[mesa-users] Creating more opacity tables (for interpolation)
Warrick Ball
wball at astro.physik.uni-goettingen.de
Tue Oct 22 11:25:40 EDT 2013
Aaron,
Thanks for the suggestion to push the blending boundary futher down. I
tried putting the blend between log T = 3.6 and 3.7 using
kappa_blend_logT_upper_bdy = 3.70 ! <= 0 means use default
kappa_blend_logT_lower_bdy = 3.60 ! <= 0 means use default
That stabilized the result for Z below about 0.019. i.e. the lower half of
my range. I only then looked at MESA Instrument Paper I and realised that
this puts both limits cooler than the region labelled "BLEND" in the
figure showing the opacity sources (Fig. 2). So not really sure why that
worked at all...
I also tried blending the opacity tables over the range 3.75 < logT < 4.5,
but that didn't change the results much from the "ringing" result I
started with. I'll keep playing, but if you (or anyone else!) has any
good ideas on where to progress, let me know!
Cheers,
Warrick
On Tue, 22 Oct 2013, Aaron Dotter wrote:
> Hi Warrick,
> Thanks for the explanation. Note that the monochromatic opacities won't help you near the stellar surface because
> they only apply in the high-T regime. Low-T opacities are still tabulated. However, I think you can at least
> push the temperature boundary as low as possible between high and low in the star_job inlist (not sure and can't
> check at the moment).
>
> I have been hoping that asteroseismology would push us away from all these low-res tables. [The OPAL EOS tables
> only exist for Z=0, 0.02, 0.04 and SCVH only for Z=0. HELM is great, though!] Monochromatic opacities are a step
> in the right direction. Your case may provide further motivation.
>
> Aaron
>
>
> On Tuesday, October 22, 2013, Warrick Ball wrote:
> 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
>
>
>
>
------------
Warrick Ball
Postdoc, Institut für Astrophysik Göttingen
wball at astro.physik.uni-goettingen.de
+49 (0) 551 39 5069
More information about the Mesa-users
mailing list