[mesa-users] issue with OP AGSS09

Sat Oct 12 15:45:26 EDT 2013

OK, I will give it a try and send you the HR diagram with hopefully nice
tracks soon. But for the moment I have this problem:
After ./clean and:
svn up -r 5529
I get:
svn: Directory 'data/rates_data/cache/.svn' containing working copy admin
area is missing

Do I need a fresh check out or you still work on the sources?
Radek

2013/10/12 Bill Paxton <paxton at kitp.ucsb.edu>

> Make that version 5529 --- I also needed to make a small fix for the high
> T blend with Compton.
>
> -B
>
>
>
>
> On Oct 11, 2013, at 11:39 PM, Radek Smolec wrote:
>
> Hi,
>
> It solves the problem in my opinion. Yesterday I found the same, i.e. that
> OP A09 extends only to logT=8 (and all other go to 8.7), but thought it is
> a job of preprocessor to correctly blend the opacities at lower logT, and
> asked Bill about that to make sure. Now I see that preprocessor does not
> care about blending, just prepares the opacities in MESA format and kap
> module makes blending. Therefore, am I right that
> - at the moment using OP A09 for any problem dealing with large log T is
> simply wrong?
> - can we simply fix this and tell kap module to make blending at lower
> logT? (does the source of opacities at large  logT extend also down to
> logT=8 and is reliable there?)
> - does anyone know why the OP web application now produces the results
> only to logT=8, while for OP GS98 it was possible to go logT=8.7 (how OP
> gs98 file was prepared: with web application or OPCD software?)
> Cheers,
> Radek
>
>
>
> 2013/10/12 Aaron Dotter <aaron.dotter at gmail.com>
>
>> Hi again,
>>
>> Further inspection shows that the kap module isn't properly dealing with
>> the different temperature limits of OP vs. OPAL.
>>
>> OP only goes up to logT=8; OPAL goes up to logT=8.7.  In the MESA opacity
>> files based on OP data the values for logT > 8 are set 9.999.  In the kap
>> module the limits where the opacity is blended between high-T tables and
>> compton is between 8.2 and 8.69.  Using the OP opacities, rather than OPAL,
>> at high temperatures would encounter the missing data 9.999s.
>>
>> He-burning is relevant at these temperatures and, thus, this ought to be
>> Type2 enhanced C and O territory anyway, but the choice to use those or not
>> is in the user's hands.
>>
>> Aaron
>>
>>
>> On Sat, Oct 12, 2013 at 11:44 AM, Aaron Dotter <aaron.dotter at gmail.com>wrote:
>>
>>> Hi all,
>>>
>>> With regard to Jakub's first email, an important consideration is that
>>> He-burning models really should be using Type2 opacities to account for the
>>> production of excess C and O.  The inlist provided does not seem to include
>>> the Type2 tables.
>>>
>>> I have also compared the headers for the OP A09 tables that are in the
>>> current mesa/kap/preprocessor/kap_input_data/OP directory.  These files are
>>> called
>>>
>>> 1. A09.OP17
>>> 2. A09_Przybilla.OP17
>>>
>>> The OPAL format, which OP mimics, lists the input abundances for metals
>>> near the top of the file.  Just looking at the input abundances shows that
>>> the second file is inconsistent with A09 abundances (and should not be
>>> used).  The first is alright.  We have the issue that OPAL includes more
>>> elements than OP in the opacity calculation, so that there will be larger
>>> discrepancies between OP abundances and OPAL abundances even for the
>>> correct input mixture.
>>>
>>> For reference, the OPAL table for A09 is "correct" in the sense that it
>>> matches the actual values given in the table of Asplund et al. (2009) for
>>> all elements present.  It can be found at kap_input_data/opal/A09opal.
>>>
>>> Aaron
>>>
>>>
>>>
>>>
>>> On Sat, Oct 12, 2013 at 5:59 AM, Bill Paxton <paxton at kitp.ucsb.edu>wrote:
>>>
>>>> Hi Craig,
>>>>
>>>> Thanks for the pointer.   Before we get to that, we need to wait for
>>>> Radek & Jakub to check the mesa opacity tables to see if there is a problem
>>>> in them.
>>>>
>>>> Bill
>>>>
>>>>
>>>>
>>>>
>>>> On Oct 11, 2013, at 11:47 AM, Craig Wheeler wrote:
>>>>
>>>> > http://adsabs.harvard.edu/abs/2012A%26A...542A...1L
>>>> >
>>>> > Might be relevant.
>>>> >
>>>> > Craig
>>>> >
>>>> > On 10/11/13 1:22 PM, Bill Paxton wrote:
>>>> >> Hi Jakub,
>>>> >>
>>>> >> Lovely!  The jumps in core He abundance from 1% to 3% suggest
>>>> instabilities during the "death" of the core He burning convection zone.
>>>>  Please check that -- make plots of size of core convection zone during
>>>> this time and share them with us.  I expect that the convection dies out
>>>> when core He drops to 1%, but then the core temp rises and you get a burst
>>>> of convection from that.  The convection briefly reaches up into He rich
>>>> material and raises the center abundance up to 3% and that lets the core
>>>> temperature drop.  Then the cycle repeats until the convective bursts can
>>>> no longer bring down more He.
>>>> >>
>>>> >> Since the convection will be sensitive to opacities, the change from
>>>> GS98 to A09 might be enough to trigger this.   And of course overshooting
>>>> during He burning can go unstable as you well know.  You have overshooting
>>>> above he burning turned on:
>>>> >>       overshoot_f_above_burn_he = 0.010
>>>> >> so that might also be contributing to this.   What happens to this
>>>> when you run without overshooting?  I expect that will cause you grief in
>>>> other things, but specifically what effect does it have on these
>>>> instabilities in core he burning?
>>>> >>
>>>> >> My guess is that the A09 tables are fine.  They are just pushing you
>>>> over the cliff with an overshooting related instability during the final
>>>> stage of core He burning.    But I'm suspicious of the use of overshooting
>>>> during core He burning anyway -- it has been very unstable when I've tried
>>>> it.   But let's see -- maybe it has nothing to do with what you are getting
>>>> here.
>>>> >>
>>>> >> Another question -- you are dealing with opacities in the C/O ashes
>>>> of He burning, but you are not using Type2 opacities.  Why not?  Have you
>>>> experimented and found that there was no difference?  That would be a
>>>> surprise.
>>>> >>
>>>> >> -Bill
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >> On Oct 11, 2013, at 10:58 AM, Jakub Ostrowski wrote:
>>>> >>
>>>> >>> Hi,
>>>> >>>
>>>> >>> I'd like to point out an unusual behavior that happens with
>>>> calculations which use the recently implemented OP AGSS09 opacity tables. I
>>>> calculated models within mass range of 3 - 20 MS and for metallicity
>>>> between 0.01 and 0.02 and there are problems with every model.
>>>> >>>
>>>> >>> First of all, with OPAL AGSS09, OPAL GS98 and OP GS98 there is a
>>>> helium blue loop for every calculated track while for OP AGSS09 there is
>>>> none for any of them. This behavior itself doesn't necessary mean that
>>>> something is wrong, but the other thing does: after the core helium
>>>> abundance drops below about 1% it suddenly rises to about 3% and the energy
>>>> produce from helium burning increases. Then it repeats itself again for a
>>>> dozen of times or so. I attached a plot that shows this behavior for 15Ms
>>>> and Z = 0.01, but this problem exists for every single model I calculated
>>>> with OP AGSS09.
>>>> >>>
>>>> >>> I discussed the problem with Radek who provided the tables. He
>>>> confirmed that the problem is real and I'm sure he will soon provide his
>>>> ideas.
>>>> >>>
>>>> >>> My environment: MESA v5456 compiled with SDK on OS X 10.8.5. You
>>>> can find the attaches inlist. The only things I changed there are opacity
>>>> tables, mass and metallicity.
>>>> >>>
>>>> >>> Cheers,
>>>> >>> Jakub
>>>> >>>
>>>> >>> <LHe-Yc-15m-op-z0.01.pdf>
>>>> >>> <15m-z0.01-op-opal.pdf>
>>>> >>> <inlist_15m_op_f0010_z001>
>>>> >>
>>>> >>
>>>> ------------------------------------------------------------------------------
>>>> >> October Webinars: Code for Performance
>>>> >> Free Intel webinars can help you accelerate application performance.
>>>> >> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the
>>>> most from
>>>> >> the latest Intel processors and coprocessors. See abstracts and
>>>> register>
>>>> >>
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
>>>> >> _______________________________________________
>>>> >> mesa-users mailing list
>>>> >> mesa-users at lists.sourceforge.net
>>>> >> https://lists.sourceforge.net/lists/listinfo/mesa-users
>>>> >
>>>> > --
>>>> > J. Craig Wheeler
>>>> > Department of Astronomy
>>>> > 2515 Speedway, Stop C1400
>>>> > Austin, TX 78712-1205
>>>> > 512-471-6407
>>>> > http://www.as.utexas.edu/~wheel
>>>> > http://ebooks.cambridge.org/ebook.jsf?bid=CBO9780511536625
>>>> > http://www.smashwords.com/books/view/127749
>>>> > http://www.smashwords.com/books/view/178104
>>>> > http://www.amazon.com/The-Krone-Experiment-ebook/dp/B008Y6L3VW
>>>> > http://www.amazon.com/Krone-Ascending-ebook/dp/B00926QEGW
>>>> > http://www.amazon.com/The-Q-Man-1-ebook/dp/B00AFKJYKC
>>>> >
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> October Webinars: Code for Performance
>>>> Free Intel webinars can help you accelerate application performance.
>>>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the
>>>> most from
>>>> the latest Intel processors and coprocessors. See abstracts and
>>>> register >
>>>>
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
>>>> _______________________________________________
>>>> mesa-users mailing list
>>>> mesa-users at lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/mesa-users
>>>>
>>>
>>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20131012/268bec22/attachment.html>