[mesa-users] Vink_wind_eta

Mathieu mathren90 at gmail.com
Tue May 26 16:01:16 EDT 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 \85
>>
>> 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\F6cker 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_factor' 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\E4fener & 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

More information about the Mesa-users mailing list