[mesa-users] off-center Ne and O burning (again…)

Bill Paxton paxton at kitp.ucsb.edu
Mon Apr 22 14:56:25 EDT 2013


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
>> 
>> !DSPAM:10228,5174459526489317621427!
>> 
> 





More information about the Mesa-users mailing list