[Mesa-users] rel_run_E_err Warning

Mon May 4 16:07:07 EDT 2020

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 <mailto: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 <mailto: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 <mailto: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 <mailto:mesa-users at lists.mesastar.org>
> >> https://urldefense.com/v3/__https://lists.mesastar.org/mailman/listinfo/mesa-users__;!!KGKeukY!ipaYn4IY1MG7yu0_mxlNicrfkO3gmZSILAJFUAwWSseP034Uq7x91fd7YDgqhGttrCMgcq1FUDvpYw$ <https://urldefense.com/v3/__https://lists.mesastar.org/mailman/listinfo/mesa-users__;!!KGKeukY!ipaYn4IY1MG7yu0_mxlNicrfkO3gmZSILAJFUAwWSseP034Uq7x91fd7YDgqhGttrCMgcq1FUDvpYw$> 
> >> 
> > 
> 
> _______________________________________________
> mesa-users at lists.mesastar.org <mailto:mesa-users at lists.mesastar.org>
> https://urldefense.com/v3/__https://lists.mesastar.org/mailman/listinfo/mesa-users__;!!KGKeukY!ipaYn4IY1MG7yu0_mxlNicrfkO3gmZSILAJFUAwWSseP034Uq7x91fd7YDgqhGttrCMgcq1FUDvpYw$ <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
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20200504/87123076/attachment.htm>