[mesa-users] Vink_wind_eta

Tue May 26 16:34:59 EDT 2015

Hi mesa-users,

For the sake of low- and intermediate-mass stellar evolution, I'd like for
MESA to preserve the RGB/AGB distinction that it has currently (i.e.,
triggered on central He).  If this becomes a part of a "cool wind"
category, that's ok with me.

Alternatives based on (core) burning phase are less clear with regard to
the RGB/AGB distinction.  Since the AGB takes place after core He burning,
I don't want my AGB wind scheme to start with core He burning.  We're
really talking about two phases of stellar evolution that are driven by
shell burning, as Mathieu already pointed out.

I hope more people will chime in so that we get a sense of what the MESA
community wants.

Aaron

On Wed, May 27, 2015 at 6:09 AM, Zsolt Keszthelyi <
Z.Keszthelyi at campus.lmu.de> wrote:

> Hi,
>
> I was about to suggest the same thing! A further support is that this is
> basically already implemented in the 'Dutch wind'.
>
> Maybe 10 - 12 kK would be a good limit to distinguish between 'hot' and
> 'cool'.
>
> Cheers,
>  Zsolt
>
>
>
>
> > Von: Mathieu <mathren90 at gmail.com>
> > An: mesa-users at lists.sourceforge.net
> > Kopie:
> > Datum: Tue May 26 22:03:06 CEST 2015
> >
> > Hi everyone,
> >
> > since the wind mass loss is not directly connected with the burning
> > stage in the core, I would suggest avoiding to name the different wind
> > options according to the nuclear processes in the core.
> > It seems a bit confusing to me.
> >
> > Most of the mass loss algorithms apply in a given temperature range, so
> > I would suggest using something like:
> >
> >   - wind_hot
> >   - wind_cool
> >   - wind_WR
> >
> > and use a condition on the effective temperature (and surface hydrogen
> > abundance for the WR wind scheme) to switch between different rates.
> > This should match more consistently the physics of the wind driving
> > (which depends on the radiative flux, parametrized in terms of the
> > effective temperature), and also the way mass loss algorithms are
> > derived either from observations (e.g. de Jager, Nieuwenhuijzen, and van
> > Loon rates), or from numerical simulations of the wind (as in the Vink
> > case).
> >
> > Best wishes,
> >
> > Mathieu
> >
> > On 05/26/2015 07:32 PM, Bill Paxton wrote:
> > > Thank Ehsan.   And anyone else who'd like to add a comment, please do.
> > >
> > > bill
> > >
> > >
> > >
> > > On May 26, 2015, at 10:30 AM, Ehsan Moravveji wrote:
> > >
> > >> Hi Bill, hi all,
> > >> I think a reasonable naming that also takes care of generality could
> be something
> > like mass_loss_h_burning, and mass_loss_he_burning. Then whether or not
> one deals
> > with OB stars or an RGB, the former applies, and after the core He
> ignition, the
> > latter enters the stage.
> > >> Just a suggestion …
> > >>
> > >> Cheers
> > >> Ehsan.
> > >>
> > >>> On 26 May 2015, at 17:57, Bill Paxton <paxton at kitp.ucsb.edu> wrote:
> > >>>
> > >>> Thanks --- that is very helpful.  it looks like we're still using a
> scheme from
> > the infancy of mesa when there were only a few options, but now it isn't
> a good fit
> > for the range of options that have been added since then.  time for a
> cleanup.
> > >>>
> > >>> the RGB/AGB split was meant to provide a simple way for users to
> select different
> > wind schemes for different stages of evolution.
> > >>> and since the scheme could change on the fly, there needs to be a
> way to change
> > the wind_scaling_factor too.
> > >>> that is taken care of by providing separate values of scaling factor
> for the
> > different kinds of winds.
> > >>>
> > >>> I can easily do the renaming to replace "eta" by "scaling factor"
> while keeping
> > different scaling factors for different types of wind.
> > >>>
> > >>> Do you have suggestions for a way to replace the crude RGB/AGB by
> something better?
> >  RGB/AGB/OB?  or what?
> > >>> and please include precise details of the partitioning so that I can
> translate
> > it into code!
> > >>>
> > >>> Thanks again,
> > >>> Bill
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> On May 26, 2015, at 3:26 AM, Zsolt Keszthelyi wrote:
> > >>>
> > >>>> Hi Bill,
> > >>>>
> > >>>> thanks for your reply.
> > >>>>
> > >>>> I think the issue is that eta is used in different contexts with
> different meanings
> > in the literature.
> > >>>>
> > >>>>
> > >>>> 1. In the context of RGB / AGB stars (Reimers 1975, Blöcker 1995)
> eta is a scaling
> > factor to match observed mass loss rates with their empirical mass loss
> formulas.
> > >>>>
> > >>>>
> > >>>> 2. On the other hand, in the context of WR stars (Cassinelli 1991
> and references
> > therein) eta was introduced with a physical meaning, to describe the
> wind with the
> > ratio of stellar wind momentum flux and the photon momentum flux, eta =
> Mdot * vinf
> > / (L / c).
> > >>>>
> > >>>> This eta is used in the context of OB stars (e.g., Lamers &
> Leitherer 1993,
> > Puls et al. 1996) as the performance number.
> > >>>>
> > >>>>
> > >>>>
> > >>>> Even though the idea of eta as a scaling factor is stated (and
> used), a user
> > was looking for eta in the Vink paper, so that is why I think calling it
> simply 'wind_scaling_f
> > actor' might make it easier for the users.
> > >>>>
> > >>>>
> > >>>> Also my understanding is that you must set either 'RGB_wind_scheme'
> or 'AGB_wind_scheme'
> > to apply one of the wind recipes, however the Kudritzki, Vink (OB) and
> Nugis & Lamers,
> > Gräfener & Hamann (WR) prescriptions are not valid for these stars. This
> might also
> > be a source of confusion since in a previous email the vink_wind_eta and
> RGB mass
> > loss was mentioned together.
> > >>>>
> > >>>>
> > >>>> I hope this is helpful.
> > >>>>
> > >>>> Cheers,
> > >>>>
> > >>>> Zsolt
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>> Von: Bill Paxton <paxton at kitp.ucsb.edu>
> > >>>>> An: Zsolt Keszthelyi <Z.Keszthelyi at campus.lmu.de>
> > >>>>> Kopie: mesa-users at lists.sourceforge.net users <
> mesa-users at lists.sourceforge.net>
> > >>>>> Datum: Tue May 26 06:46:15 CEST 2015
> > >>>>>
> > >>>>>
> > >>>>> On May 23, 2015, at 4:25 AM, Zsolt Keszthelyi wrote:
> > >>>>>
> > >>>>>> It's a little bit unlucky nomenclature though, since in stellar
> wind physics
> > the
> > >>>>> eta is the so-called wind efficiency / performance number and has
> nothing to
> > do with
> > >>>>> a numerical scaling factor. (It might be useful to change it in
> the next version.)
> > >>>>>
> > >>>>>
> > >>>>> Hi,
> > >>>>>
> > >>>>> In star/defaults/controls.defaults we describe the various etas
> like this for
> > Reimers
> > >>>>> and Blocker winds:
> > >>>>>
> > >>>>>        !### Reimers_wind_eta
> > >>>>>        ! Parameter for mass loss by Reimers wind prescription.
> > >>>>>        ! Reimers mdot is `eta*4d-13*L*R/M` (Msun/year), with L, R,
> and M in
> > solar
> > >>>>> units.
> > >>>>>
> > >>>>>        !### Blocker_wind_eta = 0
> > >>>>>        ! Parameter for mass loss by Blocker's wind prescription.
> > >>>>>        ! Blocker mdot is `eta*4.83d-9*M**-2.1*L**2.7*4d-13*L*R/M`
> (Msun/year),
> > >>>>>
> > >>>>> Having stated that idea twice, we just hope the reader will make
> the leap to
> > understand
> > >>>>> that they work similarly for the remaining kinds of winds.
> > >>>>>
> > >>>>> So we use "parameter for mass loss" where you would use "wind
> efficiency /
> > performance
> > >>>>> number".
> > >>>>>
> > >>>>> In practice of course it is a numerical scaling factor for the
> strength of
> > the wind.
> > >>>>> At least it looks like that to me.  And it does that in the code.
> > >>>>>
> > >>>>> If I'm missing something important about the role of eta in
> stellar wind physics,
> > >>>>> please educate me.
> > >>>>>
> > >>>>> Thanks,
> > >>>>> Bill
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> ------------------------------------------------------------------------------
> > >>>>> One dashboard for servers and applications across
> Physical-Virtual-Cloud
> > >>>>> Widest out-of-the-box monitoring support with 50+ applications
> > >>>>> Performance metrics, stats and reports that give you Actionable
> Insights
> > >>>>> Deep dive visibility with transaction tracing using APM Insight.
> > >>>>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> > >>>>>
> > >>>>> _______________________________________________
> > >>>>> mesa-users mailing list
> > >>>>> mesa-users at lists.sourceforge.net
> > >>>>> https://lists.sourceforge.net/lists/listinfo/mesa-users
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>
> > >>>
> ------------------------------------------------------------------------------
> > >>> One dashboard for servers and applications across
> Physical-Virtual-Cloud
> > >>> Widest out-of-the-box monitoring support with 50+ applications
> > >>> Performance metrics, stats and reports that give you Actionable
> Insights
> > >>> Deep dive visibility with transaction tracing using APM Insight.
> > >>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> > >>> _______________________________________________
> > >>> mesa-users mailing list
> > >>> mesa-users at lists.sourceforge.net
> > >>> https://lists.sourceforge.net/lists/listinfo/mesa-users
> > >
> > >
> ------------------------------------------------------------------------------
> > > One dashboard for servers and applications across
> Physical-Virtual-Cloud
> > > Widest out-of-the-box monitoring support with 50+ applications
> > > Performance metrics, stats and reports that give you Actionable
> Insights
> > > Deep dive visibility with transaction tracing using APM Insight.
> > > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> > > _______________________________________________
> > > mesa-users mailing list
> > > mesa-users at lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/mesa-users
> >
> >
> >
> ------------------------------------------------------------------------------
> > _______________________________________________
> > mesa-users mailing list
> > mesa-users at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/mesa-users
> >
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> mesa-users mailing list
> mesa-users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mesa-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20150527/95828f01/attachment.html>