[Mesa-users] rel_run_E_err Warning

Fri May 8 17:49:39 EDT 2020

Hi Bill,

Ah, yes, we do indeed have diffusion turned on. Thank you for looking at
this! We'll confirm that turning the diffusion of lowers the
log_rel_run_E_err, but this makes a lot of sense, given where we see the
error begin to appear.

Many thanks to you all, we really appreciate the support!

Cheers,
Jen

On Fri, May 8, 2020 at 5:42 AM Bill Paxton <paxton at kitp.ucsb.edu> wrote:

> 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> 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/20200508/56922624/attachment.htm>