[mesa-users] Creating more opacity tables (for interpolation)
Warrick Ball
wball at astro.physik.uni-goettingen.de
Tue Oct 22 06:27:29 EDT 2013
Aaron,
Since you asked ;) here's a bit more information.
What I'm doing is the following. I evolve a sequence of models up to the
same age (in this case, 4.5 Gyr) with all parameters but one fixed at the
same value in all the models. I choose one parameter to vary within some
range. Then, I inspect the differences of the effective temperature
between the models themselves, and a cubic spline interpolation taken at
every tenth point. I've attached three plots like this, in which I vary
the mass, initial hydrogen, or initial metallicity, in the ranges [0.950
.. 0.001 .. 1.050], [0.680 .. 0.001 .. 0.740] or [0.0160 .. 0.0001 ..
0.0220], respectively. There are a few tricks at work here: one thing I
found necessary to get the scatter down is to impose a small maximum
timestep: in this case 10 Myr at a time. Yes, it slows it down, but not
too much. MESA is pretty fast. :)
If you look first at the plot against the mass, you can see that, in this
case, the error is *tiny*: on the order of millikelvin, and everywhere
less than 0.01 K. This constitutes a fractional error of something like
10^-6. Great!
If you look at the plot for X, things still look pretty good, but there's
a bump at low X that looks like it might be an interpolation artifact.
Finally, the plot for Z has a clear systematic component that approaches
the 0.1 K level: it's ten times worse. This is the phenomenon that I
think is related to the opacity tables.
I tried changing my selection of interpolation points to closely match
Chebyshev zeros, to see if that would bring things under control but it
didn't help much. (IIRC, it cut the error about in half.)
Now, there's nothing to exclude the fact that reality might not support my
expectation that the variation of the stellar observables would be
sufficiently smooth for the interpolation to work. But this is the last
hurdle I've got...
Also, let's call a spade a spade: the interpolation error is still very
small, like maybe at the 10^-5 level. But it's systematic, which I don't
like, and for asteroseismology the 10^-5 level is starting to become
comparable with the best observed uncertainties.
I'll try doing the on-the-fly opacity calculations. For a series of 60
models on the local cluster, that's probably not too much too ask for.
And then I'll know if I should keep cracking at a MESA-based solution.
I'll start looking at the relevant inlist parameters now.
Cheers,
Warrick
On Tue, 22 Oct 2013, Aaron Dotter wrote:
> Hi Warrick,
> Your difficulties with opacity tables in the kap/preprocessor are largely due to the fact that the preprocessor is
> merely a way of taking existing tables for fixed X and Z values (in their native formats), sampling them, and then
> writing them out in the format that MESA wants.
>
> The X and Z values for which we have kap tables are the same as in the original opacity files. If you were to
> make your own using the preprocessor, you'd be interpolating in the tables just as you are when you compute a
> model with MESA star that has a X or Z value different than what appears in the table. The only difference being
> the method of interpolation.
>
> Some of the problems you are seeing when switching between Type1 and Type2 are probably due to the fact that Type2
> only has tables for X <= 0.7 whereas Type1 will go up to X=1. Type2 is less densely sampled in X and Z than
> Type1; Type2 is really there to help you through He-burning, see the other ongoing discussion about opacity
> tables. Type1 is what you want for the main sequence.
>
> The kap module is expecting things to follow conventions of the OPAL opacity tables (whence the Type1 and Type2).
> If you want to experiment with different Z values, there is the other_kap functionality in MESA/star. But you're
> still stuck with the need to generate new tables that are not in the traditional grid. Which can be done (ask
> Ehsan!).
>
> The other, really neat option in MESA is to compute your own opacities from within MESA/star using the OP
> monochromatic opacities. This will require you to download those data and set everything up. It will be, as
> Frank says, "slow as molasses in a North Dakota winter" but you'll not have to worry about interpolation in X and
> Z.
>
> It's not clear what sort of "ringing" you're experiencing or if any of the above will be applicable to that
> problem, but I'd be interested to know more about it.
>
> Cheers,
> Aaron
>
>
>
>
> On Tue, Oct 22, 2013 at 7:22 PM, Warrick Ball <wball at astro.physik.uni-goettingen.de> wrote:
> Hi everyone,
>
> In another experiment I'm conducting with MESA, I'm seeing if I can get reasonable results by
> interpolating observable features (T_eff, log g, etc) in a grid of stellar models. Currently, MESA is
> performing very well: it's fast and, with some trickery, I can get some really smooth results.
>
> However, when I interpolate in initial metallicity and hydrogen abundance (Z_0 and X_0), I get a kind
> of "ringing": the interpolated observables oscillate around the modelled values. I think this is
> because my own cubic spline interpolation is sensitive to the underlying interpolation in the opacity
> tables. I suspect so because changing between Type 1 and 2 opacities (even though I only have main
> sequence models) made a difference, as did changing from linear to cubic interpolation in Z. Note
> that my range of X_0 is 0.68 to 0.74 and Z_0 covers 0.016 to 0.022. As far as I can tell, both X_0 =
> 0.70 and Z_0 = 0.02 are points in the opacity interpolations.
>
> So, my question: can I generate extra opacity tables of, say, 'gs98' variety, that MESA will read? I
> would then be able to see if adding a few more tables around my region calms the interpolation down to
> acceptable levels.
>
> I tried tinkering in mesa/kap/preprocessor but I quickly started breaking things. I tried adding a
> few extra metallicities to the rn_fixed_metal script but they weren't created and I tried adding
> hydrogen abundances but that started producing errors in the rebuild_all script. To be more
> comprehensive about my attempts, here's some detail of what I did, but if you're not interested in the
> nitty-gritty, there's no need to read on.
>
> I tried supplying a different number of hydrogen abundances by changing the following line in
> rn_fixed_metal:do_one(). (Basically, I added X_0 = 0.60 to the default list.)
>
> ./ckap $1 $2 -1
> to
> for X in 0.00 0.10 0.20 0.35 0.50 0.60 0.70 0.80 0.90 0.95
> do
> ./ckap $1 $2 $X
> done
>
> I thought this because I had a look at the source of how the input arguments were read and processed.
> That gave me errors like "unknown X value 0.5999999998 60000", which I tracked down to the last
> case statements in src/fixed_metal.f. I know I could just add the necessary case (60000) but I also
> got errors like
>
> bad composition in setup for kap builder
> Z 5.9999999999999998D-02
> X 9.4999999999999996D-01
> Zbase 5.9999999999999998D-02
> dXC 0.0000000000000000D+00
> dXO 0.0000000000000000D+00
> Zbase+X+dXC+dXO 1.0100000000000000D+00
>
> so I stopped on that line. These errors seem to be in the Type 2 tables, which I didn't want to
> modify. I don't get these errors when I run rebuild the tables without modification.
>
> When I tried added extra metallicities (with lines like do_one $1 0.0250 in rn_fixed_metal) I got more
> errors like
>
> unknown Z value for fixed metal 2.5000000000000001E-002
>
> which also just involved a few lines in the relevant case statement. I ran ./rebuild_all without a
> problem but I couldn't find any new opacity tables in mesa/kap/preprocessor/data/kap_data/.
>
> Thanks for any advice!
>
> Cheers,
> Warrick
>
>
> ------------
> Warrick Ball
> Postdoc, Institut für Astrophysik Göttingen
> wball at astro.physik.uni-goettingen.de
> +49 (0) 551 39 5069
> ------------------------------------------------------------------------------
> 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=60135991&iu=/4140/ostg.clktrk
> _______________________________________________
> mesa-users mailing list
> mesa-users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mesa-users
>
>
>
>
------------
Warrick Ball
Postdoc, Institut für Astrophysik Göttingen
wball at astro.physik.uni-goettingen.de
+49 (0) 551 39 5069
-------------- next part --------------
A non-text attachment was scrubbed...
Name: T_interpolated_in_m.png
Type: image/png
Size: 86268 bytes
Desc:
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20131022/08618c5c/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: T_interpolated_in_X.png
Type: image/png
Size: 57433 bytes
Desc:
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20131022/08618c5c/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: T_interpolated_in_Z.png
Type: image/png
Size: 54035 bytes
Desc:
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20131022/08618c5c/attachment-0002.png>
More information about the Mesa-users
mailing list