[mesa-users] off-center Ne and O burning (again…)
Stan Woosley
woosley at ucolick.org
Mon Apr 22 18:33:22 EDT 2013
Agreed,
We have found too that the final presupernova star for a massive
progenitor may vary significantly with compiler flags for round off and precision,
the degree of optimization, the compiler, and even the machine
hardware. Usually these variations are not great, but sufficient that we don't
feel comfortable carrying out surveys of evolution on more than one machine at
a time or with more than one version of the code.
This "chaos", so anti-Russell-Vogt in nature, is worthy of its own study.
We tried for a time, but the possibilities were too great. In some sense
stellar evolution studies are "statistical".
However the variations we have seen are not nearly enough to make
a 15 Msun star look like an 11 Msun star for the same code physics.
Stan
On Apr 22, 2013, at 3:09 PM, Falk Herwig <fherwig at uvic.ca> wrote:
> This is fine, I think. Just be aware that if you turn on convective boundary mixing (overshooting) the overshooting implementation does not know how large the convection zone is that is seeding the extra mixing. One may consider it unreasonable to have a convective boundary mixing layer that has more Hp than the underlying convection zone.
>
> Another comment re: "I am surprised that this result is different in this version compared to the last version ...". The stellar evolution problem, especially towards the advanced phases, is a highly nonlinear, multi-physics problem. As such it has the potential to show chaos-like behavior (small differences in initial conditions can lead significant/noticeable differences later on). Equally, small differences in implementation, each of which represent "reasonable" choices and physics interpretations, can create noticeable differences later on. Here is an example: a while back when we were switching from intel 11 to 12 compilers we checked the impact on AGB evolution. The same version of MESA would produce different result in terms of Teff and L on the advanced AGB. In the end I believe it was related to overly aggressive optimization of floating point arithmetic in intel 11.
>
> Hardening codes to avoid these kind of issues is not impossible, but has to be done on a case by case basis, and may entail significant effort.
>
> F.
>
>
> On 2013-04-22, at 11:56, Bill Paxton <paxton at kitp.ucsb.edu> wrote:
>
>> Hi,
>>
>> I've now run the mesa/star test_suite and found that most cases were happy
>> with turning off pruning of tiny convection zones and turning off removing glitches.
>> There were 4 that failed unless I turned on okay_to_remove_mixing_singleton.
>> That is one of the "remove_mixing_glitches" operations; I was able to disable
>> all of the other ones and just allow removal of singletons. This is of course
>> with prune_bad_cz_min_Hp_height = 0. So with these settings, it only
>> prunes cases where a single point is convective and both of its neighbors
>> are radiative.
>>
>> I'm certainly not endorsing the default settings as reflecting the "real" physics,
>> but in light of our lack of anything better, it does seem reasonable to
>> set the defaults to do as little as we can get away with, at least until
>> the fog clears a bit more (Dave, we are waiting.)
>>
>> So in the next release I'll have the following defaults unless there
>> are loud screams of protest:
>>
>> ! remove tiny convection zones unless have strong nuclear burning
>> ! i.e., remove if size < prune_bad_cz_min_Hp_height .and.
>> ! max_log_eps < prune_bad_cz_min_log_eps_nuc
>> prune_bad_cz_min_Hp_height = 0 ! lower limit on radial extent of cz (<= 0 to disable)
>> ! in units of average pressure scale height at top and bottom of region
>> prune_bad_cz_min_log_eps_nuc = -99 ! lower limit on max log eps nuc in cz
>> ! this allows emergence of very small cz at site of he core flash, for example.
>>
>>
>> ! apply smoothing to abundances in newly nonconvective regions
>> smooth_convective_bdy = .true.
>> max_delta_limit_for_smooth = 0.1
>> ! don't smooth across a region where any mass fraction changes by more than this limit
>>
>>
>> remove_mixing_glitches = .true. ! if true, then okay to remove gaps and singletons
>>
>> ! the following controls are for different kinds of "glitches" that can be removed
>>
>> okay_to_remove_mixing_singleton = .true.
>>
>> clip_D_limit = 0 ! 1 ! zero mixing diffusion coeffs that are smaller than this
>>
>> min_convective_gap = -1 ! 0.1
>> ! close gap between convective regions if smaller than this (< 0 means skip this)
>> ! gap measured radially in units of pressure scale height
>>
>> min_thermo_haline_gap = -1 ! 0.1
>> ! close gap between thermohaline mixing regions if smaller than this (< 0 means skip this)
>> ! gap measured radially in units of pressure scale height
>>
>> min_thermo_haline_dropout = -1 ! 5 ! <= 0 disables this
>> max_dropout_gradL_sub_grada = 1d-3
>> ! if find radiative region embedded in thermohaline,
>> ! and max(gradL - grada) in region is everywhere < max_dropout_gradL_sub_grada
>> ! and region height is < min_thermo_haline_dropout
>> ! then convert the region to thermohaline
>>
>> min_semiconvection_gap = -1 ! 0.1
>> ! close gap between semiconvective mixing regions if smaller than this (< 0 means skip this)
>> ! gap measured radially in units of pressure scale height
>>
>> remove_embedded_semiconvection = .false.
>> ! if have a semiconvection region bounded on each side by convection,
>> ! convert it to be convective too.
>>
>>
>>
>> Bill
>>
>>
>>
>>
>>
>>
>>
>> On Apr 21, 2013, at 5:06 PM, Tuguldur Sukhbold wrote:
>>
>>> thanks everyone for the fruitful discussion!
>>>
>>> I have just tried my 15Msun with this parameter completely turned off, and my alpha_mlt=2 case is burning Ne and O in the core nicely with 4906! In the alpha_mlt=1 case, the CO core got a bit larger compared to my older run, but it wasn't big enough to overcome the off-center burning.
>>>
>>> In my understanding, decrease of this parameter should produce a larger CO core, thus promoting regular central Ne and O burning. But I am a bit confused about why in version 4798, where this parameter was set to 1.0, I was able to get central burning.
>>>
>>> MESA version alpha_mlt=1 alpha_mlt=2 prune_bad_cz_min_Hp_height
>>> 4798 y n 1.0
>>> 4906 y y 0.1
>>> 4906 y n 0.0
>>> 4917 y n 0.1(?)
>>>
>>>
>>>
>>> Tuguldur
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Apr 21, 2013, at 1:00 PM, Bill Paxton <paxton at kitp.ucsb.edu> wrote:
>>>
>>>> Hi Stan,
>>>>
>>>> good advice. I went part way by reducing that parameter, but your
>>>> suggestion is to turn it off completely -- which can be done by setting
>>>>
>>>> prune_bad_cz_min_Hp_height = 0
>>>>
>>>> along the same lines, it would be worth changing the following controls to .false.
>>>>
>>>> remove_mixing_glitches = .true. ! if true, then okay to remove gaps and singletons
>>>> okay_to_remove_mixing_singleton = .true.
>>>>
>>>> Let's try it. Tug, Jakob, Josh, and others: please give this a try and let us know.
>>>> I'll run the mesa test suite with these changes and see what happens there.
>>>>
>>>> Bill
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Apr 21, 2013, at 12:43 PM, Stan Woosley wrote:
>>>>
>>>>> Just a thought. When semi convection is small or turned off in a code
>>>>> the response is often to create many small alternating convection zones,
>>>>> often only a few zones thick. These come and go out of phase and
>>>>> act as a staircase that can mimic the effects of semiconvective mixing. I think
>>>>> Icko Iben first saw this many years ago.
>>>>>
>>>>> Anyway, it may not be a good scheme to ignore convection anywhere
>>>>> that the gradients say it should occur, even if its just a few zones.
>>>>>
>>>>> Stan
>>>>>
>>>>>
>>>>>
>>>>> On Apr 21, 2013, at 12:52 AM, Jakub Ostrowski <ostrowski at astro.uni.wroc.pl> wrote:
>>>>>
>>>>>> Hi!
>>>>>>
>>>>>> I'm working almost exclusively on 15 M_s models and I have found quite a big difference between the v4906 and previous ones too - but somewhere else than you.
>>>>>>
>>>>>> I studied properties of models after depletion of central H, logTeff ~ 4.30, logL ~ 4.63. The behavior of Brunt-Vaisala frequency is much smoother in v4906 than before and finally now there is convection where it should be according to behavior of gradients.
>>>>>>
>>>>>> And this is due to one change in controls.default. Now there is
>>>>>>
>>>>>> prune_bad_cz_min_Hp_height = 0.1 ! lower limit on radial extent of cz
>>>>>>
>>>>>> whereas previously the value was 1.0. I don't know if this is useful for you but for me this previously overlooked parameter made a huge change in case of my model. But it seems there is no dramatic influence on the shape of track on HRD.
>>>>>>
>>>>>> Take care,
>>>>>> Jakub
>>>>>>
>>>>>> On 21 kwi 2013, at 06:59, Tuguldur Sukhbold <sukhbold at ucolick.org> wrote:
>>>>>>
>>>>>>> Dear MESA users,
>>>>>>>
>>>>>>> I am getting 2 different results with the exact same inlist for two different versions of the code: 4798 and the current 4906. Since MESA is constantly being developed, I understand that we should expect changes between the versions. However I am little surprised to see such a 'big' change in two releases came out almost one after the other.
>>>>>>>
>>>>>>> The attached plot shows the central T-Rho plane evolution for 15Msun model with the following simple inlist:
>>>>>>>
>>>>>>> &star_job
>>>>>>>
>>>>>>> mesa_dir = ''
>>>>>>> create_pre_main_sequence_model = .true.
>>>>>>>
>>>>>>> set_rate_c12ag = 'Buchmann'
>>>>>>> num_special_rate_factors = 1
>>>>>>> reaction_for_special_factor(:) = 'r_c12_ag_o16'
>>>>>>> special_rate_factor(1) = 1.2
>>>>>>>
>>>>>>> eos_file_prefix = 'mesa'
>>>>>>> kappa_file_prefix = 'gs98'
>>>>>>>
>>>>>>> / !end of star_job
>>>>>>>
>>>>>>> &controls
>>>>>>>
>>>>>>> initial_mass = 15
>>>>>>> initial_Z = 0.02
>>>>>>> initial_Y = 0.25
>>>>>>>
>>>>>>> mixing_length_alpha = 2
>>>>>>>
>>>>>>> RGB_wind_scheme = 'Nieuwenhuijzen'
>>>>>>> AGB_wind_scheme = ''
>>>>>>> RGB_to_AGB_wind_switch = 1d-4
>>>>>>> Nieuwenhuijzen_wind_eta = 1.0d0
>>>>>>>
>>>>>>> photostep = 50
>>>>>>> profile_interval = 25
>>>>>>> history_interval = 1
>>>>>>> terminal_interval = 10
>>>>>>> write_header_frequency = 10
>>>>>>>
>>>>>>> !hign
>>>>>>> ! xa_central_lower_limit_species(1) = 'h1'
>>>>>>> ! xa_central_lower_limit(1) = 0.72
>>>>>>> !hdep
>>>>>>> ! xa_central_lower_limit_species(1) = 'h1'
>>>>>>> ! xa_central_lower_limit(1) = 0.01
>>>>>>> !heign
>>>>>>> ! xa_central_upper_limit_species(1) = 'c12'
>>>>>>> ! xa_central_upper_limit(1) = 0.01
>>>>>>> !hedep
>>>>>>> ! xa_central_lower_limit_species(1) = 'he4'
>>>>>>> ! xa_central_lower_limit(1) = 0.01
>>>>>>> !cign
>>>>>>> ! log_center_temp_limit = 8.69897 !0.5d8K
>>>>>>> !cdep
>>>>>>> log_center_temp_limit = 9.07918 !1.2d9K
>>>>>>> !odep
>>>>>>> ! xa_central_lower_limit_species(1) = 'o16'
>>>>>>> ! xa_central_lower_limit(1) = 0.05
>>>>>>>
>>>>>>> /
>>>>>>>
>>>>>>> If you guys remember, I have previously brought up the issue of off-center O burning, in the case of alpha_mlt = 1, in version 4798. This behavior was gone if I set this parameter to alpha_mlt = 2, as it creates a larger CO core. However, when I try to recreate the older results with the current version of MESA - 4906 - I am facing the off-center burning issue again with alpha_mlt = 2.
>>>>>>>
>>>>>>> In the response to my previous email, Bill has reported that he got the same result (no off-center burning) with alpha_mlt=2 in his version of MESA - 4917.
>>>>>>>
>>>>>>> MESA version alpha_mlt=1 alpha_mlt=2
>>>>>>> 4798 y n
>>>>>>> 4906 y y
>>>>>>> 4917 y n
>>>>>>>
>>>>>>> (yes/no to off-center Ne and O burning)
>>>>>>>
>>>>>>> I haven't seen anything in the release email from Bill for 4906, that might be relevant to what I see here.
>>>>>>>
>>>>>>> In general, 15Msun is a funny mass in MESA. It is sitting on the border of two different paths of evolutions of CO core: (1) degeneracy is important and off-center burnings of Ne and O as we've seen (2) degeneracy effects are no longer important and everything ignites in the center first. In other words, 15Msun model essentially with all the default settings, is producing a CO core mass that borderlines these two paths. This is why changing parameters here and there are producing these rather big changes for this 15Msun case. I don't think one will see this behavior in bigger mass models in any version of the code with any alpha_mlt, simply because the CO core will be big enough.
>>>>>>>
>>>>>>> From my experience, this funny mass is usually much lower in other codes, more like in the 8-12Msun range.
>>>>>>>
>>>>>>> Tuguldur
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> <inc.png>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Precog is a next-generation analytics platform capable of advanced
>>>>>>> analytics on semi-structured data. The platform includes APIs for building
>>>>>>> apps and a phenomenal toolset for data science. Developers can use
>>>>>>> our toolset for easy data analysis & visualization. Get a free account!
>>>>>>> http://www2.precog.com/precogplatform/slashdotnewsletter_______________________________________________
>>>>>>> mesa-users mailing list
>>>>>>> mesa-users at lists.sourceforge.net
>>>>>>> https://lists.sourceforge.net/lists/listinfo/mesa-users
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Precog is a next-generation analytics platform capable of advanced
>>>>>> analytics on semi-structured data. The platform includes APIs for building
>>>>>> apps and a phenomenal toolset for data science. Developers can use
>>>>>> our toolset for easy data analysis & visualization. Get a free account!
>>>>>> http://www2.precog.com/precogplatform/slashdotnewsletter
>>>>>> _______________________________________________
>>>>>> mesa-users mailing list
>>>>>> mesa-users at lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/mesa-users
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Precog is a next-generation analytics platform capable of advanced
>>>> analytics on semi-structured data. The platform includes APIs for building
>>>> apps and a phenomenal toolset for data science. Developers can use
>>>> our toolset for easy data analysis & visualization. Get a free account!
>>>> http://www2.precog.com/precogplatform/slashdotnewsletter
>>>> _______________________________________________
>>>> mesa-users mailing list
>>>> mesa-users at lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/mesa-users
>>>>
>>>>
>>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Precog is a next-generation analytics platform capable of advanced
>> analytics on semi-structured data. The platform includes APIs for building
>> apps and a phenomenal toolset for data science. Developers can use
>> our toolset for easy data analysis & visualization. Get a free account!
>> http://www2.precog.com/precogplatform/slashdotnewsletter
>> _______________________________________________
>> mesa-users mailing list
>> mesa-users at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mesa-users
>
> ------------------------------------------------------------------------------
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> _______________________________________________
> mesa-users mailing list
> mesa-users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mesa-users
>
> !DSPAM:212,5175b5a7269582353316103!
>
More information about the Mesa-users
mailing list