Stellar model atmospheres

An //Extract Stellar// request computes line strengths in a model atmosphere, and the request has to name one. The form offers two grids and an upload:

• ATLAS9 (Castelli & Kurucz) - the default

• MARCS

• Upload own model atmosphere... - your own .krz file

This page describes which models each choice can actually reach, since neither grid fills the Teff x log g box its endpoints suggest.

What each choice resolves to

Both grids live in $VALD_HOME/MODELS/STELLAR, which holds far more than the two families below: seven Castelli/ATLAS9 metallicity families (am20 am15 am10 am05 ap00 ap02 ap05) and some 2400 MARCS models over ten metallicities and four alpha/CNO patterns. A grid choice maps to exactly one metallicity family. Were a choice to span several, the metallicity of the atmosphere you got would depend on filename sort order.

Note the two different conventions for log g in the filename: ATLAS9 writes 10 x log g as two digits (G45 = 4.5), MARCS writes a signed decimal (g+4.5).

The MARCS models offered here are the plane-parallel ones (the p prefix). The line selection cannot use a spherical model: an uploaded MARCS model with MODEL TYPE= 3 in its header is rejected, and must be converted to plane-parallel geometry first.

You always get a model, even outside the grid

A request whose Teff and log g fall outside the grid - or between its nodes - is not an error. The nearest node is used instead, by the distance

    dist = |dTeff| + 100 x |d(10 log g)|

so 0.1 dex in log g weighs the same as 100 K in Teff, and Teff is followed in preference to gravity. Nothing in the result file announces this. The model that was actually used is shown as Model atmosphere on the request's own status page - worth a glance whenever the parameters sit near an edge of the coverage below.

The nodes of the other grid are never considered: they are named by a pattern this grid does not recognise, so a MARCS request can never be answered with an ATLAS9 atmosphere merely because it lies nearer in Teff.

Coverage

● a model is present, ○ the combination does not exist.

ATLAS9 (Castelli & Kurucz), [M/H] = 0.0

476 models: Teff 3500-50000 K at 76 values (250 K apart up to 13000 K, 1000 K apart above it) x log g 0.0-5.0 in steps of 0.5. That is 57% of the 76 x 11 box: the grid is a staircase, because low gravities are not computed for hot models. Above 40000 K only log g >= 4.5 exists, and at 50000 K only log g = 5.0.

MARCS, plane-parallel, z+0.00

173 models: Teff 2500-8000 K (100 K steps to 4000 K, 250 K above it) x log g 3.0-5.5. 90% filled - much closer to a full box than ATLAS9, but note that it starts at log g 3.0, so MARCS has no giants here, and that log g 5.5 exists only for the coolest dwarfs.

Choosing between them

• Teff above 8000 K: ATLAS9 is the only choice. MARCS stops at 8000 K.

• Giants and supergiants (log g < 3.0): ATLAS9 only.

• Cool dwarfs below 3500 K: MARCS only, which reaches down to 2500 K.

• Where both apply (roughly 3500-8000 K, log g 3.0-5.0), the grids differ in

  • physics, not just in sampling: MARCS uses a more complete treatment of molecular opacity, which matters most for the coolest stars. The two also differ in microturbulence, 2 km/s for this ATLAS9 family against 1 km/s for MARCS.
• Anything else - a different metallicity, a different microturbulence, a

  • spherical or interpolated model - has to be uploaded as a .krz file.

Uploading your own model atmosphere

Choosing //Upload own model atmosphere...// on the stellar form replaces the grid entirely: the file you send is the atmosphere the line selection runs in, and the Teff and log g shown on the request are read out of its header rather than taken from the form. Use it for a metallicity, a microturbulence or an interpolated node the two grids above do not have.

The file must be in krz format - the condensed Kurucz-style model select5 reads. The format is documented at marcs.astro.uu.se/docs.html, and every file in the VALD grid is an example of it.

Layout

The head of a grid model, which is the shape to copy:

TITLE  [0.0] VTURB=2  L/H=1.25 NOVER NEW ODF
T EFF= 5750. GRAV= 4.5  MODEL TYPE= 0 WLSTD= 5000.
 1 1 1 1 1 1 1 1 1 1 1 1 1 0 1 0 0 0 0 0 - Opacity switches
  0.920  -1.11 -10.94 -10.64  -9.49  -3.52  -4.12  -3.21  -7.48  -3.96
  ... eight more lines of ten ...
 -20.00 -12.54 -20.00 -20.00 -20.00 -20.00 -20.00 -20.00 -20.00 72
 5.561746900E-04,   3628.5, 2.86500E+09, 3.51119E+13, 7.35900E-11,

The last number of the abundance block (72 above) is the depth-point count, not an abundance. Abundances and that count are a single list-directed read, so they may be spread over any number of lines; the grid files use ten lines of ten.

Rules that are easy to break

• MODEL TYPE= must be 0. Type 3 is spherical, and the line selection

  • cannot use a spherical atmosphere. Most of the MARCS grid is spherical and has to be converted to plane-parallel geometry first. A spherical file also carries a sixth column, the height above the reference radius, which is not read here.

• The four keywords must appear in the order above, and within the first

  • 256 characters of line 2. Each value is taken as the text between one keyword and the next rather than looked up by name, so a keyword out of order

    silently scrambles all four values. (GRAV is listed without its = because that is the bare word the reader searches for.)

• Abundances are number fractions, not the A(X)=12 dex scale. A value at

  • or above zero is used as N_atom/N_all; a negative value is read as its log10. Both conventions appear in real files - a MARCS model writes helium as 0.078, an ATLAS9 model writes -1.110, and those are the same abundance. But an abundance table on the dex scale, where iron is 7.50, is not rejected by the Fortran: it is read as a number fraction of 7.5 and the result is quietly wrong. If your file is on that scale, subtract 12.04 from every value. The upload check refuses any value above 1 for exactly this reason.

• Use -20.00, not 0.00, for an element you have no abundance for. The

  • abundances are written back into the result header as log10, so an exact zero becomes -Infinity there. The grid models floor at -20.00.

• Whole numbers must be written as whole numbers. The opacity switches,

  • MODEL TYPE= and the depth-point count are read into Fortran INTEGERs, which refuse 0. and 7.2E1 outright. That is an error there, not a rounding.

• 3 to 100 depth points. select5 sizes its arrays for 100 and rejects

  • more.

• Plain text, at most 512 kB. A 100-layer model is about 12 kB.

What happens to the file

The upload is checked before the job starts, and a file that would not read is refused with a message naming the line - the checks are deliberately no stricter than the Fortran, so anything accepted here runs. The bytes are then stored and run unchanged rather than rewritten into a canonical form, so the file that produced a result is the file you sent.

The filename is kept too, reduced to letters, digits and . _ + - and truncated to fit - select5 holds the whole path in 120 characters. It is printed into the result header and carried into every exported format, so it is worth sending a name that says what the model is: marcs_p5750_g45_m-0.5.krz rather than model.krz.