[Mesa-users] ascending metallicity problem

Fri Dec 20 05:16:45 EST 2019

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 <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 <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 <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://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 <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://lists.mesastar.org/mailman/listinfo/mesa-users>
> > > 
> > 
> 
> _______________________________________________
> 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/20191220/831d0cb3/attachment-0001.htm>