[Mesa-users] ascending metallicity problem

Fri Dec 20 14:54:35 EST 2019

Formally, there’s a whole set of literature on verification and validation of codes that comes from the computational and computational physics/engineering community (e.g. https://www.grc.nasa.gov/WWW/wind/valid/tutorial/verassess.html).

However, for the usual physicist’s approach, for a convergence test you pick some quantity/quantities of interest and figure out how fine of time-stepping and spatial-resolution you need to go until the answer doesn’t change within some tolerance.  To be safe it’s good to go a bit finer in spatial and time resolution to make sure you didn’t hit a local minimum or temporary plateau. What the quantities are and what tolerance you choose are up to you.  Practically, you’ll want to run a grid of calculations where you change nothing except for your time/spatial resolution controls. Var_control_target and mesh_delta_coeff are fan favorites (described in the appendix of instrumentation paper 2, along with the general mechanics of how time-steps and mesh resolution are determined).

Sometimes you’ll find that the answer is still changing and you can’t afford to go finer in time/space (e.g. when using a large reaction network). In that case, it is what it is and you note that somewhere. For instance, the 3D CCSN folks more or less need to do this all the time.

-Zach

----
Zach Meisel
Assistant Professor of Physics & Astronomy
Director, Edwards Accelerator Laboratory
Ohio University
Email: meisel at ohio.edu
Web: http://inpp.ohio.edu/~meisel

From: Croxmor Moraga via Mesa-users<mailto:mesa-users at lists.mesastar.org>
Sent: Friday, December 20, 2019 1:45 PM
To: anne.thoul at uliege.be<mailto:anne.thoul at uliege.be>
Cc: mesa-users<mailto:mesa-users at lists.mesastar.org>
Subject: Re: [Mesa-users] ascending metallicity problem

Thanks for the tip!
I will try using the last method you mentioned, but I want to know, how can I test it with that?

El vie., 20 dic. 2019 a las 7:16, anne.thoul at uliege.be<mailto:anne.thoul at uliege.be> (<anne.thoul at uliege.be<mailto:anne.thoul at uliege.be>>) escribió:
The fact that you get different results using different values for varcontrol_target means you should do a proper convergence study.
I would suggest that you plot the value of the timestep in both simulations as a function of time.
I would also suggest that you directly play with the timestep limit and number of mesh points and do a real convergence study.
You could use the mesh_delta_coeff and max_dt controls. I personally like those but there are many others to control the timestep and mesh size.
Decrease the tilmestep, increase the number of mesh points, and look at how your runs behave.

Cheers
Anne

Le 20 déc. 2019 à 05:17, Croxmor Moraga via Mesa-users <mesa-users at lists.mesastar.org<mailto:mesa-users at lists.mesastar.org>> a écrit :

Thank you for the clarification.
But the comparison I made between the two cases, was with the exact same parameters except for the varcontrol target parameter, everything else is the same. That's why I can't understand if the one I should use is the bigger one that matches previous works, with the same basic parameters or the smaller one that dismatchs the temperature for which happens the He-flash?

El vie., 20 dic. 2019 a las 0:31, Francis Timmes (<fxt44 at mac.com<mailto:fxt44 at mac.com>>) escribió:
> changing the variable control should only change the number of steps necessary to reach an exact moment of the simulation,

no.

here is what http://mesa.sourceforge.net/controls_defaults.html#varcontrol_target<https://nam03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmesa.sourceforge.net%2Fcontrols_defaults.html%23varcontrol_target&data=02%7C01%7Cmeisel%40ohio.edu%7Cd3ccb28b772442a3c36f08d7857ccc9a%7Cf3308007477c4a70888934611817c55a%7C0%7C1%7C637124643370199498&sdata=dw2Wc%2B9jkq5RxZpHhE7Zl4WKrgyqZqabKlNbF7L%2F7mA%3D&reserved=0> says:

> varcontrol_target
>
> This is the target value for relative variation in the structure from one model to the next.
> The default timestep adjustment is to increase or reduce the timestep depending on whether
> the actual variation was smaller or greater than this value.
>
> varcontrol_target = 1d-4

the first sentence essentially says varcontrol_target determines how accurately the equations are solved.
a smaller varcontrol_target means the equations are solved more accurately than they are with a larger varcontrol_target.

the second sentence essentially says that to achieve the specified relative variation,
the timestep is increased or decreased.

it is a mistake to think of varcontrol_target as merely scaling the timestep up or down.
a model with a small varcontrol_target will not necessarily reach the same evolutionary state
as a model with a large varcontrol_target.

showing how a model's results change with different mass and time resolutions
is an essential part of demonstrating convergence of one's results, and hence
plausible confidence in one's results. in your case, both values of varcontrol_target
are useful and telling you about the time resolution sensitivity of the results.

fxt

> On Dec 19, 2019, at 4:47 PM, Croxmor Moraga <rodrigo.moraga.merino at gmail.com<mailto:rodrigo.moraga.merino at gmail.com>> wrote:
>
> Hi again.
> The answer Francis gave me worked. But now that I repeated one of my simulations for a low metalicity, [Fe/H] = -2.26. It is known that when a star has a strong mass loss effect, the H1 envelope loss mass before reaching the He-flash, so this flash happens in higher temperatures, it will look like the star moves in the HR diagram in a horizontal line with the same Luminosity until it reaches the He-flash.
> So my problem is that at first when I used a varcontrol equal to 1*10^-3 the simulations were equal to the ones made in this paper: https://arxiv.org/pdf/astro-ph/9511017.pdf<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Farxiv.org%2Fpdf%2Fastro-ph%2F9511017.pdf&data=02%7C01%7Cmeisel%40ohio.edu%7Cd3ccb28b772442a3c36f08d7857ccc9a%7Cf3308007477c4a70888934611817c55a%7C0%7C1%7C637124643370199498&sdata=xxkW17NoPTc4O%2FTnt9bZdBRCFUbe1reDKQOh7v91PWI%3D&reserved=0> .
> But after changing my varcontrol equal to 5*10^-4 , the moment in which the star reaches the He-flash happens in higher temperature than the one it reaches before, so now my question is, changing the variable control should only change the number of steps necessary to reach an exact moment of the simulation, so how do I fix this, and if I can't, which varcontrol should I keep, the higher that match previous works, or the lower one that dismatch it?
>
> El mié., 11 dic. 2019 a las 17:02, Croxmor Moraga (<rodrigo.moraga.merino at gmail.com<mailto:rodrigo.moraga.merino at gmail.com>>) escribió:
> I have to thank you, it actually worked, but now I have to reduce my simulations to the first two inlist instead of passing to the 3rd one after the He-flash, depending of the case.
> It takes some more steps to reach where I want, but at least it completes the simulation.
> Thanks Francis.
>
> El mar., 10 dic. 2019 a las 20:46, Croxmor Moraga (<rodrigo.moraga.merino at gmail.com<mailto:rodrigo.moraga.merino at gmail.com>>) escribió:
> Thanks I will try it.
>
> El mar., 10 dic. 2019 19:31, Francis Timmes <fxt44 at mac.com<mailto:fxt44 at mac.com>> escribió:
> the error message from the inlists supplied is
>
> stop because power_he_burn >= power_he_burn_upper_limit
>     0.1018357506E+10    0.1000000000E+10
>
> as inlist_project sets power_he_burn_upper_limit = 1e9.
>
> ~~~
>
> getting through the he-flash takes better time resolution and thus patience.
> setting
>
> !power_he_burn_upper_limit = 1.0d9
> varcontrol_target = 5.0d-5
> max_model_number = 40000
>
> in inlist_projesct allows an r12115 run to get
> well past the initial, and strongest, he-flash.
>
> fxt
>
>
>
>
>
>
> > On Dec 10, 2019, at 11:18 AM, Croxmor Moraga via Mesa-users <mesa-users at lists.mesastar.org<mailto:mesa-users at lists.mesastar.org>> wrote:
> >
> > Ok. In a more extended explanation:
> > I am running a model for a low mass star, starting with a proto star, until it reaches the ZAMS state, then it changes to the next inlist which continue evolving the star until it reachs the He-flash, then once it have done that, it changes to the last inlist which make the model evolve until it's luminosity reaches the order of the 0.1 solar luminosities. This evolution has been done using both a simplified version of the reimers mass loss formula based on the paper of D'Cruz and Dorman et. al. 1995 and a more modern version of this equation based on Catelan. et al. 2013. Which are writed in my standard run extras. Everything was going ok, but since I stard testing the High metallicity cases I mentioned before, the model stops soon after it reaches the He-flash, and doesn't matter how many times I expand the min limit for dt, it is always the same, showing this:
> >  retry    1854
> >  gravedad superficial (cm/seg**2) =   1.0316990162999944
> >  m dot (msun/year) =   3.1658163634510211E-008
> >                                                      dt    7.7255210522695602-106
> >                                      min_timestep_limit    1.0000000000000000D-99
> >
> >  stopping because of problems dt < min_timestep_limit
> >
> >
> > terminated evolution: cannot find acceptable model
> >
> > termination code: min_timestep_limit
> > DATE: 2019-12-10
> > TIME: 13:07:51
> > I hope this helps to have a better understanding of what my problem is.
> > From beforehand, thank you all of you.
> >
> > El lun., 9 dic. 2019 a las 20:37, Josiah Schwab (<jwschwab at ucsc.edu<mailto:jwschwab at ucsc.edu>>) escribió:
> > But recently once I perfomed this simulations for a metalicity of [Fe/H] = 0 and over, my star models trowns an error short after the star reaches the He-flash, and I have tried a lot fo things to repair this, but I have failed.
> >
> > Please describe the error and briefly describe what you tried.
> >
> > Your inlists are appreciated, but it is helpful for us to get some feel of what is going on without having to run them.
> >
> > Josiah
> > _______________________________________________
> > mesa-users at lists.mesastar.org<mailto:mesa-users at lists.mesastar.org>
> > https://lists.mesastar.org/mailman/listinfo/mesa-users<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mesastar.org%2Fmailman%2Flistinfo%2Fmesa-users&data=02%7C01%7Cmeisel%40ohio.edu%7Cd3ccb28b772442a3c36f08d7857ccc9a%7Cf3308007477c4a70888934611817c55a%7C0%7C1%7C637124643370209492&sdata=8oOaMew%2Fu8b2pBPOHhVvwBzTJLuGr7fjgBZ61JB%2FjLM%3D&reserved=0>
> >
>
_______________________________________________
mesa-users at lists.mesastar.org<mailto:mesa-users at lists.mesastar.org>
https://lists.mesastar.org/mailman/listinfo/mesa-users<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mesastar.org%2Fmailman%2Flistinfo%2Fmesa-users&data=02%7C01%7Cmeisel%40ohio.edu%7Cd3ccb28b772442a3c36f08d7857ccc9a%7Cf3308007477c4a70888934611817c55a%7C0%7C1%7C637124643370209492&sdata=8oOaMew%2Fu8b2pBPOHhVvwBzTJLuGr7fjgBZ61JB%2FjLM%3D&reserved=0>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20191220/2ebfb68e/attachment-0001.htm>