[Mesa-users] ascending metallicity problem

Wed Jan 8 17:18:39 EST 2020

Hello everyone, it's been a while since I speak with you through this
string of email. But the thing is I have this question I don't know how to
solve: the thing is that like I said before I am evaluating different
values of the reimers coefficient for the mass loss process in the RGB and
the HB for the model low mass star, but once I ascended through higher
metalicities, I had to use a smaller varcontrol target, first in almost all
my previous test I used a varcontrol target of the order of 5* 10**-4, but
on one of my test, I checked that if I realize the same simulation but
changing the varcontrol, with a smaller one the calcule is more precise,
but the road the star takes in the hr diagram, so I don't know which
varcontrol target should I use, and how it will affect my research if as I
use a different value for varcontrol target for each new test, as I had too
for high metalicity tests.
Which metallicity should I keep, the higher and less precise one, that
match better with the paper I am basing my job, or the more precise one
which doesn't match as much as the other one?
Help me people, what should I do?
(I attached 2 images for the same simulation, except that for one
varcontrol target is equal to 1*10**-3 and for the other one is equal to
9*10**-4 as can be seen in the file name. Also I attached my inlists and
run_star_extras, but in the high metallicity case I arranged it so the
simulation happens mainly in the inlist_project, passing directly to the
last one, without using inlist_to_wd)
Regards, and from beforehand thank you for your help people.

El vie., 20 dic. 2019 a las 16:54, Meisel, Zach (<meisel at ohio.edu>)
escribió:

> 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 <mesa-users at lists.mesastar.org>
> *Sent: *Friday, December 20, 2019 1:45 PM
> *To: *anne.thoul at uliege.be
> *Cc: *mesa-users <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 (<
> 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> 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>)
> 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> 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>) 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>) escribió:
> > Thanks I will try it.
> >
> > El mar., 10 dic. 2019 19:31, Francis Timmes <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> 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>)
> 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
> > > 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
> 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/20200108/eb12b850/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hr_giant_004785_varcontrol_equal_to_1_plus_d-3.png
Type: image/png
Size: 4798 bytes
Desc: not available
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20200108/eb12b850/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hr_giant_005075_varcontrol_equal_to_9_plus_d-4.png
Type: image/png
Size: 4857 bytes
Desc: not available
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20200108/eb12b850/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: inlist_to_wd
Type: application/octet-stream
Size: 10040 bytes
Desc: not available
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20200108/eb12b850/attachment-0005.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: inlist_start
Type: application/octet-stream
Size: 8560 bytes
Desc: not available
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20200108/eb12b850/attachment-0006.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: inlist_project
Type: application/octet-stream
Size: 6444 bytes
Desc: not available
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20200108/eb12b850/attachment-0007.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: inlist_to_turn_off_mass_loss
Type: application/octet-stream
Size: 10118 bytes
Desc: not available
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20200108/eb12b850/attachment-0008.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rn2
Type: application/octet-stream
Size: 833 bytes
Desc: not available
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20200108/eb12b850/attachment-0009.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: run_star_extras.f
Type: text/x-fortran
Size: 20215 bytes
Desc: not available
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20200108/eb12b850/attachment-0001.bin>