[Mesa-users] rates confusion and soul searching

[Aaron Dotter]

Hi again,

@Rob, thanks for your suggestion.  I changed the reaclib file but it didn't
noticeably change the result in 11701.  The mystery continues . . .


I have put together a minimal working example in case anyone would like to
help me figure this out.  Attached is a very minimal inlist and starting
model.

When I run this with a more recent revision (12155), it is able to sustain
a reasonable timestep throughout core H-burning.  However, it accumulates a
large error.  Maybe this is relevant; I don't know.

When I run the same with 11701, it starts doing retries and backups around
model #730.  It ends with a min_timestep_limit at 750.

When I then turn on debugging output to the terminal, still in 11701, it
rather dramatically changes the result.  The model still struggles (shorter
timesteps, more retries + backups) but it is able to keep going up until
the stopping condition at model #1000.

One final note is that I'm no longer suspicious that this is related to
weak reactions.  I tried setting the T9_weaklib_full_on/off to 1.0 and
nothing changed.


Changing MESA revisions is not a viable option at this point -- I need to
get this working in 11701 if at all possible.


Thanks,
Aaron


On Tue, Oct 22, 2019 at 4:30 PM Rob Farmer <r.j.farmer at uva.nl> wrote:

> Hi,
>
> What happens if you try one of the older JINA/REACLIB files (see
> $MESA_DIR/data/rates_data) jina_reaclib_filename =
> 'jina_reaclib_results_v2.2' for the previous version.
>
> Rob
>
> On Tue, 22 Oct 2019 at 16:08, Aaron Dotter via Mesa-users <
> mesa-users at lists.mesastar.org> wrote:
>
>> Hi folks,
>>
>> I'm having one of those Heisenbug days, where I just can't figure out
>> what I'm doing wrong.  Hoping that some can point me in a productive
>> direction.  I'm running a model that I've recently run successfully, where
>> "success" is defined as making it through core H-burning without any reties
>> or backups in about 1000 timesteps.  Using rev 11701 with the 20190830 SDK,
>> gfortran 9.2.0.
>>
>> I'm using pp_and_cno_extras.net with JINA rates (new_rates_preference=2)
>> in a low-mass star (0.7 Msun) starting from the pre-main sequence.
>> Normally this cruises through core H-burning without issue.  Today it
>> grinds to a halt, evolutionarily-speaking, when the core T goes above ~10^7
>> K (logdt < 0) and starts doing lots of retries.  I'm also using
>> set_initial_xa_from_file to set the initial abundances for all species in
>> the inlist -- this has caused some surprises in the past (looking at
>> boron-8 here).
>>
>> I don't have a MWE at the moment but if this drags on into tomorrow, I'll
>> make one.
>>
>> When the run starts, before listing the rate cache files written by MESA,
>> I get these two lines printed to the terminal, over and over again maybe
>> hundreds of times:
>>
>> r_ne18_wk_f18 failed in do_jina_reaclib     321
>> r_ne19_wk_f19 failed in do_jina_reaclib     324
>>
>> I've tried removing/cleaning caches (data/rates_data/cache, my
>> MESA_CACHES_DIR, and .mesa_temp_cache in my work directory).  This doesn't
>> fix the problem.
>>
>> If I switch to NACRE (new_rates_preference=1 then the model evolves as I
>> would like it to.  This and the error message make me think I've run afoul
>> of some weird rates problem.
>>
>> If confronted with this problem, what would you try next?
>>
>> Thanks!
>> Aaron
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20191023/40a28018/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: start.mod
Type: audio/x-mod
Size: 634450 bytes
Desc: not available
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20191023/40a28018/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: inlist_project
Type: application/octet-stream
Size: 788 bytes
Desc: not available
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20191023/40a28018/attachment-0001.obj>