[Mesa-users] make_co_wd test case in r15140

Thu Jan 13 23:35:46 UTC 2022

Hi Kevin,

You are absolutely right, setting MESA_RUN_OPTIONAL=t I find exactly the
same issue, and thanks to Evan we've got a good explanation.

I've checked a little more on how this works, just to see why this has
worked to me the first time with "initial_mass = 5.7d0"

With a fresh copy of the make_co_wd model, and with no value on
MESA_RUN_OPTIONAL, the first time the model creates zams.mod from a copy of
standard_zams.mod.
When I've set MESA_RUN_OPTIONAL as you suggested, which means to set a
value (any value works), the model runs inlist_zams_header and creates
zams.mod, and then it overwrites standard_zams.mod so, as long as
MESA_RUN_OPTIONAL has a value, you are using your initial_mass (also you
can modify rn file to be sure).

Right now, the only way to recover the original standard_zams.mod file is
to go to the original folder, so I've compared the two files.
The original file was created with the version 15121, and was set to create
a 3.1 Msun initial_mass. Then running by default (without optional
parameter set) zams.mod allows to run the model without issues... just
because it's still for a 3.1Msun despite any change of initial_mass..
With every run in this model you will have a zams.mod so you can check the
initial_mass used by reading its header.

I've tried a couple of runs using other parameterizations but without good
outputs, so I stop here. I'm glad that the suggested extra pressure works.

Kind regards,

Silvana

El jue, 13 ene 2022 a las 21:14, Kevin Rorke (<kevin.rorke at gmail.com>)
escribió:

> Hi Silvana
>
> Thanks for your interest. It is always helpful to see if somebody else is
> independently getting the same results!
>
> One of the steps that the make_co_wd test case does is to create a ZAMS
> model of the required mass to begin with; but as I understand it, if you
> want to run the case with a different initial mass, you will need to set an
> environment parameter to make this happen.
>
> So if you execute this:
>
> export mesa_run_optional=t
>
> from the command line and re-run the case for a starting mass of 5.7M,
> does the case still complete successfully?
>
> I'm also running my version of MESA on Ubuntu in a VMWare VM, and I had
> wondered previously if the virtualisation had somehow affected the test
> case.
>
> Regards
>
> Kevin
> On 1/13/22 9:53 PM, Silvana Vacchina via Mesa-users wrote:
>
> Hi Kevin,
>
> I found your problem interesting and I've tried myself to run this test
> (make_co_wd), since I've been testing for a while with r15140 (it's really
> good).
>
> I can run the test without issues. I've only changed start_mass in the
> inlist_common to set "initial_mass = 5.7d0" and activated "pgstar_flag =
> .true.". There is a comment in the inlist that suggest that it is possible
> to run this start_mass, I quote:
> "! initial_mass in the range 1.0-6.5 Msun will produce CO WDs
>  ! with masses 0.5-1.0 Msun."
> Maybe there is another change involved in any place... in fact I don't
> understand "And the environment variables are set to create a new zams
> model each time." I can try more changes if you want, to rule out a model
> or system problem (I can also attach results if needed).
>
> Since I've found no issues, and since you've realized that it might
> require some 16 GB, I can say that I'm working on Oracle Virtual Machine,
> with an operating system Ubuntu (system and libraries as suggested for
> r15140), with 32 GB RAM and assigning 10 cores to the calculations (you can
> check the value of OP_NUM_THREADS).
>
> I hope you find the way to make this work.
>
> Cheers,
> Silvana.
>
> El jue, 13 ene 2022 a las 0:48, Evan Bauer via Mesa-users (<
> mesa-users at lists.mesastar.org>) escribió:
>
>> Hi Kevin,
>>
>> Thanks for calling attention to this. I don’t think you’re doing anything
>> wrong per se. I’ve noticed that massive C/O WDs have gotten harder to
>> produce with make_co_wd in recent MESA versions as well, and I can confirm
>> that I run into similar convergence problems when starting with an initial
>> mass of 5.7.
>>
>> I think the problem is that the solver is struggling to converge for the
>> outer layers during some parts of the very luminous post-AGB evolution. I
>> was able to get around this by adding this control in inlist_remove_env and
>> inlist_settle:
>>         Pextra_factor = 4
>>
>> That’s somewhat inspired by the test case wd_nova_burst, which also has a
>> massive WD evolving through a similar luminous post-nova phase. This
>> control might make some parts of the evolution slightly unrealistic, but if
>> your goal is just to produce a fresh C/O WD model to work with, this should
>> get your model where you want it to end up.
>>
>> Perhaps we can add this as a default in future MESA releases so that
>> massive C/O WDs aren’t so hard to produce consistently.
>>
>> By the way, I think the RAM constraint that you were seeing comes from
>> all of the EOS table caching that occurs during the relaxation phase if you
>> haven’t run models through that range of composition space before on your
>> MESA installation. I noticed that I had quite large RAM usage when I first
>> ran the model and had many EOS tables to cache, but the next time I ran the
>> model my RAM usage was much more reasonable.
>>
>> Cheers,
>> Evan
>>
>> > On Jan 10, 2022, at 12:58 PM, Kevin Rorke via Mesa-users <
>> mesa-users at lists.mesastar.org> wrote:
>> >
>> > Hi everyone
>> >
>> > I've been trying to run the make_co_wd test case in r15140 with a 5.7
>> Msun (or thereabouts) starting mass for some time now. Previously the run
>> failed during the inlist_remove_env step because of memory constraints - it
>> seems to require about 16GB of RAM. But even with that amount of memory,
>> the run eventually fails for any starting mass in that region.
>> >
>> > The only value I've changed is the initial_mass value in inlist_common.
>> And the environment variables are set to create a new zams model each time.
>> Can anyone suggest what I might be doing wrong?
>> >
>> > Cheers
>> >
>> > Kevin
>> >
>> >  Exceeded max_iters iterations in eval_T_tau_uniform
>> >  retry: error in PT_eqns_surf    1887
>> >                                                      dt
>> 5.6302130558697700D-21
>> >                                      min_timestep_limit
>> 9.9999999999999995D-21
>> >
>> >  stopping because of problems dt < min_timestep_limit
>> >
>> >
>> > terminated evolution: cannot find acceptable model
>> >
>> > termination code: min_timestep_limit
>> > DATE: 2022-01-10
>> > TIME: 19:24:41
>> >
>> > ******************************************************************
>> > failed to create co_wd.mod when running inlist_remove_env_header
>> > ******************************************************************
>> >
>> > <inlist_common.txt>_______________________________________________
>> > mesa-users at lists.mesastar.org
>> > https://lists.mesastar.org/mailman/listinfo/mesa-users
>> >
>>
>> _______________________________________________
>> mesa-users at lists.mesastar.org
>> https://lists.mesastar.org/mailman/listinfo/mesa-users
>>
>>
> _______________________________________________mesa-users at lists.mesastar.orghttps://lists.mesastar.org/mailman/listinfo/mesa-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20220114/a2d825b3/attachment.htm>