[Mesa-users] ascending metallicity problem

Thu Jan 9 07:01:32 EST 2020

Thanks a lot!
I will check that convergence tests

El jue., 9 ene. 2020 8:55, Francis Timmes <fxt44 at mac.com> escribió:

> you are comparing extreme horizontal branch mesa models with
> those published in a 1996 apj article by d’cruz et al that used
> a modified version of the non-lagrangian/lagrangian STEV software
> instrument,
> https://ui.adsabs.harvard.edu/abs/1996ApJ...466..359D/abstract .
>
> the STEV instrument is not generally available so we don't know
> what goes on in detail, the article does not provide enough information
> to say what mass and time resolution was used at any given phase of
> evolution,
> and a convergence study of the results is not presented.
> i also opine that the article is a lovely body of work.
>
> for certain mass and time resolutions you find that the mesa models
> agree with those by d’cruz et al at the chi-by-eye level in the hr digram.
> that’s great. this verifies the d’cruz et al results and gives some
> confidence that the mesa models are on the right track.
>
> you also find that when the mass and time resolution is increased
> that the results in the hr diagram change. this is normal and expected
> in the absence of a convergence study that has demonstrated the quantities
> of interest are robust with respect to changes in the mass and time
> resolution.
>
> > 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?
>
> its not a matter of choosing one or the other.
> both are providing useful scientific information.
>
> what you could do, should do, is systematically vary the
> mass and time resolution, and plot the results to demonstrate
> convergence in the hr-digram. at minimum do this convergence study
> for one metallicity and one reimers coefficient. then you will have
> numerically defensible result for the chosen physics that may, or may not,
> agree with the d’cruz et al results. if they do not, you will the results
> to answer why not.
>
> clearer?
>
> fxt
>
>
>
>
>
>
> > On Jan 8, 2020, at 3:18 PM, Croxmor Moraga via Mesa-users <
> mesa-users at lists.mesastar.org> wrote:
> >
> > 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
> > Sent: Friday, December 20, 2019 1:45 PM
> > To: anne.thoul at uliege.be
> > Cc: mesa-users
> > 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 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 .
> > > 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
> > > >
> > >
> >
> > _______________________________________________
> > mesa-users at lists.mesastar.org
> > https://lists.mesastar.org/mailman/listinfo/mesa-users
> >
> >
> >
> >
> >
> >
> <hr_giant_004785_varcontrol_equal_to_1_plus_d-3.png><hr_giant_005075_varcontrol_equal_to_9_plus_d-4.png><inlist_to_wd><inlist_start><inlist_project><inlist_to_turn_off_mass_loss><rn2><run_star_extras.f>_______________________________________________
> > mesa-users at lists.mesastar.org
> > https://lists.mesastar.org/mailman/listinfo/mesa-users
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20200109/4cb44d8a/attachment-0001.htm>