[mesa-users] mesa-users Digest, Vol 50, Issue 61
黄志华
zhmrhuang at 163.com
Tue Oct 22 10:04:50 EDT 2013
At 2013-10-22 21:54:39,mesa-users-request at lists.sourceforge.net wrote:
>Send mesa-users mailing list submissions to
> mesa-users at lists.sourceforge.net
>
>To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.sourceforge.net/lists/listinfo/mesa-users
>or, via email, send a message with subject or body 'help' to
> mesa-users-request at lists.sourceforge.net
>
>You can reach the person managing the list at
> mesa-users-owner at lists.sourceforge.net
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of mesa-users digest..."
>
>
>Today's Topics:
>
> 1. Re: Creating more opacity tables (for interpolation)
> (Aaron Dotter)
> 2. mesa installing error (nagyandi at titan.physx.u-szeged.hu)
> 3. Re: mesa installing error (Pablo Marchant)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Tue, 22 Oct 2013 22:23:57 +1100
>From: Aaron Dotter <aaron.dotter at gmail.com>
>Subject: Re: [mesa-users] Creating more opacity tables (for
> interpolation)
>To: Warrick Ball <wball at astro.physik.uni-goettingen.de>
>Cc: mesa-users <mesa-users at lists.sourceforge.net>
>Message-ID:
> <CAN5--jOZnjKi9HHD+Wu7=oZehKkP4tRWhe0xvYp1k9v4yWaz0w at mail.gmail.com>
>Content-Type: text/plain; charset="iso-8859-1"
>
>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
>>
>>
>>
>-------------- next part --------------
>An HTML attachment was scrubbed...
>
>------------------------------
>
>Message: 2
>Date: Tue, 22 Oct 2013 15:25:19 +0200
>From: nagyandi at titan.physx.u-szeged.hu
>Subject: [mesa-users] mesa installing error
>To: mesa-users at lists.sourceforge.net
>Message-ID:
> <69e80c425cfa36355aea833365bee49f.squirrel at titan.physx.u-szeged.hu>
>Content-Type: text/plain;charset=utf-8
>
>Hello.
>
>I am trying to install MESA on a linux/Ubuntu machine.
>When I ran ./clean then ./install, I got the following message:
>
>'Please set the environment variable OMP_NUM_THREADS.
>Suggested value is the number of cores on your machine.
>We need this in various test cases during installation.'
>
>Where can I find this variable?
>Thanks for any help in figuring this out.
>
>Cheers,
>Andrea
>
>Hi, Andrea,
> Run cat /proc/cpuinfo in your terminal and you will see the number of processors, that's the OMP_NUM_THREADS.
>cheers,
Zhihua
>------------------------------
>
>Message: 3
>Date: Tue, 22 Oct 2013 15:54:32 +0200
>From: Pablo Marchant <pamarca at gmail.com>
>Subject: Re: [mesa-users] mesa installing error
>To: nagyandi at titan.physx.u-szeged.hu
>Cc: "mesa-users at lists.sourceforge.net"
> <mesa-users at lists.sourceforge.net>
>Message-ID:
> <CAF_dd5OkrcORyQL1Lc8RRHq5TA3FPwgLV-97_iGOGzOAs9A=Lw at mail.gmail.com>
>Content-Type: text/plain; charset="iso-8859-1"
>
>Andrea, just run:
>
>export OMP_NUM_THREADS=2
>
>where 2 is the number of cores of your machine. Then execute "./install"
>and the installation should proceed normally.
>
>
>On Tue, Oct 22, 2013 at 3:25 PM, <nagyandi at titan.physx.u-szeged.hu> wrote:
>
>> Hello.
>>
>> I am trying to install MESA on a linux/Ubuntu machine.
>> When I ran ./clean then ./install, I got the following message:
>>
>> 'Please set the environment variable OMP_NUM_THREADS.
>> Suggested value is the number of cores on your machine.
>> We need this in various test cases during installation.'
>>
>> Where can I find this variable?
>> Thanks for any help in figuring this out.
>>
>> Cheers,
>> Andrea
>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>>
>
>
>
>--
>Pablo Marchant Campos
>M.Sc on Astrophysics, Universidad Cat?lica de Chile
>PhD student, Argelander-Institut f?r Astronomie
>-------------- next part --------------
>An HTML attachment was scrubbed...
>
>------------------------------
>
>------------------------------------------------------------------------------
>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
>
>
>End of mesa-users Digest, Vol 50, Issue 61
>******************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20131022/0765748a/attachment.html>
More information about the Mesa-users
mailing list