[Mesa-users] Binary Timestep problem

[Cole Campbell Johnston]

Hi Mesa-users,


I am having trouble with the binary module of mesa-r10108, running on ubuntu 16.04 with the latest SDK.


As a baseline, I am trying to have a run with no interactions, i.e. ignoring rlof, and setting all mass transfer, and tidal circularization effects off. When running with evovle_both_stars = .true., the timesteps increase until a certain point of the main-sequence evolution, and then rapidly decrease until I receive the following error:


 s% dt_next   3.5881560164170280E-007
 s% min_timestep_limit   9.9999999999999995E-007
 s% dt_next   3.5881560164170280E-007
 s% min_timestep_limit   9.9999999999999995E-007
?
terminated evolution: cannot find acceptable model

termination code: min_timestep_limit

I have set the terminal frequency to 1 for the primary, secondary, and binary output for an example case, attached as terminal.log_2(or 4). As is expected, the limiting factor for the beginning of the evolution is varcontrol, while for the secondary it is b_companion, which makes sense. Eventually, it switches to max increase for the primary and begins continuously decreasing the timesteps. I also modified the run_binary_extras.f to write out the dt_why_reason after each step, which is also seen in terminal.log as DT_WHY: 4 after each pair of star outputs (seen in terminal.log_4). Tracing this back through the code, I have gathered that this comes from binary/public/binary_def.f90 line 45, which shows that:

public/binary_def.f90:42:      integer, parameter :: b_Tlim_comp = 1
public/binary_def.f90:43:      integer, parameter :: b_Tlim_roche = b_Tlim_comp + 1   --> This one
public/binary_def.f90:44:      integer, parameter :: b_Tlim_jorb = b_Tlim_roche + 1
public/binary_def.f90:45:      integer, parameter :: b_Tlim_env = b_Tlim_jorb + 1         --> or this one!
public/binary_def.f90:46:      integer, parameter :: b_Tlim_sep = b_Tlim_env + 1
public/binary_def.f90:47:      integer, parameter :: b_Tlim_ecc = b_Tlim_sep + 1
public/binary_def.f90:48:      integer, parameter :: b_Tlim_dm = b_Tlim_ecc + 1
public/binary_def.f90:49:      integer, parameter :: b_numTlim = b_Tlim_dm

which makes me conclude that it is an issue with the change in envelope mass, however, changing the limits with this does not fix this issue.

However, if I if set several fm = fr = 1. and fm_limit = fr_limit = 1, my terminal output shows DT_WHY: 2 ( seen in terminal.log_2), which would be a roche relative gap problem. Again, changing the limits associated with this doesn't fix the problem.

When I run the very same but with evolve_both_stars = .false., the run completes with no issue -- even if I swap the primary and secondary.
I have tried this with a number of masses, periods, eccentricities. Furthermore, after consulting the mailing-list archives I have tried setting the quantities fr,fm,fj, etc. and fr_limit,fm_limit, fe_limit to various quantities as well, however I always recover the same problem.

Furthermore, if I run each individually with star, the run completes with no issues. This leads me to think that the problem is something to do with the binary_timestep module, but I do not know what to do to stop this from limiting my time-step.

I have attached my binary inlist, primary inlist (secondary is effectively the same with some minor changes in physical properties), and twp examples of the terminal output log.

Any suggestions/tip are very much appreciated!

cheers,
cole
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20171217/0327920a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: inlist_primary
Type: application/octet-stream
Size: 4836 bytes
Desc: inlist_primary
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20171217/0327920a/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: inlist
Type: application/octet-stream
Size: 1354 bytes
Desc: inlist
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20171217/0327920a/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: terminal.log_2
Type: application/octet-stream
Size: 191582 bytes
Desc: terminal.log_2
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20171217/0327920a/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: terminal.log_4
Type: application/octet-stream
Size: 195599 bytes
Desc: terminal.log_4
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20171217/0327920a/attachment-0003.obj>