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

Wed Jan 31 20:38:08 UTC 2024

Hi Yifan,

> 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.

The "Killed" message means your operating system has decided to stop MESA, usually because the system is running out of memory.  How much RAM does your system have?  Are you running on a virtual machine and, if so, how much RAM have you allocated to it?

Our recommended minimum RAM is 8GB, though a quick glance across the test suite suggests you might get away with ~6GB.

Don't forget to search the `mesa-users` archive for potential answers:

     https://lists.mesastar.org/pipermail/mesa-users/

The first, third and fourth results I get by searching "killed" are relevant:

     https://lists.mesastar.org/pipermail/mesa-users/2021-April/012570.html
     https://lists.mesastar.org/pipermail/mesa-users/2023-July/014638.html
     https://lists.mesastar.org/pipermail/mesa-users/2023-January/014259.html

The second result is this thread.

Regards,
Warrick

___________

Warrick Ball
Senior Research Software Engineer
University of Birmingham
W.H.Ball at bham.ac.uk

On Wed, 31 Jan 2024, Chen Yi-Fan via Mesa-users wrote:

> CAUTION: This email originated from outside the organisation. Do not click links or open attachments unless you recognise the sender and know the content is safe.
> 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. 
> 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.
> 
> -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
> 
> 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
> 
> 
> 
> _______________________________________________
> 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$
> 
> 
>