[mesa-users] convergence

[Bill Paxton]

Hi Natasha,

I'm delighted to get you involved even if I had to piss you off to get it to happen. ;)

We can definitely make this better with your help.  And it doesn't need to wait until the KITP conference next year although that will be a good chance to work together -- I'm looking forward to it.

Pablo will be a postdoc at Northwestern starting in the fall, so it will be easier to get together with him as well -- he's the prime author of the binary mass transfer in mesa with me as assistant.  You are welcome to talk to Frank about it, but this isn't his part of the system.

One quick question for now: when you take into account multiple variables to decide convergence (obviously the right thing to do), do you include the difference between surface radius and roche radius?  Seems like the main problem you see in the current mesa implicit scheme is that it only considers that one criterion, but it is presumably one of several that should be considered -- with change in Mdot from one step to the next being another I presume.   or do you just consider model variables like surface P, R, T, and L that then determine mdot without explicitly including mdot in the convergence criteria?

I'm looking forward to your input -- always great to hear from someone with hands-on experience.  Please educate us. ;)

Cheers,
Bill





On May 13, 2016, at 10:05 AM, Natasha Ivanova wrote:

> Hi all,
> 
> This is a followup to the question that my student Kenny sent yesterday.
> 
> I understand perfectly how implicit and explicit scheme MT work in principle (per say, implicit scheme has some roots from my code way back in the past), however the oscillations in the MT rate that MESA has are the purely numerical feature of MESA. The fact that they are shown by people in MESA tutorials does not validate the oscallations, just demonstrates that this is a big unfixed problem. A similar issue was fixed in other binary codes ages ago, and I believe the nature is the same -- having a too small time step rather then improving convergence. Generally speaking, I do not understand why this concept was accepted for MESA as it did not work well for previous stellar codes, but we can have a longer discussion with Frank in a few months when we both will be at KITP for a long time. 
> 
> Let us see that on the  simple example.  I use real data from MESA.
> 
> age                                            radius
> 5.018075106014762074e+06 4.813512093255021829e-01
> 5.026973111848642118e+06 4.812979394829801083e-01
> 5.035887099594448693e+06 4.812442647659711525e-01
> 5.044816387584990822e+06 4.811937099257804773e-01
> 5.053761369794959202e+06 4.811492877224504694e-01
> 5.062721936671409756e+06 4.811004430349119509e-01
> 5.071697463133651763e+06 4.810552508037580499e-01
> 5.080688271018664353e+06 4.810112151819854742e-01
> 5.089694798251089640e+06 4.808135777471279626e-01
> 
> Do you see the jump in the last model? This is because the accumulated numerical noise from all the previous models (any number 0.000x is meaningless here, and one can trust only to 0.001), as in all of the models,  iterations were *stopped once* the residual (?) becomes "acceptable". 
> 
> So, the models have a kind of common "offset" from the true value, and the offset from the true value is growing with each model till it reaches 0.001. While this jump in radius is OK for single star evolution, this offset causes MT rate to jump by a factor of 10. 
> 
> This is because the true change in the radius dR/dt due to physics is comparable to numerical noise epsilon_R, where dt is the timestep and epsilon_R is accepted in each model residual.If one decreases timestep, then the effect of the numerical noise is only increasing for the MT calculations.
> 
> The way how it is fixed in other mass transfer codes, is to increase the number of iterations (getting to a smaller epsilon_R) while increasing by all possible means dt. Then obtained dR/dt has less artificial noise on it and represents better what MT is. This is especially so for the implicit methods, and this is exactly why the implicit method was introduced in Ivanova and Taam 2004 - to boost the timestep compared to the explicit method while removing the numerical oscillations! One has to understand that by its nature, an implicit method is meaningless when the timestep is getting too small, and if one makes timestep too small, then anything what one gets out of its could be a numerical artifact.
> 
> I am really surprised the astroseismology studies did not run into the same problem with small timesteps producing a bunch of artificial waves, with those waves even having *period* that can be traced back to the timestep and convergence. And generally, for whenever your accepted change of variables between the models is smaller than the residual, it must be worrisome and been flagged by the code!
> 
> Anyway, the standard and easy fix that should be done is the introduction of regidly enforced minimum timestep in the way that the model is first iterated to the first strong criterion, then accepted even if the convergence is at least OK by the second criterion, and it does not decrease the timestep below the minimum value.
> 
> If I understand correctly, then the use of
> 
> tol_correction_norm = 1.e-7
> tol_max_correction = 1.e-5
> tol_residual_norm1 = 1d-7
> tol_max_residual1 = 1d-6
> iter_for_resid_tol2 = 200
> tol_residual_norm2 = 1d99
> tol_max_residual2 = 1d99
> 
> should force the code first do 200 interaction before decreasing the timestep , and that should help the MT issue. The problem here of course that there is only one parameter for all. It is more sense if, as in other codes, the user could manage *which* variables he/she needs to keep at a tighter convergence.  I used to have different set of values of acceptable tolerance during MT calculations, and definitely such values are not the same for all main variables. Having four variables for which one can give different values: P, R, T, L should make the code flexible enough to attend various problems, not just MT. 
> If I miss some other conditions for the solver, please correct me, but without enforced minimum timestep is will not work anyway.
> 
> Best
> Natasha
> 
> 
>  
> ------------------------------------------------------------------------------
> Mobile security can be enabling, not merely restricting. Employees who
> bring their own devices (BYOD) to work are irked by the imposition of MDM
> restrictions. Mobile Device Manager Plus allows you to control only the
> apps on BYO-devices by containerizing them, leaving personal data untouched!
> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j_______________________________________________
> mesa-users mailing list
> mesa-users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mesa-users