[mesa-users] issue with OP AGSS09

Fri Oct 11 23:44:53 EDT 2013

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/8e31ee7d/attachment.html>