[mesa-users] Question about abundances in the 1 Msun test problem
paxton at kitp.ucsb.edu
Wed Aug 6 19:39:36 EDT 2014
On Aug 6, 2014, at 3:08 PM, Francis Timmes wrote:
> alternative options, which may not be the best options for this
> particular case, are a) renormalizing the abundances of whatever
> network is being used to sum to unity and b) putting any nonconservation
> into an existing istope, say h1. both approaches avoid adding a dumping ground.
Good suggestions. Here's yet another way to avoid having a dump isotope without changing X and Y values --- assign all of the metals solar abundances and then renormalize them to give Z = 1 - (X + Y). For the case we've been looking at, this gives the following starting abundances for standard o18_and_ne22.net without an added "dump" isotope:
This preserves the solar relative abundances such as Ne20/Mg24 while increasing all the metal abundances to make up for the missing isotopes. The absolute values have jumped a bit: e.g., Ne20 from 1.9423584493049016D-03 to 2.3248824409470140D-03.
Those values can be compared to what we currently get for o18_and_ne22.net using the dump into most massive scheme:
I'll add flag to let users pick between "dump missing metals in the most massive" vs. this one, "renormalize metals to make up for missing ones".
I wonder what will break if I change the default behavior from dumping to renormalizing? ;D
> On Aug 6, 2014, at 2:49 PM, Bill Paxton <paxton at kitp.ucsb.edu> wrote:
>> Hi Manos,
>> Turns out that we need to treat create_pre_main_sequence_model differently when it comes to changing the net.
>> Normally, change net works with an existing model and adds or removes isotopes from an existing set. And when it encounters a newly added isotope it gives it an adjusted solar abundance, but it only makes minimal adjustments to isotopes that were already in the net.
>> That works fine most of the time, but it leads to the problems you've noted. I think it will work if we change things so that the create PMS routine knows to use the new net rather than what it does now which is to use "basic.net".
>> That's part of the solution. The other part is to use a net that contains heavier elements. All heavy elements not in the net get dumped into the abundance of the heaviest one that is in the net. So we need to provide at least 1 element heavier than mg24 -- e.g. mg26 or si28 or even zn60, it doesn't really matter what you pick since it will just be an inert placeholder for "all things heavy". That will give a better value for mg24 but will give a strangely large abundance for whatever you have added since it now is the dumping place for all heavier isotopes.
>> For example, here's a possible net you can create:
>> include 'o18_and_ne22.net'
>> it just adds zn60 to the o18_and_ne22 net.
>> then with a few magic changes to mesa/star so that create_pre_main_sequence_model uses the new net instead of basic.net, I get these starting abundances:
>> h1 6.9999999999999996D-01
>> he3 2.9797635251138618D-05
>> he4 2.7997020236474884D-01
>> c12 3.4416106108120406D-03
>> n14 1.0081585468366041D-03
>> o16 9.3393731281944965D-03
>> o18 2.1073480945478206D-05
>> ne20 1.9423584493049016D-03
>> ne22 1.5710150039274719D-04
>> mg24 7.9962893561223670D-04
>> zn60 3.2906953479015129D-03
>> So now we're getting initial mg24 < ne20 as you expect. Do the abundances look okay to you?
>> These changes will be the next release. If you'd like to play with an untested pre-release version let me know.
>> On Aug 6, 2014, at 12:41 PM, Manos Chatzopoulos wrote:
>>> Dear all,
>>> I have a question with regards to the initial abundances of the solar
>>> (1M_pre_ms_to_wd) problem in the test_suite. Basically
>>> the issue is that the initial surface abundance of Mg24 should always be
>>> smaller than that of Ne20. I do know from previous
>>> communication that this is an issue with the size of the network used in
>>> MESA but it actually does not solve the problem.
>>> If one just runs the test problem as it is the Mg24/Ne20 ratio is
>>> wrong. Even if I switch to using approx21.net instead of
>>> the default (in the test inlist_1.0) o18_and_ne22.net the ratio is still
>>> wrong. Now when I add the following lines in the inlist_1.0:
>>> set_uniform_initial_composition = .true.
>>> initial_zfracs = 3
>>> initial_h1 = 6.9979637695268626D-01
>>> initial_h2 = 0
>>> initial_he3 = 2.7973106548401051D-05
>>> initial_he4 = 2.7970309237746210D-01
>>> and I run with the original o18_and_ne22.net the ratio is still wrong. I
>>> only get the correct ratio of Mg/Ne when I run
>>> with approx21.net AND the above lines included in the inlist.
>>> My question is why when using a large network from the beginning of
>>> the run (that includes both isotopes, like approx21.net) does
>>> not assign the correct solar abundance ratios for these isotopes in the
>>> model? Why are those lines of code needed for this and it
>>> is not done by default since I input inital_z = 0.02d0?
>>> Regards and thank you in advance,
>>> Infragistics Professional
>>> Build stunning WinForms apps today!
>>> Reboot your WinForms applications with our WinForms controls.
>>> Build a bridge from your legacy apps to the future.
>>> mesa-users mailing list
>>> mesa-users at lists.sourceforge.net
>> Infragistics Professional
>> Build stunning WinForms apps today!
>> Reboot your WinForms applications with our WinForms controls.
>> Build a bridge from your legacy apps to the future.
>> mesa-users mailing list
>> mesa-users at lists.sourceforge.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mesa-users