[mesa-users] convergence

Pablo Marchant pamarca at gmail.com
Thu May 12 13:52:55 EDT 2016 

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/7ab21c01/attachment.html>

More information about the Mesa-users mailing list