[mesa-users] convergence
Natasha Ivanova
nata.ivanova at ualberta.ca
Fri May 13 13:50:38 EDT 2016
Dear Bill
As a quick answer: no I only have a criterion in surface radius
convergence, but in my case it involves additional convergence on "surface
boundary conditions" triangle, as I use Kippenhah method, so it is linked
to effective temperature and luminosity.
To Frank I wanted to talk about the overall idea that decreasing the time
step is better then convergence, as from web page I understood that it
comes from him. It is fundamental to MESA as I understand, but is bound to
produce numerical noise equal to the residuals, and making produced stellar
models questionable. So when I listed variables to trace convergence I did
not mean just surface values, but the whole star. When I was doing in the
past simulations at the "edge", for specific case of fast nuclear burning,
I did have cases when a smaller timestep would take models to another
branch. Since then I flag models where residuals are bigger than the
temporal change, and in a typical run force time step to increase to have
temporal change be at least 10 times of residuals for traced variables, or
force to decrease residuals .
Best
Natasha
On May 13, 2016 11:25 AM, "Bill Paxton" <paxton at kitp.ucsb.edu> wrote:
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20160513/3ecb9c4a/attachment.html>
More information about the Mesa-users
mailing list