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

Wed Jan 31 07:22:32 UTC 2024

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://docs.mesastar.org/en/release-r23.05.1/known_bugs.html#zams-model-central-composition>
.
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://docs.mesastar.org/en/release-r23.05.1/reference/star_job.html#rotation-controls>
.

-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/2912320b/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: binary_Chen_Yi-Fan_r23.05.1.tar.gz
Type: application/x-gzip
Size: 35415 bytes
Desc: not available
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20240131/2912320b/attachment.bin>