[mesa-users] issue with OP AGSS09
Bill Paxton
paxton at kitp.ucsb.edu
Sat Oct 12 14:42:34 EDT 2013
Hi Radek,
Interesting! BTW: the header of the OP A09 data that you sent has this line:
log(T) range: 70 values from 3.75 to 8.70
so I guess they just wanted to make the tables have the same range as OPAL even though they didn't have the data to fill them!!!!! Those <expletive deleted> bums!
I've made a new set of mesa kap tables with the OP data cut off at logT = 8.0 -- hopefully that will help! Get mesa 5528 to try them.
As Aaron and I have both mentioned now, you need to do something about Type2 tables for C/O enhanced abundances if you are going to do helium burning and beyond.
For Type_2 opacities in mesa using OP data, I need to have exactly the same set of files as I have now from OPAL. You can see what those are by unpacking mesa/kap/preprocessor/kap_input_data.tar.bz2
You need to provide OP versions of all of the following 40 files that you'll find in kap_input_data/opal
Gz000.x00
Gz000.x03
Gz000.x10
Gz000.x35
Gz000.x70
Gz001.x00
Gz001.x03
Gz001.x10
Gz001.x35
Gz001.x70
Gz004.x00
Gz004.x03
Gz004.x10
Gz004.x35
Gz004.x70
Gz010.x00
Gz010.x03
Gz010.x10
Gz010.x35
Gz010.x70
Gz020.x00
Gz020.x03
Gz020.x10
Gz020.x35
Gz020.x70
Gz030.x00
Gz030.x03
Gz030.x10
Gz030.x35
Gz030.x70
Gz050.x00
Gz050.x03
Gz050.x10
Gz050.x35
Gz050.x70
Gz100.x00
Gz100.x03
Gz100.x10
Gz100.x35
Gz100.x70
Here's one as an example -- they have to be in this format (but you can skip logT > 8.0 !!!)
-Bill
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/645fa4ad/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Gz020.x70
Type: application/octet-stream
Size: 314206 bytes
Desc: not available
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20131012/645fa4ad/attachment.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20131012/645fa4ad/attachment-0001.html>
More information about the Mesa-users
mailing list