[Mesa-users] rel_run_E_err Warning

Bill Paxton paxton at kitp.ucsb.edu
Fri May 8 11:42:41 EDT 2020 

Hi Jen,

In my previous emails I’ve suggested problems with partials from input physics modules as a major source of problems with converence of the newton solution to a highly accurate solution to the equations.  That was a big issue in the past and is still in some situations, but we’ve made a lot of progress in the last tew years to improve the partials.  In particular, for your case, input physics partials are not the issue at all.  I’ve been looking at the simplex_solar_calibration test case to see how rel_run_E_err behaves there.  It turns out the newton solve is just fine; the problems are arising before we even start the newton iterations.   

There are other things that go on during a step.  We start by remeshing, and that will introduce small changes to the total E.  Consider for example the potential energy of the model.  Theoretically, that’s an integral, but we of course approximate it by a sum over cells.  Such a sum will only be approximate and will change when you change the set of cells.  We try to partially compensate for that by adjusting the internal energy to keep the total E constant.  But of course that means an unrealistic transfer to/from internal to potential.  So remeshing introduces small effects on E.   But usually they are very small.  And for the solar model it looks like they are not an important issue.

After remesh and before the newton iterations, we do several other optional computations.  Ideally these could be included in the newton iterations, but for practical/numerical reasons they are “split” off and done separately.  For some of these, such as mass loss/gain, we are carefully accounting for change in total E of the model.  But for some we currently neglect any changes they might make, assuming that the changes are small enough to neglect.  One example of this is element diffusion.  Since it changes composition of cells, it will in general change their internal energy.   And in the simplex_solar_calibration test case, this turns out to be the primary source of rel_E_err.    With element_diffusion on, I see a typical per step rel_E_err of 4e-6.  With it off, that drops to 5e-13.   

If you are using element_diffusion, you might try the same experiment: change do_element_diffusion from .true. to .false. — what do you now get for log_rel_run_E_err at the end of the run?

Obviously this is a problem in our accounting for E rather than a failure of the code to get high accuracy results.  We should count the change in E caused by element_diffusion as an expected part of the E budget rather than report it as an error.  So the warnings you have been getting about excessive log_rel_run_E_err are not an indication of problems in your models; they are a false alarm and an indication that we need to fix the accounting in mesa.

Thank you for reporting the issue.  We’ll now get to work to fix it.

Thanks
Bill






> On May 7, 2020, at 6:11 PM, Jennifer Van Saders <vansaders at astronomy.ohio-state.edu> wrote:
> 
> 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 <mailto: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 <mailto: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 <mailto: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/20200508/4bea2d15/attachment.htm>

More information about the Mesa-users mailing list