[mesa-users] helium main sequence binary

[Ying Qin]

Hi Josiah,

Thank you very much for quick reply. I now understand what some parameters really mean.

I update my binary/work and use some parameters by default. The wrong results should be due to the settings in a not correct way I used.
And now it works well.
model_number     age                                           period_days                               binary_separation                     star_1_mass                                   lg_mstar_dot_1
          1                3.1622776601683819E+002     2.0502586561339722E-001     3.2807055306783051E+000      9.8803896662487389E+000         -4.2110699139184131E+000
The results are reasonable now. I just ran it for about 20 mins, and I want to run it in a longer time, and see what’s going on.

BTW:
1. About inlist1, I use some parameters by default, and add one command line: mesa_dir = ‘ ‘. It seems to use mesa r-7624 environment.
So can you please explain more about this command ?

2. How to make mesa run fast ? I though one way is to change the time_step, are there any other controls ?


l put the new inlists below if you want to check.  Your reply helped indeed, and thank you so much again.

Have a nice day,
Ying


On 12 Sep 2015, at 17:29, Josiah Schwab <jwschwab at berkeley.edu<mailto:jwschwab at berkeley.edu>> wrote:

Hello Ying,

On 12 September 2015 at 03:37 PDT, Ying Qin wrote:

Thank you for sending the additional files.  Now I can reproduce the
results you mention.

I know WR star lost mass very fast, these results are not what I expect now.
Why does WR star decrease mass from 3.9637246692135668E+000 ? I think the mass of WR should be decreasing from about 10.0.
Why does binary_separation change from 9.6975446700026726E+000 ? Because I initialize this it with 0.2d0.
For these results, I said there were random, Because they are not reasonable.

Before the main evolution begins, there was a relaxation stage to
satisfy the condition that the rotation of the star be sychronized with
the orbit (since you specified do_initial_orbit_sync_1 = .true.).

During this part --- which is printed to your terminal along with some
relax_to_omega messages, but is not included in the binary_history.data
file --- the WR wind you specified was active.  So by the time the
system gets synchronized and therefore ready for the main evolution, the
star has lost mass and the orbit has adjusted.

I'm surprised (as are you) that MESA isn't deactivating mass loss during
this relaxation phase.  Hopefully Pablo or one of the binary experts can
chime in.

I suggest the following work-around.  Make a tidally synchronized model
by running with the WR wind off.  Immediately save this model at
timestep 1.  Then load this saved model and run with the WR wind on.


Also, I want star1 to evolve with zero age and zero model number, and
I change these in inlist1:

     set_initial_age = .true.
     initial_age = 0 ! in years

     set_initial_model_number = .true.
     initial_model_number = 0

But from the results, we can clearly find it did not  work.

These controls are mainly used when you are loading a saved model file,
which has an associated age and model number.  These controls are not
really relevant since your model is coming from one of the ZAMS files.

Still, why is it clear this "didn't work"?

When I look in binary_history.data, the first model number is 1 and the
first star_age is the duration of the first timestep.  That is what I
would expect to see using these flags (even if it is not really due to
these flags in this case).

Hope that helps,
Josiah

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20150912/a7462375/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: inlist1
Type: application/octet-stream
Size: 2745 bytes
Desc: inlist1
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20150912/a7462375/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: inlist2
Type: application/octet-stream
Size: 477 bytes
Desc: inlist2
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20150912/a7462375/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: inlist_project
Type: application/octet-stream
Size: 883 bytes
Desc: inlist_project
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20150912/a7462375/attachment-0002.obj>