[Mesa-users] ascending metallicity problem

Fri Dec 20 13:35:08 EST 2019

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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20191220/c15ea9d8/attachment.htm>