[mesa-users] convergence

Kenny Van kvan at ualberta.ca
Thu May 12 15:28:43 EDT 2016


Thanks for the quick reply Pablo

On Thu, May 12, 2016 at 1:14 PM, Pablo Marchant <pamarca at gmail.com> wrote:

> Usually retries are invoked because of convergence issues, with the Newton
> solver failing to find a solution for the following step, which hopefully
> is not the case with a smaller timestep. Fixing a minimum timestep will
> likely result in your model getting stuck and incapable of computing a
> single step more if it ever reaches the limit, it will just eternally try
> to recompute the same step over and over and failing to do so.
>
> So, it's possible, but very likely useless.
>
> On Thu, May 12, 2016 at 9:08 PM, Kenny Van <kvan at ualberta.ca> wrote:
>
>> 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
>>>
>>
>>
>
>
> --
> 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/028b8d83/attachment.html>


More information about the Mesa-users mailing list