[Mesa-users] rates confusion and soul searching

[Aaron Dotter]

Hi Frank,

with what version, and when, did this model run to your satisfaction?
>

Setting aside the large accumulated error, this particular model runs to my
satisfaction with 12155.

Your question inspired me to dig into the compilation date and related
details.  There is one inconsistency that is worth looking into further.
I'm onto that now.


This saga began with a model that ran satisfactorily to completion with
11701 on 2019-10-01.

I tried to run the same inlist again on Monday (2019-10-21), *after
recompiling star*, and started seeing all of these retries and backups
during core H-burning.

Here is the history file header of the successful run:

              version_number                     compiler
     build             MESA_SDK_version                         date
                       11701                   "gfortran"
   "8.3.0"      "x86_64-linux-20190830"                   "20191001"

This is wrong: 20190830 corresponds to GCC 9.2.0 while 20190503 corresponds
to 8.3.0.  MESA is reporting correctly the version of GCC used to compile
the executable but it's picking up the current version of the SDK I have
installed. The two are inconsistent in the header.  I hadn't noticed the
inconsistency until now, which is why I thought the compiler and SDK were
the same between my 10/01 and 10/21 runs.

20190503 was released simultaneously with 11701; whereas 20190830 was
several days before 12115.

I'll write again as soon as I can confirm or deny the SDK/compiler version
is related to the issue.  My bad for not having noticed this before.

Aaron






> @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
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20191023/0d336944/attachment.html>