[Mesa-users] rel_run_E_err Warning

Thu May 7 21:11:46 EDT 2020

Dear Bill,

Thanks for this email - this really helps me to understand a bit better
what this is actually telling me, although it's taken some time to process
it. The thing that's still a bit surprising to me is that this is a very
solar star - solar mass, solar composition, solar age. Gold tolerances are
on. I wouldn't have thought we're in particularly ugly regions for the EOS,
or any of the other input physics... but perhaps I haven't appreciated the
lack of precision, even at solar conditions.

I'll be sure to respond to this thread if we arrive at a solution that is
anything other than living with it... but don't expect any beautiful new
input tables ;)

Cheers,
Jen

On Mon, May 4, 2020 at 10:07 AM Bill Paxton <paxton at kitp.ucsb.edu> wrote:

> Hi Jen,
>
> Let me take a shot at answering this question as it’s an important one.
>  And keep in mind that this is just me (a retired Computer Scientist), not
> some official MESA statement.
>
> First of all, the “E” in rel_run_E_err is the mesa/star rough analog of
> total energy but should not be thought of as an attempt to capture
> everything a physicist would want to consider as the actual star (physical)
> total energy.  The report for E_err is an indication of how well the
> mesa/star numerics are able to reduce residuals in order to find highly
> accurate solutions to the given set of stellar equation approximations it
> is using along with the given set of approximate input physics it is using
> (kap, eos, net, …).  For a perfect numerical world with precise input
> physics values and partials and precise solutions to equations that are
> written to ensure conservation E for true solutions, E_err could be as
> small as you want; unfortunately this isn’t a perfect world (you may have
> noticed).  The main limits on our ability to drive E_err toward 0 is the
> accuracy of the partial derivatives that go into the Jacobian matrix that
> is at the heart of the incremental improvement of trial models.  If the
> partials are limited in accuracy, then the newton solution will be limited
> also.  The progress towards a true solution can stall while the solution is
> still not satisfying the equations to a high precision.
>
> Since E is analogous to total energy, it makes a good test of the numerics
> since it should be conserved in a manner similar to the conservation of
> physical total energy.  So we can check both how well the numerics are
> working on a per step basis and on a cumulative basis for an entire run.
>  In most of the test suite, the cases are able to run well while keeping
> the cumulative E_err small.  But not always and not for all cases.  We
> continue to work on areas where E_err gets “bad" - often this involves
> trying to improve the issues with input physics where we have to blend
> results from different sources.  The eos is particularly challenging for
> this.
>
> So, finally to get to your question, the messages about rel_run_E_err are
> intended to let you know about cases where mesa/star isn’t able to drive
> the approximate solutions to a user specified level of accuracy. Your
> concern about E_err should be matched by a concern about the uncertainties
> in the input physics and the physics left out by the approximate equations
> we are solving in the 1D approximation.
>
> Unfortunately, if the rel_run_E_err numbers seem dangerously large to you
> for your application, there isn’t much you can do other than provide
> replacements for the current mesa input physics (e.g., if you have some
> spare time, we could use an eos that covers the entire T-Rho range without
> the need for blends!).   Make sure you set use_gold_tolerances = .true.,
> but even that can only make the newton solver try harder with what it
> already has.  If it is stalling because of poor partials, then letting it
> grind for more iterations won’t help anything.  For the same reason,
> smaller timesteps or smaller zones aren’t likely to help either if you get
> into a situation where the input to the solver isn’t good enough.
>
> I’ll be interested to hear from you about what you decide to do about this
> issue.    We continue to put a lot of effort into making things better, but
> they are not quite perfect yet. ;-)    If you would like me to look at a
> specific case, I’d be happy to poke around to see if I can determine the
> source of the problem.  Perhaps I can suggest a work around.  But even if
> there’s no simple short term fix, knowing where the problems lie is a start
> toward developing a solution.
>
> Cheers,
> Bill
>
>
>
>
>
>
> On May 4, 2020, at 12:18 PM, Jennifer Van Saders <
> vansaders at astronomy.ohio-state.edu> wrote:
>
> Dear Frank,
>
> When should we be concerned that the rel_run_E_err is thrown? Is there a
> community best practice for solar models as to what this threshold should
> be? And, if we're not happy with where it is now, is the best path
> forward increasing the mess points and decreasing timesteps?
>
> Thanks!
>
> Jen
>
> On Sat, May 2, 2020 at 7:33 AM Francis Timmes via Mesa-users <
> mesa-users at lists.mesastar.org> wrote:
>
>> hi erica,
>>
>> of course one should be aware of the potential issues when turning off
>> warnings.
>>
>> for the second item, in your inlist_astero_search_controls, there is
>>
>>        ! terminate if simplex gets "small" enough
>>        simplex_x_atol = 1d-10 ! tolerance for absolute differences
>>        simplex_x_rtol = 1d-10 ! tolerance for relative differences
>>
>> these might be too small relative to when you seek to terminate.
>> perhaps experiment with larger values, at least until one of the astero
>> experts comment.
>>
>> fxt
>>
>>
>>
>>
>>
>>
>> > On May 2, 2020, at 8:34 AM, Francis Timmes <fxt44 at mac.com> wrote:
>> >
>> > hi erica,
>> >
>> > for the first item, one can consider using
>> >
>> > ! silence energy warnings
>> >     warn_when_large_rel_run_E_err = 1.0d99
>> >     warn_when_stop_checking_residuals = .false.
>> >
>> > fxt
>> >
>> >
>> >
>> >
>> >> On May 1, 2020, at 12:45 PM, Erica Sawczynec <ericasaw at hawaii.edu>
>> wrote:
>> >>
>> >> Hi all!
>> >>
>> >> I am working with the astero module using MESA 12115 and MESASDK
>> 20190830. I am trying to model a star with individual pulsation
>> frequencies, but I am running into a few problems:
>> >> 1) Throughout each iteration (from pre-main sequence to within the
>> error box) I noticed an energy conservation warning: "WARNING:
>> rel_run_E_err". The warning continues even when fitting the seiesmic
>> frequencies.   When looking through some of the documentation for MESA I
>> noticed a few things that might help this error: a. using gold tolerances
>> and b. using the dedt form of the energy eq. After turning both of these
>> parameters on, the warning still appears. Further, to check it was not a
>> problem with my particular inlist, I also ran the MESA test suit for
>> example-astero and found the same warning all the way up the main sequence.
>> >>
>> >> 2) I am also having difficultly getting the astero module to stop
>> modeling once the parameters have converged. I am unsure what parameters to
>> change that will end the entire run. I have tried: changing the chi2 search
>> limits, changing the number of simplex iterations, changing the
>> sigmas_coeff values for all the parameters, and changing the chi2 relative
>> increase limit. Right now I just plot all the output values from the
>> simplex results file and wait until I see the values have converged before
>> I end the run (see the image convergence.png).
>> >>
>> >> Here is some information about my os:
>> >> NAME="CentOS Linux"
>> >> VERSION="7 (Core)"
>> >> ID="centos"
>> >> ID_LIKE="rhel fedora"
>> >> VERSION_ID="7"
>> >> PRETTY_NAME="CentOS Linux 7 (Core)"
>> >>
>> >> Below I have attached a text file that shows the terminal outputs for
>> my star on the main sequence to right before the astero module begins a new
>> model with a different combination of starting parameters.
>> >> I have also attached my inlist_astero and my
>> inlist_astero_search_controls so you can see all the parameters that are
>> set.
>> >>
>> >> Thanks so much!
>> >> Erica
>> >>
>> >>
>> <covergence.png><inlist_astero.txt><inlist_astero_search_controls.txt><terminal_output.txt>_______________________________________________
>> >> mesa-users at lists.mesastar.org
>> >>
>> https://urldefense.com/v3/__https://lists.mesastar.org/mailman/listinfo/mesa-users__;!!KGKeukY!ipaYn4IY1MG7yu0_mxlNicrfkO3gmZSILAJFUAwWSseP034Uq7x91fd7YDgqhGttrCMgcq1FUDvpYw$
>> >>
>> >
>>
>> _______________________________________________
>> mesa-users at lists.mesastar.org
>>
>> https://urldefense.com/v3/__https://lists.mesastar.org/mailman/listinfo/mesa-users__;!!KGKeukY!ipaYn4IY1MG7yu0_mxlNicrfkO3gmZSILAJFUAwWSseP034Uq7x91fd7YDgqhGttrCMgcq1FUDvpYw$
>>
>> _______________________________________________
> mesa-users at lists.mesastar.org
> https://lists.mesastar.org/mailman/listinfo/mesa-users
> <https://urldefense.com/v3/__https://lists.mesastar.org/mailman/listinfo/mesa-users__;!!KGKeukY!lVtk6G0bagrBjrQQ_E4yzD7Nd1ww4fDXpOy5vUWE9XrwEZwTHzYVemRNtrQoFfZ7OfZh4cHETh-6Eg$>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20200507/7063bce2/attachment.htm>