[mesa-users] Undocumented control in &controls: eos_partials_consistency_level

[Warrick Ball]

Hi Bill,

Brilliant explanation, thanks very much!  It's clear that I misinterpreted 
"consistency" as thermodynamic consistency, rather than a kind of 
numerical consistency.  I tried a solar calibration with level 1 and it 
made no difference whatsoever (as expected, I guess).

Thanks for taking the time to explain in such detail.

Cheers,
Warrick


------------
Warrick Ball
Postdoc, School of Physics and Astronomy
University of Birmingham, Edgbaston, Birmingham B15 2TT
wball at bison.ph.bham.ac.uk
+44 (0)121 414 4552

On Fri, 7 Apr 2017, Bill Paxton wrote:

> Hi Warrick,
>
> On Apr 7, 2017, at 2:49 AM, Warrick Ball wrote:
>
>> Hi everyone,
>>
>> I'm still tinkering with solar models and noticed that I get quite a big
>> difference if I switch the opacity interpolation between linear and cubic
>> in X and Z.
>
> Good detective work!   Interesting to note that the "calibrated" results depend on the details of the non-physical numerics.  This is particularly noticeable for the eos and opacity results that depend on interpolating tables that are relatively sparse reflecting decisions made 20+ years ago taking into account the amount of RAM required to store them at runtime -- machine memory sizes have increased by factors of 10 while the tables are still at a resolution appropriate for a much different era.  The low resolution of the tables makes the results more vulnerable to interpolation issues.
>
>> Motivated by the recent thread on the interpolation of the
>> EoS [1] I tried digging around inside the EoS module to see what options
>> were available for deciding which interpolation to use in the EoS.
>
>>
>> Along the way, I came across the control eos_partials_consistency_level in
>> &controls.  The documentation is empty [2] and the only test cases that
>> change its value from the default -1 are ccsn_IIp and envelope_inflation
>> (both of which set it to 1).  I assume consistency refers to thermodynamic
>> consistency.  My question to the forum is: what does this control do?
>>
>> In principle, if I work through the code for long enough I should be
>> able to figure out what's going on.  But it'll be much faster if someone
>> else could explain it...  Just searching for consistency_level in
>> $MESA_DIR/eos/private/eosdt_eval.f90, it looks to me that as
>> consistency_level increases, so the order of derivatives that are
>> thermodynamically consistent increases too.  At consistency_level = 1 or
>> 2, the first derivatives are made consistent, and for consistency_level =
>> 3, the second derivatives are made consistent too.  I don't understand
>> what happens above level 4, though.  My suspicion is that a different kind
>> of interpolation is implemented for levels 4, 5 and 6 but I'm hoping
>> someone can correct me.
>
>
>
> For an implicit solver like mesa/star, we need to have partials of the tabulated values as well as the basic values themselves -- for example, in addition to the value of the entropy as a function of logT and logRho,, we also need partials of the entropy with respect to logT and logRho.  And the same holds for values that are themselves partials of top level values (energy, gas pressure, entropy) such as adiabatic gradient, grad_ad.
>
>
> In the case of the eos, the tables try to help with this by providing columns of data for the partials in addition to values for the top level values.  This has the value of giving you highly accurate values of the partials at grid points, but it doesn't solve the problem of interpolating to off grid locations. For mesa/star, we need to have the partials of the interpolating polynomial since that tells us how the results will behave when we make calls to the eos with slightly different arguments.  But the standard practice is to have the eos return interpolation of the partials instead of partials of the interpolating polynomials.   Seems like a minor difference that might actually be an improvement since it is using the information from the table.  But this means that the reported partials based on interpolating the tabulated partials will not be precisely the same as the partials of the interpolants -- in other words, the results will not be consistent, the reported part!
 ials will not be an accurate representation of the actual partials of the interpolated values even if they might be a better estimate of the values of the partials that would be calculated by the original routines that produced the data for the table.  Got it?
>
> We have just muddled along with this inconsistency, but it has a downside.  Since mesa/star doesn't get accurate partials it cannot drive down the errors in the stellar models beyond the level set by the uncertainties.  This shows up in the residuals stalling in the newton iterations --- we cannot make the residuals tiny if we cannot predict how the new model because of imprecise partials.  For "normal" work, the inconsistencies in the partials are small enough that we just accept the failure to get tiny partials, i.e., we accept the failure to get models that solve the equations at the level of tiny residual errors.  But for "the era of high precision stellar astrophysics" we need something better.  We need to have consistent partials from the input physics for the eos.
>
> The "eos_partials_consistency_level" control is a part of an attempt to improve this situation.  As is the fate of most 1st efforts, it failed.   So this problem is still waiting for a good solution.  In the meantime we have a not-very-good partial semi-fix that sort-of works for a few special cases.  This is the "consistency_level = 1" option.  The higher number options have gone away in my current working version (not yet public).  But this one is still around since it is the least ambitious of the things we tried and at least helps sometimes.   It replaces the interpolated values of Cv, dS_dT, chiR, choRho, and gamma3 by expressions caclulated on the fly from the partials of the interpolants of lnE, lnS, and lnPgas.  Those particular cases are easy to do in that they don't require 2nd derivatives of lnE, lnS, or lnPgas.  So we do the easy ones and leave the rest alone (i.e., leave them as interpolated from tables rather than partials of interpolants).  The small section!
  of code for this is in subroutine finish_partials in eos/private//eosdt_eval.f90.
>
> You are of course welcome to try setting consistency level = 1.  It helps some cases and breaks others.  It is not a solution, and it is not even a very good workaround.
>
> The problem of consistent partials from the eos is still with us, and until it is solved, we will be vulnerable to limited ability to drive down residual errors in the equations in mesa/star.
>
> Finally, note that the situation in opacities is less difficult since we don't need 2nd derivatives of the opacity, and the tables don't include partials so there is no issue of interpolating tabulated partials.  The problem here is not the consistency of the partials, it is the low resolution of the tables increasing the opportunity for effects from different interpolating algorithms.   Going to higher order interpolation can help to a limited degree, but it introduces the danger of unphysical values caused by large jumps in the tabulated values such as at the hydrogen ionization temperature where the opacity drops sharply for small decreases in T.   Fine resolution in the tables is really the right solution, at least until we can do away with tables and just calculated everything on the fly (not going to happen soon).
>
> Cheers,
> Bill
>
>
>
>
>
>
>>
>> Cheers,
>> Warrick
>>
>> [1] https://sourceforge.net/p/mesa/mailman/message/35754574/
>> [2] http://mesa.sourceforge.net/controls_defaults.html#eos_partials_consistency_level
>>
>>
>> ------------
>> Warrick Ball
>> Postdoc, School of Physics and Astronomy
>> University of Birmingham, Edgbaston, Birmingham B15 2TT
>> wball at bison.ph.bham.ac.uk
>> +44 (0)121 414 4552
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> mesa-users mailing list
>> mesa-users at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mesa-users
>
>