[Mesa-users] The first model is slow to converge on binary evolution (r12.11.5)

Wed Jan 31 20:14:19 UTC 2024

Hello Yifan,

> Or is J_spin already excluded from the output, which means that it can be
calculated by the formula under synchronization assumption?
> My puzzle is that if I'm evolving a non-rotational model, how does
Magnetic Braking work through the orbit-spin

I see your question now. I don't know if it makes sense to use 'do_jdot_mb
= true.' and 'do_tidal_sync = true.' together.

'do_jdot_mb = true' follows the orbital magnetic braking formulation  in
Rappaport, Verbunt, and Joss. apj, 275, 713-731. 1983
<https://ui.adsabs.harvard.edu/abs/1983ApJ...275..713R/abstract>.
To paraphrase, they assume the secondary star is spherical, the orbit is
circular, the rotation of the secondary is always synchronous with the
orbital motion,
and that the rotational angular momentum vector of the secondary is always
parallel to the orbital angular momentum vector.

Whereas 'do_tidal_sync = true.' calculates the tidal torque on individual
zones in the model over a given timescale.

If you want an effective J_spin of the secondary while using the magnetic
braking, perhaps multiply the moment of Inertia in each zone by the orbital
frequency (since you are assuming synchronization).

> to solve this "killed" issue, using r12115 will be fine with me, until
the next version is released.

My instincts tell me this could be an issue with your machine or
installation of r23.05.1.

-EbF

On Wed, Jan 31, 2024 at 12:04 PM Chen Yi-Fan <yifanchen.sdu at gmail.com>
wrote:

> Hi Ebraheem, Evan,
>
> I have used Ebraheem's example in r23.05.1, but it was still killed. I
> doubt that there may be something I ignored when installing MESA, as I
> can't even reproduce my issue of "the first model is slow to converge ''
> at the beginning in r23.05.1.
>
> However, I employed Ebraheem's measures in r12115:
>
> " First, I commented out  "initial_z = 0.01" in the &controls section of
> inlist1 and inlist2, and instead placed the following in &starjob:
> relax_initial_Z = .true.
> new_Z = 1d-2 ",
>
> then the issue of "the first model is slow to converge '' was solved and
> the model evolution was smooth.
>
> I have also attached the output with Ebraheem's example in r23.05.1, but
> if there is no help to solve this "killed" issue, using r12115 will be fine
> with me, until the next version is released.
>
> About the questions of "to get the output of J_spin (currently the output
> of J_spin is zero)?":
>
> I don't necessarily want to get the explicit output of J_spin if the tidal
> synchronization assumption is effective when do_jdot_mb turns on. My puzzle
> is that if I'm evolving a non-rotational model, how does Magnetic Braking
> work through the orbit-spin synchronization?
>
> Thanks again for your replies.
>
> Sincerely,
>
> Yifan Chen
>
> Ebraheem Farag <ekfarag at asu.edu> 于2024年1月31日周三 15:22写道：
>
>> Hello Yifan,
>>
>> In r23.05.1, I Injected the inlists you shared into the evolve_both_stars
>> binary test_suite, and reproduced your issue of "the first model is slow to
>> converge ''.
>>
>> To fix:
>> ----------
>> First, I commented out  "initial_z = 0.01" in the &controls section of
>> inlist1 and inlist2, and instead placed the following in &starjob:
>> relax_initial_Z = .true.
>> new_Z = 1d-2
>>
>> From here, the first model is slow to converge. I then employed the ZAMS
>> model fix suggested by Evan
>> <https://urldefense.com/v3/__https://docs.mesastar.org/en/release-r23.05.1/known_bugs.html*zams-model-central-composition__;Iw!!IKRxdwAv5BmarQ!dCckuIf5nvgFNW-GjX-xrKLFmjNOGUq2qhE1BO4PD4IvcaxPHN1Y6Wrr2QHiImquKDoKW8oOh-TFzxmfYERfCw$>
>> .
>> With  "zams_filename = 'zams_z2m2_y28_patched.data'" set in the &controls
>> section of inlist1 and inlist2
>> the convergence issue is gone and the models run fine detached..
>>
>> I've attached a clean tar.gz of the example using your inlists, tested
>> with:
>>    m1 = 1.4d0  ! donor mass in Msun
>>    m2 = 0.89d0 ! companion mass in Msun
>>
>> On how "to get the output of J_spin (currently the output of J_spin is
>> zero)?":
>> If i'm not mistaken, you are evolving non rotating models since you do
>> not have the rotation flags turned on, hence the rotational angular
>> momentum of each model "J_spin_1" and "J_spin_2" will be 0, while the
>> orbital angular momentum J_orb will be non-zero.  See Rotation Controls
>> <https://urldefense.com/v3/__https://docs.mesastar.org/en/release-r23.05.1/reference/star_job.html*rotation-controls__;Iw!!IKRxdwAv5BmarQ!dCckuIf5nvgFNW-GjX-xrKLFmjNOGUq2qhE1BO4PD4IvcaxPHN1Y6Wrr2QHiImquKDoKW8oOh-TFzxnVZBg6jw$>
>> .
>>
>> -EbF
>>
>>
>> On Tue, Jan 30, 2024 at 10:54 PM Chen Yi-Fan via Mesa-users <
>> mesa-users at lists.mesastar.org> wrote:
>>
>>> Hi Evan,
>>>
>>> The program is killed both before and after adding the patch ZAMS file,
>>> but at different steps. I have attached the output files, please have a
>>> look.
>>>
>>> (I also do the patch in binary/test_suite/evolve_both_stars, only change
>>> the settings to
>>>
>>>    m1 = 1.2d0  ! donor mass in Msun
>>>    m2 = 0.8d0 ! companion mass in Msun
>>>    initial_period_in_days = 3d0
>>>
>>> and the output is the same as attached.)
>>>
>>> Sincerely,
>>>
>>> Yifan Chen
>>> Evan Bauer <evan.bauer.astro at gmail.com> 于2024年1月31日周三 03:19写道：
>>>
>>>> Hi Yifan,
>>>>
>>>> You're right that the bug I mentioned should not affect r12115, so
>>>> there's probably something else going on. My main motivation for bringing
>>>> it up is that you mentioned seeing different behavior in r12115 and
>>>> r23.05.1. It will probably be much easier to get help from the mailing list
>>>> if you're using the most recent version, since many fixes and other pieces
>>>> of development have happened in the nearly 5 years since r12115 was
>>>> released.
>>>>
>>>> So could you summarize where things stand when trying this model in
>>>> r23.05.1 with the patched ZAMS model file? And send an example of the
>>>> output you see when the run fails?
>>>>
>>>> (And no need to worry about the SDK version listed in the ZAMS file.
>>>> That's included for a complete record of how the file was produced, but the
>>>> file itself should be compatible with any system running MESA.)
>>>>
>>>> Cheers,
>>>> Evan
>>>>
>>>> On Jan 30, 2024, at 7:45 AM, Chen Yi-Fan <yifanchen.sdu at gmail.com>
>>>> wrote:
>>>>
>>>> Hi Evan，
>>>>
>>>> Thanks for your correction, my version is indeed r12115.
>>>>
>>>> I have copied the patched ZAMS file and changed the "zams_filename"
>>>> both in list1 and list2, but the program was still killed soon after it
>>>> started running (as the patched ZAMS file uses z=0.02 while mine is z=0.01,
>>>> I made this test using the copy of the star/work directory in r23.05.1).
>>>>
>>>> I found that the MESA_SDK_version in the patched ZAMS file is
>>>> "aarch64-macos-22.10.1", while my MESA_SDK_version is
>>>> "x86_64-linux-23.7.3", I wonder if they're incompatible? If so, is there
>>>> any patched ZAMS file for linux users?
>>>>
>>>> The instructions told me that the issue occurs to 1.26 M_sun, that
>>>> maybe explain why the first model is slow to converge for the initial donor
>>>> mass >=1.3 M_sun in r12115, but it confuses me that as this bug affects
>>>> versions r15140 through r23.05.1, why r12115 is affected?
>>>>
>>>> Do you have any ideas for the situations I reported?
>>>>
>>>> Sincerely,
>>>>
>>>> Yifan Chen
>>>>
>>>>
>>>> Evan Bauer <evan.bauer.astro at gmail.com> 于2024年1月29日周一 22:44写道：
>>>>
>>>>> Hi Yifan,
>>>>>
>>>>> This is only a partial answer, but hopefully this will help get things
>>>>> started. First, a quick note on version naming conventions to help clarify
>>>>> which version we're talking about. Currently, the naming convention for
>>>>> MESA releases is that they are named according to release year, month, and
>>>>> number within the month, all separated by periods. The latest release was
>>>>> in 2023 (23) in the month of May (05), and was the first and only release
>>>>> during that month (1): r23.05.1. However, prior to 2021, MESA had a
>>>>> different naming convention that used the commit number (no periods) in the
>>>>> SVN repository where MESA was developed prior to transition onto git and
>>>>> GitHub. So I believe the release version you're referring to is r12115,
>>>>> right?
>>>>>
>>>>> Secondly, assuming you are using r12115, the issue that causes a
>>>>> difference between that and r23.05.1 might be this ZAMS model bug:
>>>>> https://docs.mesastar.org/en/release-r23.05.1/known_bugs.html#zams-model-central-composition
>>>>> <https://urldefense.com/v3/__https://docs.mesastar.org/en/release-r23.05.1/known_bugs.html*zams-model-central-composition__;Iw!!IKRxdwAv5BmarQ!dBfOGzQp9ijx3ZZiXEbK6RdcvYknC_q9rjaONdW1R-nn42-d0IfDgyXc-4wR08i6RySMapBBCxpDj-oy7pzpJbSv$>
>>>>>
>>>>> Can you try following the instructions on that page for applying the
>>>>> patch to that bug and let us know how things look in r23.05.1 after that?
>>>>>
>>>>> Cheers,
>>>>> Evan
>>>>>
>>>>>
>>>>> On Jan 29, 2024, at 12:14 AM, Chen Yi-Fan via Mesa-users <
>>>>> mesa-users at lists.mesastar.org> wrote:
>>>>>
>>>>> Hi everyone,
>>>>>
>>>>> I am using MESA  r12.11.5 to conduct the binary evolution with the
>>>>> donor 1.2~1.4 M_sun and the accretion 0.6 ~ 0.9 M_sun, chosen the
>>>>> metallicity z=0.01 and no pre-main sequence evolution.
>>>>>
>>>>> The problem arises when I take the initial donor mass >=1.3 M_sun, the
>>>>> terminal tells me that the first model is slow to converge. For smaller
>>>>> donor mass, evolution can proceed smoothly.
>>>>>
>>>>> I tried to use the latest mesa-r23.05.1, but it was killed after
>>>>> running over a hundred steps (while I used the exact same list), why is
>>>>> that?
>>>>>
>>>>> In addition, I set
>>>>>
>>>>> do_jdot_mb = true.
>>>>>
>>>>> which assumes that the orbit is synchronized with the spin. Do I need
>>>>> to set a series of rotation-related modules such as
>>>>>
>>>>> do_tidal_sync = true.
>>>>>
>>>>> to get the output of J_spin (currently the output of J_spin is zero)?
>>>>> Or is J_spin already excluded from the output, which means that it can be
>>>>> calculated by the formula under synchronization assumption?
>>>>>
>>>>> The list I used is attached. Any advice will be helpful to me.
>>>>>
>>>>> Sincerely,
>>>>>
>>>>> Yifan Chen
>>>>> <inlist2><inlist1><inlist_project>
>>>>> _______________________________________________
>>>>> mesa-users at lists.mesastar.org
>>>>> https://lists.mesastar.org/mailman/listinfo/mesa-users
>>>>> <https://urldefense.com/v3/__https://lists.mesastar.org/mailman/listinfo/mesa-users__;!!IKRxdwAv5BmarQ!dBfOGzQp9ijx3ZZiXEbK6RdcvYknC_q9rjaONdW1R-nn42-d0IfDgyXc-4wR08i6RySMapBBCxpDj-oy7sMH-VvV$>
>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>> mesa-users at lists.mesastar.org
>>>
>>> https://urldefense.com/v3/__https://lists.mesastar.org/mailman/listinfo/mesa-users__;!!IKRxdwAv5BmarQ!dBfOGzQp9ijx3ZZiXEbK6RdcvYknC_q9rjaONdW1R-nn42-d0IfDgyXc-4wR08i6RySMapBBCxpDj-oy7sMH-VvV$
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20240131/bc36688e/attachment.htm>