[mesa-users] convergence
Kenny Van
kvan at ualberta.ca
Thu May 12 15:08:00 EDT 2016
Hi,
Thanks for the replies, I'll read over the materials you guys have
linked/recommend. One other thing I was trying to do was instead of having
MESA retry a model with a constantly smaller timestep until it reaches its
limit then stops, have it reduce timestep until it reaches that min value
and no longer decrease. Is that possible to do with MESA?
Thanks
On Thu, May 12, 2016 at 11:52 AM, Pablo Marchant <pamarca at gmail.com> wrote:
> A followup on what Bill just said.
>
> That mass transfer history does seem to be a product of using an explicit
> method to compute the mass transfer rate. As Bill says there is an option
> to implicitly adjust mass transfer rates so that the radius of the donor
> star matches its Roche lobe. However this is not the only implicit method
> available.
>
> The way mass transfer is computed in MESA involves two different choices.
> One relates to the physical model used and the other one to the numerics.
> In terms of the physical model you have the following options, which are
> set using the "mdot_scheme" option in the binary_controls section of your
> inlist:
>
> - "Ritter": Follows the prescription of Ritter 1988
> - "Kolb": Follows the prescription of Ritter & Kolb 1990
> - "roche_lobe": sets mass transfer such that R ~= R_Rl at the end of the
> step
> - "contact": similar to "roche_lobe", but includes treatment for contact
> systems as in Marchant et al. (2016)
> - custom: There is an use_other_rlo_mdot option for the user to define his
> own formula for mass ransfer rates.
>
> The first two of these involve an equation for the mass transfer rate that
> can be directly computed in terms of properties of the system (amount of
> overflow, surface sound speed, etc...), while for the other two the mass
> transfer rate cannot be computed directly.
>
> Now, in addition, you have two purely numerical options regarding the
> computation of the mass transfer rate:
>
> - explicit: simply compute the rate at the beginning of the step. Can only
> be used if the mdot_scheme option gives an explicit formula for the mass
> transfer rate (i.e. options "Ritter" and "Kolb" or a custom, user-defined
> mdot formula).
>
> - implicit: iterate the step while adjusting the mass transfer rate until
> at the end of the step a given condition is satisfied to a user-defined
> tolerance. When using the the "roche_lobe" scheme this means that
> (R-R_Rl)/R_Rl at the end of the step is within the required tolerance. When
> using schemes that give an explicit formula for the mass transfer rate, the
> tolerance defines the relative difference between the values of the mass
> transfer rate used for the step, and the value computed at the end of the
> step.
>
> In order to activate the implicit scheme, the option
> "max_tries_to_achieve" of binary_controls has to be bigger than zero.
>
> Perhaps these options need a bit of renaming, and switching the defaults?
> The word "scheme" should probably be used for the choice between implicit
> and explicit, maybe an option with a boolean value
> use_implicit_mass_transfer_scheme (in addition to max_tries_to_achieve)
> would be useful, and instead of "mdot_scheme" we could use something like
> "mass_transfer_option" or "mass_transfer_model". Also might be a good idea
> to set the implicit calculation as the default. I think a similar conundrum
> happens with regard to mass loss rates for single stars, the options are
> named *_scheme, in addition to having an option to implicitly compute them.
>
> On Thu, May 12, 2016 at 6:57 PM, Bill Paxton <paxton at kitp.ucsb.edu> wrote:
>
>> I 2nd Rob's comments. you need to take time to understand the
>> complexities of the implementation of mass transfer in binaries. start by
>> reading Pablo's excellent section in the recent MESA instrument paper
>> (section 2). in particular, get clear about the differences between
>> implicit and explicit methods (section 2.3). the implicit method adjusts
>> mdot at each step to fine tune the radius to match the roche lobe -- it is
>> not trying to keep mdot smooth. instead it is trying to keep the radius
>> close to the roche value. try plotting the difference R minus Roche_R for
>> comparison.
>>
>> b
>>
>>
>>
>> On May 12, 2016, at 9:48 AM, Robert Farmer wrote:
>>
>> Hi Kenney
>>
>> firstly, when debugging timestep issues you should look for whats driving
>> the timetsep. In the terminal output, look for the dt_limit (bottom right
>> of the output)
>>
>> An example from a run i've done:
>>
>> __________________________________________________________________________________________________________________________________________________
>>
>> step lg_Tcntr Teff lg_LH lg_Lnuc Mass
>> H_rich H_cntr N_cntr Y_surf X_avg eta_cntr zones retry
>> lg_dt_yr lg_Dcntr lg_R lg_L3a lg_Lneu lg_Mdot
>> He_core He_cntr O_cntr Z_surf Y_avg gam_cntr iters bckup
>> age_yr lg_Pcntr lg_L lg_LZ lg_Psurf lg_Dsurf
>> C_core C_cntr Ne_cntr Si_cntr Z_avg v_div_cs dt_limit
>>
>> __________________________________________________________________________________________________________________________________________________
>>
>>
>> 842 9.896936 3358.924 4.753581 27.226659 15.712764 9.641372
>> 0.000000 0.000000 0.317656 0.402478 6.306150 1285 29
>> -8.132787 9.329324 3.062386 19.641098 14.283218 -99.000000
>> 6.071392 0.010646 0.000001 0.020066 0.324405 4.490119 6
>> 10
>> 2.5759E-03 27.111358 5.183055 27.226659 2.340030 -8.721408
>> 0.000000 0.000001 0.000000 0.000004 2.731E-01 0.000E+00
>> dX_nuc_drop
>>
>>
>> The dX_nuc_drop is limiting my timestep, with this i can then search the
>> controls.default to look for what controls dX_nuc_drop, which in this case
>> is the dX_nuc_drop_limit inlist control. Tweaking that control would then
>> alter how my timestep behaves (you may then need to do this again with
>> another control)
>>
>>
>> Secondly you may find help in:
>>
>> http://mesastar.org/teaching-materials/2015-mesa-summer-school/phinney-lecture-1-mesa-binary-and-mass-transfer-basics
>>
>> http://mesastar.org/teaching-materials/2015-mesa-summer-school/phinney-lecture-2-advanced-mass-transfer-and-binary-extras
>>
>> which are lectures from the 2015 summer school on mass transfer and might
>> help.
>>
>> Rob
>>
>>
>> ------------------------------------------------------------------------------
>> Mobile security can be enabling, not merely restricting. Employees who
>> bring their own devices (BYOD) to work are irked by the imposition of MDM
>> restrictions. Mobile Device Manager Plus allows you to control only the
>> apps on BYO-devices by containerizing them, leaving personal data
>> untouched!
>>
>> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j_______________________________________________
>> mesa-users mailing list
>> mesa-users at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mesa-users
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Mobile security can be enabling, not merely restricting. Employees who
>> bring their own devices (BYOD) to work are irked by the imposition of MDM
>> restrictions. Mobile Device Manager Plus allows you to control only the
>> apps on BYO-devices by containerizing them, leaving personal data
>> untouched!
>> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
>> _______________________________________________
>> mesa-users mailing list
>> mesa-users at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mesa-users
>>
>>
>
>
> --
> Pablo Marchant Campos
> M.Sc on Astrophysics, Universidad Católica de Chile
> PhD student, Argelander-Institut für Astronomie
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20160512/b34ec163/attachment.html>
More information about the Mesa-users
mailing list