[Mesa-users] Thank you and questions
Rob Farmer
r.j.farmer at uva.nl
Fri Oct 12 05:49:48 EDT 2018
>3. Again related to that, I do not quite understand the function of "net".
(If you can point me to a good online source to explain, that would save
you the time needed for a long response).
The net (short for network) computers the changes in abundances due nuclear
reactions. A good reference for understanding this is here (and links
within) http://cococubed.asu.edu/code_pages/net_integration.shtml
>5. v_div_cs is the convective velocity as a fraction of the sound speed at
the surface cell, correct? Is that an observable, say by line
broadening
in stars, or Doppler shifts and tracking on the Sun? Curiously I find
that that parameter is quite sensitive to the mass loss history. I do
not understand why, but if this is confirmed upon multiple checks,
perhaps it could be a diagnostic. Am I missing an obvious physical
explanation?
No, v_div_cs is simply the (hydro) velocity divided by the sound speed, the
convective velocity divided by the sound speed is conv_vel_div_csound.
Both these are computed at every zone in the star, as they are in the
profile output. The surface quantities are in the history output and have
surf_ in their name (or you find the surface zone in the profile output and
look at the conv_vel_div_csound in the profile output)
>7. This is a comment, not a question. I was confused initially by the line
"wind_scheme = ''". I left the space between single quotes empty, as I
thought was indicated, but that led to an error message. One really has
to comment out that line to make it work. Not totally clear (for me).
There is no parameter called "wind_scheme" (note when you get error
messages its far easier to debug an issue if you post the exact error
message and send inlists used). There is hot_wind_scheme,
cool_wind_RGB_scheme and cool_wind_AGB_scheme, thats way commenting it out
removed the error message.
Rob
On Fri, 12 Oct 2018 at 09:53, Warrick Ball via Mesa-users <
mesa-users at lists.mesastar.org> wrote:
> Hi Piet,
>
> I'll try to answer the questions I'm most comfortable with. Note that
> while I'm answering these questions for MESA specifically, the principles
> of how opacities are computed and used are roughly the same for all
> stellar evolution codes.
>
> > 1. I use the Asplund09 metal fractions, both for initial_zfracs and
> > kappa_file_prefix. I take it the first sets the initial conditions
> > and the second is for calculating the (initial?) opacities. So could
> > one, to create an absurd scenario, use Asplund09 for one and, say,
> > GS98 for the other?
>
> `initial_zfracs` determines the metal mixture in the stellar model.
> `kappa_file_prefix` determines which set of opacity tables is used to
> interpolate the opacity of material in the star mye answer to 2 to might
> help).
>
> You could certainly choose different values for these parameters if you
> want.
>
> > 2. Related to that, it is not clear to me what elements (as well as
> > isotopes and ionization states) are evolved and used for opacity
> > calculations by MESA.
>
> MESA comes with tables of opacities, mostly as a function of density ρ,
> temperature T, hydrogen abundance X and metallicity Z. (There are also
> tables that have the carbon and oxygen abundances as variables but I won't
> complicate the discussion with those now.) These tables are precomputed
> by other teams and groups that make detailed calculations and then average
> the results into Rosseland mean opacities, which is what MESA. The
> individual metal abundances are assumed to be distributed according to
> whichever solar mixture is specified in the filename. e.g. GS98 opacities
> means that the individual metal abundances follow the patter in GS98,
> scaled by the overall value of Z.
>
> AFAIK the ionization states will depend on whatever equation of state was
> used by the team/code that computed the opacities, which may or may not be
> exactly the same one as used in MESA.
>
> > 4. I take it that opacity_factor simply multiplies all calculated
> > opacities by that factor? That to get around by the difference in
> > metallicity derived from spectroscopy and that indicated by
> > helioseismology? (It worked for me to reconcile the observed metal
> > fractions with T_eff and R_sun for one solar mass, once element
> > diffusion is switched on as well). Is it possible to tinker with the
> > opacity_factor for individual elements?
>
> Yes, all the opacities are multiplied by `opacity_factor`. I don't think
> it is intended for any specific purpose but yes, a user could perhaps use
> it to try to reconcile a solar model in the way you describe.
>
> I'm not sure about whether or not its possible to tinker with the opacity
> factor of individual elements. I suspect the answer is "yes but it's
> complicated"...
>
> Cheers,
> Warrick
>
>
> ------------
> Warrick Ball
> Postdoc, School of Physics and Astronomy
> University of Birmingham, Edgbaston, Birmingham B15 2TT
> W.H.Ball at bham.ac.uk
> +44 (0)121 414 4552
>
>
> On Fri, 12 Oct 2018, mesa-users at lists.mesastar.org wrote:
>
> > Dear all,
> >
> > First a big "Thank You" to everyone who put MESA together and is
> maintaining
> > it! I don't program or run big codes, so I was apprehensive, but it
> turned
> > out that everything worked as described in the directions, and the
> directions
> > were unambiguous. What a difference with, say, upgrading from MacOs El
> > Capitan
> > to Sierra, which took me a long frustrating weekend.
> >
> > It is indeed also a lot of fun to follow a star as it is evolving, and
> > amazing
> > to see how fast the run goes. My project is looking at solar evolution
> under
> > different mass loss scenarios related to the Faint Young Sun Paradox.
> >
> > Here are my questions, and forgive me if they seem amateurish:
> >
> > 5. v_div_cs is the convective velocity as a fraction of the sound speed
> at
> > the surface cell, correct? Is that an observable, say by line
> broadening
> > in stars, or Doppler shifts and tracking on the Sun? Curiously I find
> > that that parameter is quite sensitive to the mass loss history. I do
> > not understand why, but if this is confirmed upon multiple checks,
> > perhaps it could be a diagnostic. Am I missing an obvious physical
> > explanation?
> > 6. I sort of get the idea of "s%", but can you give me the exact
> definition?
> > 7. This is a comment, not a question. I was confused initially by the
> line
> > "wind_scheme = ''". I left the space between single quotes empty, as
> I
> > thought was indicated, but that led to an error message. One really
> has
> > to comment out that line to make it work. Not totally clear (for me).
> > 8. Upon compiling many error messages appear of the sort "ld: warning:
> object
> > file (/Applications/mesasdk/lib/libhdf5_fortran.a(H5_ff.o)) was built
> for
> > newer OSX version (10.13) than being linked (10.12)". That is meant
> to
> > say to use High Sierra instead of Sierra, I think. Do you know if
> that
> > leads to errors? Doesn't seem so, as MESA works fine on Sierra for
> me.
> > (I'd rather not upgrade my MacOs again....).
> >
> > Thanks again!
> >
> > --
> > Piet Martens, Dept. of Physics & Astronomy
> > Georgia State University
> > 25 Park Place, 6th Floor, Room 624
> > Atlanta, GA 30303
> > Office Phone: 404-413-6612
> > Dept. Fax: 404-413-5481
> >
> > _______________________________________________
> > mesa-users at lists.mesastar.org
> > https://lists.mesastar.org/mailman/listinfo/mesa-users
> >
> >
> >
> _______________________________________________
> mesa-users at lists.mesastar.org
> https://lists.mesastar.org/mailman/listinfo/mesa-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20181012/e4a5d3ef/attachment.html>
More information about the Mesa-users
mailing list