[Mesa-users] rates confusion and soul searching
Aaron Dotter
aaron.dotter at gmail.com
Wed Oct 23 13:28:48 EDT 2019
Hi again,
It turns out that it was, indeed, related to the SDK and compiler. I get
the desired result with GCC 8.3.0 and the 20190503 SDK.
Since it also works with a recent, non-release version (12155) and the
20190830 SDK, I presume that whatever issues that led to my problem with
11701 have been fixed.
I think I'll leave it there for now unless anyone wants to dig deeper.
Mainly, this was on me for getting my SDKs crossed.
I have started a discussion here:
https://github.com/orgs/MESAHub/teams/developers
regarding that situation.
Aaron
On Wed, Oct 23, 2019 at 12:24 PM Rob Farmer <r.j.farmer at uva.nl> wrote:
> So if you switch to using approx21 (and with JINA) for your net things go
> smoothly. So there is something going on with the reactions in
> pp_and_cno_extras.net that are not in approx21.
>
> Attached is the expanded version of the pp_and_cno_extras.net network. At
> this point I would usually start going though and commenting out rates and
> seeing if issues persist. So first you should see what reactions are in
> pp_and_cno_extras.net and not in approx21.net (list_net_reactions=.true.)
> and then turn each of those reactions of one by one.
>
> Rob
>
> On Wed, 23 Oct 2019 at 11:29, Francis Timmes via Mesa-users <
> mesa-users at lists.mesastar.org> wrote:
>
>> hi aaron,
>>
>> with what version, and when, did this model run to your satisfaction?
>>
>> fxt
>>
>>
>>
>>
>> > On Oct 23, 2019, at 7:39 AM, Aaron Dotter via Mesa-users <
>> mesa-users at lists.mesastar.org> wrote:
>> >
>> > 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
>> >
>> >
>> >
>> <start.mod><inlist_project>_______________________________________________
>> > 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
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20191023/c167e578/attachment.html>
More information about the Mesa-users
mailing list