[Mesa-users] make_co_wd test case in r15140
Kevin Rorke
kevin.rorke at gmail.com
Thu Jan 13 20:14:33 UTC 2022
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
> <mailto: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
> <mailto: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 <mailto:mesa-users at lists.mesastar.org>
> > https://lists.mesastar.org/mailman/listinfo/mesa-users
> <https://lists.mesastar.org/mailman/listinfo/mesa-users>
> >
>
> _______________________________________________
> mesa-users at lists.mesastar.org <mailto:mesa-users at lists.mesastar.org>
> https://lists.mesastar.org/mailman/listinfo/mesa-users
> <https://lists.mesastar.org/mailman/listinfo/mesa-users>
>
>
> _______________________________________________
> mesa-users at lists.mesastar.org
> https://lists.mesastar.org/mailman/listinfo/mesa-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20220113/75f7b200/attachment.htm>
More information about the Mesa-users
mailing list