[mesa-users] Messing with the hydro solver

[Bill Paxton]

On Sep 22, 2015, at 11:01 AM, Matthew Clayton wrote:

> Hi there,
> 
> First, a quick thank you to Bill for getting hydro_rotation.f90 to use cgrav, it seems to be behaving itself fine now.

excellent.

> 
> Now, I have some questions about the hydro solver; I'm trying to get the solver to sacrifice accuracy in order to get it through difficult evolutionary stages without slowing down too much,


okay --- but it is easy to relax tolerances too much and find the code getting trapped in dead-ends where it has accepted as series of increasingly bad models and finally gets to a place where it cannot find a next step solution at any tolerance.  relaxed tolerances can paradoxically lead to more backups and slower running.  

finally, and importantly, even if you get through the tough parts by reducing tolerances, how can you know whether you have garbage when you are done?  

so, with that skeptical preamble, i'll try to answer your questions.


> so my questions are about ways the solver is failing:
> 
> 1. I can change the tolerances for residuals and corrections as acceptance criteria, but if the corrections get too big the solver fails with "avg corr too large". When this seems to depend on the product of the parameters scale_correction_norm and corr_param_factor which are set in private_defaults.inc. They are labelled for "experts only". What bad things will happen if I mess with them? And if I want to change the threshold for "avg corr too large", which one of the two should I preferentially mess with?


the location (private_defaults) and the comment (experts only) are a warning that we are on thin ice here, but let's give it a try:

         ! the remaining hydro controls are for "experts only"
            tiny_corr_coeff_limit = 5
            corr_coeff_limit = 1d-2
            tiny_corr_factor = 2


"tiny corrections" are an attempt to deal with extreme non-linearity that can result in a new solution vector that produces worse residuals rather than better.  assuming continuous partial derivatives, the vector can be trusted to point in the direction of improved residuals for sufficiently small displacements that reduce the nonlinear effects, but going too far in the direction of the solution vector can fall victim to nonlinearity.  there is a short mention of this in the 1st mesa paper (2011) in section 6.3.   

it sounds wonderful to have a "globally convergent scheme", but in practice it can lead to such slow convergence that we are better off without it.  mesa is currently setup to use the tiny corrections option only after a retry, and even then it only tries a few tiny corrections in a row before giving up -- the parameter 'tiny_corr_coeff_limit' sets this number.  The normal correction coefficient is 1.0; the reduced corrections have a value for the coefficient less than 1.0 so that only a fraction of the correction vector is applied to change to trial solution.  The line-search algorithm that selects the coefficient is limited to a minimum value set by the parameter 'corr_coeff_limit'.  If the coefficient is sufficiently larger that the minimum limit, then it doesn't count as a "tiny" correction; the factor that determines this 'tiny_corr_factor' -- i.e., if the correction coefficient is <= tiny_corr_factor* corr_coeff_limit, then it is counted as a tiny correction and can therefore trigger the tiny_corr_coeff_limit that will terminate the iterations.

Note that if corr_coeff_limit == 1.0, then reduced corrections are disabled; this is the method by which we turn off the line-search for cases other than just after a retry.  The actual logic for this is found in evolve.f90; when 'skip_global_corr_coeff_limit' is true, then  the solver doesn't try any reduced corrections because we use 1.0 instead of the current value of corr_coeff_limit.  If skip_global_corr_coeff_limit is false, then we use the value of corr_coeff_limit.  If you want to turn off small corrections in all situations, you can change the control corr_coeff_limit to be 1.0.  

            skip_global_corr_coeff_limit = (first_try .or. &
                (just_did_backup .and. s% number_of_backups_in_a_row == 1) .or. &
                (s% model_number_for_last_retry /= s% model_number &
                .and. .not. just_did_backup)) ! last alternative is for redo's


There are 3 more "private -- experts only" solver controls in private_defaults; let's consider them too while we are at it.

            scale_correction_norm = 0.1
            corr_param_factor = 10
            scale_max_correction = 1d99

Sometimes the solver gets lost and suggests huge corrections that are (almost) certainly bogus.  This can happen because of extrapolating the linear approximation to estimate a correction for a very nonlinear problem.  The solver provides an option to check for such situations and terminate the iterations rather than go on with a lost cause.  The test for this is correction_norm > corr_param_factor*scale_correction_norm.  It is also an option to reduce an overly large correction rather than terminate the iterations.  If correction_norm*correction_factor > scale_correction_norm, then correction_factor = scale_correction_norm/correction_norm.  Similarly, if max_correction*correction_factor > scale_max_correction, then correction_factor = scale_max_correction/max_correction.

As to the question of which of these you should mess with, my 1st response would be "none of them".  But if you want to explore, that's great too; just be ready to try lots of things and spend a lot of time reading the code.  Most of the changes you try will make things worse, but you might get lucky and find something that helps.

            
> 
> 2. Sometimes the solver fails due to "tiny corrections". The default for how many tiny corrections you're allowed in a row seems to be 5 (tiny_corr_coeff_limit), but in a couple of places in the test suite it's set to 999,999. What's wrong with tiny corrections and why shouldn't I set this to a big number?

see above.


> 
> 3. Occasionally the solver fails with "adjust_correction failed in eval_equations". A little digging suggests that this happens when the microphysics modules are asked to provide values for things like reaction rates under physical conditions that are outside their acceptable input ranges (the errors come from routines like do_neu and do_ne). Is this right? Or can this happen under other circumstances?


the routine "adjust_correction" is where we add in the correction vector to get a new trial solution and then call 'eval_equations' to see what we get with this new attempt.  if the correction vector leads us into horribly bad trial solutions we will get in trouble when we call the microphysics (e.g., the eos rejects things like density of 10^67 or temperature of 10^-17).  The trial solution can cause troubles in a variety of ways, but failures in microphysics are the most common.

Cheers,
Bill




> 
> Thanks,
> Matthew
> ------------------------------------------------------------------------------
> _______________________________________________
> mesa-users mailing list
> mesa-users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mesa-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20150922/5f8f2871/attachment.html>