[Mesa-users] Test suite in r15140

Wed Sep 8 15:23:56 UTC 2021

Hi Kevin,

Thanks for this report. It looks like you're using make_co_wd exactly how it was intended to be used, so I would hope the design is robust enough that you can accomplish your goal here.

I've just attempted to reproduce the failure you're seeing by running make_co_wd on 15140 with an initial mass of 5.7, but I don't see it fail in the same spot. On my system, this succeeds in running through the relaxation process. However, I do notice that this particular stage where you see the run fail is using more memory than the preceding steps, around 6 GB. Is it possible your system is running out of memory during this step and killing the run?

Cheers,
Evan

> On Sep 8, 2021, at 5:14 AM, Kevin Rorke via Mesa-users <mesa-users at lists.mesastar.org> wrote:
> 
> Hi Josiah
> 
> Thanks for taking the time to respond. I started with the make_co_wd test case as that did indeed seem most suitable, and I was running it with the original mass default of 3.1 M_sun just to see if I could get it to complete successfully. (That was my idea with 1M_pre_ms_to_wd too - just trying to get a vanilla test case to complete).
> 
> For make_co_wd, I have also set the MESA_RUN_OPTIONAL variable each time, as well as removing the max_model_number parameter from all the inlists.
> 
> Using 5.7Msun as a starting mass in make_co_wd, the simulation runs fairly quickly but still fails shortly after starting the inlist_remove_env inlist.
> 
> Regards
> Kevin
> 
> 
> 
> run inlist_remove_env_header
> DATE: 2021-09-08
> TIME: 08:56:52
>  version_number 15140
>  read inlist_common
>  read inlist_remove_env
> load saved model co_core.mod
> 
>  net name co_burn_extras.net
>                                       atm_option: T_tau
>  kap_option gs98
>  kap_CO_option gs98_co
>  kap_lowT_option lowT_fa05_gs98
>                                         OMP_NUM_THREADS           8
> 
> 
> __________________________________________________________________________________________________________________________________________________
> 
>        step    lg_Tmax     Teff     lg_LH      lg_Lnuc     Mass       H_rich     H_cntr     N_cntr     Y_surf   eta_cntr   zones  retry
>    lg_dt_yr    lg_Tcntr    lg_R     lg_L3a     lg_Lneu     lg_Mdot    He_core    He_cntr    O_cntr     Z_surf   gam_cntr   iters  
>      age_yr    lg_Dcntr    lg_L     lg_LZ      lg_Lphoto   lg_Dsurf   C_core     C_cntr     Ne_cntr    Si_cntr  v_div_cs       dt_limit
> __________________________________________________________________________________________________________________________________________________
> 
>  retry: get_T_tau -- L <= 0     218
>                            1st model retry log10(dt/yr)    1.9433655775313161D+00
>         218   8.646679   7269.409  -8.732820   4.275459   5.628404   4.705068   0.000000   0.000000   0.304024  23.352630   1245      1
>    1.943366   8.308654   2.167485   4.108631   3.720191 -99.000000   0.923336   0.000000   0.664657   0.020108   4.610459     11
>  8.2747E+07   6.819880   4.735661   3.779196 -38.053989 -10.558169   0.883737   0.309484   0.001943   0.003286  0.000E+00         retry
>                                rel_E_err    2.2416142672395751D-12
>                        log_rel_run_E_err       -8.2444592886860644
> 
>  change to "basic.net"
>  number of species           8
>  change to "co_burn_extras.net"
>  number of species          11
>  relax_composition: num_steps_to_use         100
>                        avg remaining difference, lambda    1.3826074011976910D-01    2.2159478300766062D-03
>                        avg remaining difference, lambda    1.3822111582803542D-01    4.4318956601532124D-03
>                        avg remaining difference, lambda    1.3281973451293563D-01    8.8637913203064248D-03
>                        avg remaining difference, lambda    1.1312397138470173D-01    1.7727582640612850D-02
>                        avg remaining difference, lambda    9.4249900020676028D-02    3.1846390173839244D-02
>           5   7.156510   6966.155 -99.000000 -99.000000   0.924409   0.924409   0.654958   0.001289   0.285044  -1.719124    615      0
>    3.003956   7.156510  -0.104093 -99.000000 -99.000000 -99.000000   0.000000   0.262572   0.051097   0.020004   0.094109      4
>  2.0624E+03   1.954317   0.118481 -99.000000 -99.000000  -7.201780   0.000000   0.022646   0.001845   0.000777  0.000E+00    varcontrol
> 
>                        avg remaining difference, lambda    8.4894182615377151D-02    4.3355288974895476D-02
>                        avg remaining difference, lambda    7.9115082996726496D-02    4.5243692147515516D-02
>                        avg remaining difference, lambda    7.4287188689476327D-02    4.4701683644593947D-02
>                        avg remaining difference, lambda    6.9790573601704264D-02    4.7165367034079628D-02
> DATE: 2021-09-08
> TIME: 08:57:03
> 
> ******************************************************************
> failed to create co_wd.mod when running inlist_remove_env_header
> ******************************************************************
> 
> On Tue, Sep 7, 2021 at 5:00 PM Josiah Schwab <jwschwab at ucsc.edu <mailto:jwschwab at ucsc.edu>> wrote:
> Hi Kevin,
> 
> I'm trying to create a model of a ~0.9M white dwarf for further use in a binary simulation, and I can't find a test case in the test suite that will behave for the entire duration and produce a suitable saved model. Ideally I'd like to be able use something like 1M_pre_ms_to_wd or make_co_wd.
> 
> make_co_wd is likely to be the most suitable test case for doing this.  (A ~= 0.9 Msun WD descends from a ~= 5-7 Msun star, so is quite different from the 1Msun evolution.)
> 
> I'm using MESA release r15140, and I've made the necessary adjustments to the paths and the controls so that the test doesn't end prematurely. Other than that, I've left everything as is, including the initial masses. But the cases never run to completion - for example, the 1M_pre_ms_to_wd case only ever gets as far as the inlist_to_end_agb inlist, and behaves rather pathologically during that too.
> 
> I'm confused about your statement that you don't change the initial mass.  That is the critical thing to produce a more massive WD. 
> 
> Are you running all the parts of the test?  In r15140, this required setting the environment variable MESA_RUN_OPTIONAL (or editing the rn file so that all segments are executed).
> 
> Is there something fundamental that I'm not doing correctly? Are all these test cases meant to run more or less out of the box in this release of MESA?
> 
> The test cases are checked to run to completion out of the box exactly as is.  Ideally, the test cases would be robust to small changes in the parameters, but that is not always the case.
> 
> A design goal for make_co_wd is that it works for a range of masses.  I know I have run models with ZAMS masses ~6Msun in that test case, though I'm not certain it was in r15140.
> 
> I suggest you try editing the initial mass in make_co_wd (see inlist_common), running the whole thing (doing MESA_RUN_OPTIONAL=t ./rn) report back on how that goes.
> 
> Josiah
> _______________________________________________
> 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/20210908/3800bffb/attachment.htm>