[mesa-users] New approx21 in MESA

Bill Paxton paxton at kitp.ucsb.edu
Wed Jun 18 17:13:02 EDT 2014


Just to finish this off: as you know the Cr56 in approx21 serves the role of a neutron rich end product.  It is produced by a fake reaction that pretends to do electron captures on Fe56:   Fe56 + 2 electrons => Cr56

The Ye value of Cr56 is 24/56 = 0.428.  By replacing Cr56 by a different neutron sink isotope, you can push the final Ye profile of the model to something else.  For example, if you use approx21_cr65 (Cr65 Ye = 24/65 = 0.369) then you'll probably see lower Ye's in the core at collapse.  These are implemented in the nets as fake reactions that include capture of free neutrons -- e.g., Fe56 + 2 electrons + 9 neutrons => Cr65.

The existence of a family of approx21 nets reflects the fact that these nets are not going to tell you exactly what the core Ye should be at collapse.  But by selecting the Ye rich sink, you can push the results in a desired direction if for independent reasons you have an idea of what Ye you want to get.   See mesa/data/net_data/nets/approx21_*.net for pre-supplied nets --- you can make others by creating a new file following the same pattern.

To get an estimate of the Ye profile from the evolution run itself, you need a much larger net --- probably on the order of 200 isotopes (I spent much of last year trying to get around this, but failed).   Now with the new release, you can try running a large net in mesa/star -- although you still need to use the reaction rate limits as we've been discussing (I'm working on that).   You might try the various mesa_*.net options starting small and working up to see how sensitive your results are to net size. 

Of course the runtimes go up as you increase the net size -- how much it goes up will depend on your machine (more cores help).   If the net size goes up by 10, you expect the run time to go up by at least a factor of 10 (if time is dominated by things like net rates that scale like number of isotopes); but it is likely to go up even more if the runtime is dominated by matrix operations --- and that will probably be the case.  So expect long runs.

-Bill



On Jun 18, 2014, at 1:43 PM, Bill Paxton wrote:

> 
> On Jun 18, 2014, at 1:40 PM, Manos Chatzopoulos wrote:
> 
>> Hi Bill,
>> 
>>  Thanks - that's very useful. So basically just use 
>> 
>>  ! high center T limit to avoid negative mass fractions
>>          sig_min_factor_for_high_Tcenter = 0.01
>>           ! inactive when >= 1d0
>>             ! if Tcenter >= Tcenter_min_for_sig_min_factor_full_on,
>>             ! then okay to reduce sig by as much as this factor
>>             ! as needed to prevent causing negative abundances
>>          Tcenter_min_for_sig_min_factor_full_on = 2d9
>>             ! if Tcenter >= this, factor = sig_min_factor_for_neg_abundances
>>             ! this should be > Tcenter_max_for_sig_min_factor_full_off.
>>          Tcenter_max_for_sig_min_factor_full_off = 1d9
>>             ! if Tcenter <= this, factor = 1, so has no effect
>>             ! this should be < Tcenter_min_for_sig_min_factor_full_on.
>>          ! for T > full_off and < full_on, factor changes linearly with Tcenter
>> 
>> in my inlist exactly as you indicated in your last e-mail.
> 
> 
> 
> Yes --- and that's been part of inlist_massive_defaults for a long time.
> 
> You should try turning it off by commenting out the setting for sig_min_factor_for_high_Tcenter.
> 
> See what happens during core si burning without the mixing limits.
> 
> -B
> 
> 
> 
> 
>> 
>> Best,
>> 
>> Manos
>>> Damn --- last second screwup in my previous message.   I got ahead of myself in the last comment.   We DO still need the limits on mixing at high T.   I'm looking at getting rid of that requirement and my fingers wrote that we'd already reached that goal.  not yet.   
>>> 
>>> So we no longer need the limits on reaction rates at high T but we do need the limits on mixing.  
>>> 
>>> Hope that helps.
>>> 
>>> -B
>>> 
>>> 
>>> Begin forwarded message:
>>> 
>>>> From: Bill Paxton <paxton at kitp.ucsb.edu>
>>>> Date: June 18, 2014 1:34:23 PM PDT
>>>> To: Manos Chatzopoulos <manolis at flash.uchicago.edu>
>>>> Cc: mesa-users at lists.sourceforge.net
>>>> Subject: Re: [mesa-users] New approx21 in MESA
>>>> 
>>>> 
>>>> On Jun 18, 2014, at 12:58 PM, Manos Chatzopoulos wrote:
>>>> 
>>>>> Dear all,
>>>>> 
>>>>>  In the last release it was indicated that:
>>>>> 
>>>>> "re implement approx21 for better performance and numerical stability 
>>>>> using Frank's code as basis.
>>>>> introduce quad precision calculation of dydt"
>>>>> 
>>>>>  So, in principle just calling the star_job option
>>>>> 
>>>>> new_net_name = 'approx21.net'
>>>>> 
>>>>>  Will automatically allow the newly implemented and improved version of 
>>>>> the approx21 network to run right? Nothing
>>>>> else special flag options need to be turned on?
>>>> 
>>>> Correct.
>>>> 
>>>> 
>>>>> 
>>>>>  Is that supposed to enhance numerical performance toward the very late 
>>>>> stages of stellar evolution (past core Si/S burning?)
>>>> 
>>>> Note the following from release message:
>>>> 
>>>> Begin forwarded message:
>>>> 
>>>>> reimplement approx21 for better performance and numerical stability using Frank's code as basis.
>>>>> introduce quad precision calculation of dydt
>>>>> 
>>>>> remove high T reaction rate limits. 
>>>>> can now run fully coupled approx21 models to core collapse without it.
>>>>> but note that we still have high T limits on convective coeffs
>>>> 
>>>> The star test suite cases that run approx21 models to core collapse are no longer using T limits.
>>>> I'm working on the issue of limits on mixing at high T.
>>>> These were turned on by the following lines in inlist_massive_defaults; we no longer need them.
>>>> 
>>>>          ! high center T limit to avoid negative mass fractions
>>>>          sig_min_factor_for_high_Tcenter = 0.01
>>>>           ! inactive when >= 1d0
>>>>             ! if Tcenter >= Tcenter_min_for_sig_min_factor_full_on,
>>>>             ! then okay to reduce sig by as much as this factor
>>>>             ! as needed to prevent causing negative abundances
>>>>          Tcenter_min_for_sig_min_factor_full_on = 2d9
>>>>             ! if Tcenter >= this, factor = sig_min_factor_for_neg_abundances
>>>>             ! this should be > Tcenter_max_for_sig_min_factor_full_off.
>>>>          Tcenter_max_for_sig_min_factor_full_off = 1d9
>>>>             ! if Tcenter <= this, factor = 1, so has no effect
>>>>             ! this should be < Tcenter_min_for_sig_min_factor_full_on.
>>>>          ! for T > full_off and < full_on, factor changes linearly with Tcenter
>>>> 
>>>> 
>>>> 
>>>> -Bill
>>>> 
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20140618/bb3fc5ca/attachment.html>


More information about the Mesa-users mailing list