Input files

Input rules to MyGIsFOS provide all the needed calculation parameters, the list of stars to be processed, the list of regions to be used, and the synthetic spectra grid. They must be called after the fortran unit used to read them (see below), otherwise the code will not recognize them. However, such names might just be symbolic links to a file of whatever name. For instance, the list of stars to be processed is to be provided as fort.14, but you can always

And it will work just fine. MyGIsFOS uses a fewother fortran units for input-output, so it is recommended not to have any file called fort.* but the ones here described in the directory where the code is running, to avoid them to interfere with the code or be overwritten.

Measurement and continuum regions are provided in one or more files whose names are entered, one per line, in fort.10. This is done to allow the user to choose how to organize his region lists, so that e.g. one can place regions for each ion into separate files, or, on the other extreme, everything can be placed in a single file. fort.10 format is a simple list of file names, one per line. Any line beginning with a hash (#) is skipped as comment. As an example, fort.10 might look like this:

#this is a comment line

• Fe1_metalrichdwarfs.txt
• Fe2_metalrichdwarfs.txt
• alphaelements.dat

#another comment line

• the_continua.txt
• heavyelements.txt

There is no need for the region lists to be given in any order, all the files are read, the regions from each lumped in a single list, oredered for increasing wavelength, into MyGIsFOS.

#595.643 595.703 2 26 00 1 1 1 0.859 #595.669 Y/Y see next
595.694 595.703 2 26 00 1 1 1 0.859 #595.669 Y/Y
596.104 596.167 2 -1 00 1 1 1 0.0000 #
596.352 596.429 2 -1 00 1 1 1 0.0000 #
596.975 597.041 2 -1 00 1 1 1 0.0000 #
597.825 597.871 2 22 00 1 1 1 0.0000 #
	

Where the columns are: starting wavelength (nm) ending wavelength (nm), frame number in the synthetic grid, element/ion code, flag for general use, flag for use in Vturb iteration, flag for use in Teff iteration, lower energy (eV), and comment.

• Every line prepended with a hash is considered a comment and skipped.
• Format is free, space separated. The list does not need to be sorted in any way.
• Element-ion code is the usual atomic number + ionization level format used in many other codes, e.g 26 00 means iron (26) neutral (00). 22 01 would be singly-ionized titanium etc.
• -1 00 is a special code indicating a continuum region.
• The “use this line" flag leads to the region skipped if equal to zero. This is equivalent to commenting the line. However it is better to just comment the line to skip it, for a number of reasons: please do not use the flag.
• The “use for Teff” and “use for Vturb” flags, if put to zero, lead to the region NOT being used in the fit of the lower-energy-versus-abundance and reduced-EW-versus-abundance distributions for Fe I lines, whose slopes are zeroed to set Teff and Vturb, respectively. The regions will still be used in determining the Fe I abundance, unless rejected by the code on the same ground as any other line. One typical case when one may want to still use a feature for abundance but not in the parameters determination stage is the one of a feature containing a blend of two Fe I lines. If the atomic data of the two lines are good, the blend will be well reproduced in the synthetic grid and thus the fit of the region would be useful. However, its EW will not respond to saturation as the one of single line, and thus the line cannot be used for Vturb determination. Another case could be lines with very low lower evergy, that typically are indesirable in Teff determination. These flags are ignored if the line is not a 26 00 one (but should be there)
• Excitation potential is needed For Fe I (26 00) lines only, the column is ignored (but should be there) for any other ion. It is used in the determination of Teff. MyGIsFOS input-output formats assume lower energy is given in eV. From the fitting point of view it should be irrelevant whether this is the case, but output would almost surely be wrong for other units, and the code has not been tested with anything but eV.
• The comment has a 80 character length, but is just a text string that is passed through to output for reference. It can be empty. In the example shown it always begins with a hash, but this is not mandatory. The length is fixed, so that 80 characters are read from the first non-space character after the lower energy. As such, spaces are accepted in the comment.

This file contains parameters affecting the general behavior of the code, such as threshold for line rejections or the level of precision to which to stop parameter iteration. It is particular because its format is constrained, i.e. the order of the parameters cannot be changed. A typical example is:

	
1e-16 #probmin: minimum accepted probability for a line
0.1 #slopemin: minimum accepted slope to trigger Vturb iteration
0.05 #fe2min: minimum FeI/FeII difference to trigger gravity iteration
0.01 #maxexctslope: maximum slope acceptable of the exct. pot. vs. abundance relation
50 #maxtdiff, maximum temperature difference.
0.0005 #ewmin: minimum accepted line EW
0.012 #ewmax: maximum accepted line EW
0.8 #ewdrj: the line is rejected if ABS(EW-OEW).gt.ewdrj*min(EW,OEW)
3. #ew_noise: the line is rejected if EW is smaller than this factor times the noise dominated EW
2. #nclip: number of sigmas for average abundance clipping
0.25 #freecont: maximum admitted continuum variation in MINUIT. -1 locks the continuum.
1000 #nloopmax: maximum number of iterations
0. #fwhm_override: if not 0, assumed line fwhm. If 0, grid broadening is used instead.
2 #nalp2: number of alpha elements to be used in alpha enhancement determination
14 00
20 00 #these are the ions used in alpha enhancement estimation...
0.1 #alphamin: minimum alpha enhancement difference to trigger iteration
0.6 #pnfc: pseudomedian factor in continuum normalization.
6 #policy: parameter damping policy
0 #norenorm: disables pseudonormalization if =1
100 #sncap: artificially caps S/N to this value if not 0
	

A single value is read from each line, so that everything after the space is ignored. The comments included are just for user’s convenience and can be changed at user’s will. A few notes:

• These parameters are not to be taken as they are and never changed. A few (e.g. pnfc) are somewhat sensitive to the quality of the data (S/N) and must be set after a little testing.
• All EWs are in nm, this reflects in the value used in slopemin: it is in FeI abundance change (dex) per nm of EW.
• maxtdiff is the maximum change in temperature estimate above which the code will keep iterating. For every tried Teff, MyGIsFOS determines the slope of the linear fit to the A(FeI) vs. lower energy distribution. Then a 2nd order polynomial is fitted to the slope vs. Teff samples, and the zero slope Teff is determined., and MyGIsFOS iterates with it, then its slope is determined in turn, added to the slope vs. Teff fitting sample, and a new zero-slope-Teff is determined. If said Teff differs more than maxtdiff from the previous best estimate, the iteration proceeds. Otherwise MyGIsFOS considers Teff has converged.
• maxexctslope in principle is a different criterion for Teff convergence, stopping when the slope in the lower energy vs. Teff relation is smaller (in absolute value) than this value. Both this criterion and the one based on maxtdiff must be satisfied, so whatever is stricter applies. In general maxtdiff appears to work better, so this one is usually set to a large value to leave the other in effect.
• freecont is given as a fraction of the local estimated noise. 0.25 thus means the continuum is allowed to vary by not more than 1/4 of the local 1-σ noise amplitude.
• nalp2 begins the only part in fort.11 that is allowed to change. MyGIsFOS is designed to use only explicitly indicated ions to estimate alpha enhancement. nalp2 indicates how may such ions are going to be listed after it, a corresponding number of lines, each identifying one such ion, must follow. In the above given example, for istance, only Si I and Ca I will be used to estimate alpha enhancement, which value will be set to the unweighted average of [Si I / Fe] and [Ca I / Fe], if both are present (otherwise the only one present will be used). MyGIsFOS will measure, say Mg I if features are provided, but it will not use it in determining the alpha enhancement at which the grid will be interpolated. One limitation exists in that only one ion per element can be used, i.e. one can use Ti I or Ti II here, but not both. Also, only elements that receive alpha-enhancement in the synthetic grid can be used (which elements are alpha-enhanced is indicated in the grid header).
• sncap is used to cap the S/N in high S/N spectra. Imperfection in the line lists used in generating the synthetic grid, as well as other causes (abundance anomalies, telluric absorptions, reduction issues...) introduce small discrepancies between observed spectrum and the synthetic grid. However, during the χ-square fitting, MyGIsFOS assumes that noise is the only cause of discrepancy. When S/N is high enough, this is no longer true, and the code tends sometimes to attribute an unrealistically low probability to fits that are quite good but for, e.g., a small blend only marginally affecting a feature. Capping the S/N prevents this.

The synthetic grid is contained in a specially formatted binary and linked (or renamed) to fort.12. This is done to reduce its size (even like this, the grid is easily the largest input file of MyGIsFOS, easily passing 1Gb), speed up read-in, and reduce the likelihood of errors. The grid file contains, apart from the actual synthetic spectra, descriptors for the parameter space covered (values in Teff, log g, metallicity etc.) the assumed solar abundances used in the calculation, and the instrumental broadening applied to it. The grid is currently converted to binary by the companion program makegrid, and it's instrumental broadening allied by broadgrid: the grid must be passed to MyGIsFOS already broadened. See the dedicated section for more information.

This file contains the list of stars to be analyzed by MyGIsFOS. The record for a star looks like the following example

• Any line beginning with a hash is ignored as a comment
• The record for a star begins with a line marked by the STAR keyword. It is followed by the star identifier which will be used for the output (up to 20 char.). The Teff initial guess follows, then the flag for temperature iteration, the first guess [Fe/H], the first guess micro turbulence and its iteration flag, the first guess gravity and its iteration flag, the first guess [α/Fe] and its iteration flag, and then a general flag for star execution.
• The Teff iteration flag describes how Teff is handled. If 0, Teff is kept fixed. If 1, all the temperatures in the grid are scanned to build the Teff-LEAS relationship. If 2 or larger, a range of Teff is scanned around the first guess value. If the flag is n, +-n*100 K are scanned around the first guess, at 75 k steps. For instance, being the first guess 5000 and the flag 2, the scanned Teff will be 4775, 4850, 4925, 5000, 5075, 5150, 5225.
• All the other iteration flags will keep the parameter fixed at the first guess value if 0 and iterate it if 1.
• The star execution flag, if set to 0, will lead the star to be skipped entirely. If 1, the star will be analyzed.
• After a STAR line, MyGIsFOS expects either a comment line or a FRAME line. each FRAME line describes one observed spectrum for the star being processed. When another STAR line is encountered, MyGIsSFOS assumes that all observed frames for the previous star have been read in.
• Similarly to what happens for the synthetic grid, there might be multiple FRAMEs for a star, like in the example above. This is to accommodate different spectral ranges (e.g. Giraffe settings, UVES arms and so on).
• After the FRAME keyword follows the number of the observed frame (not the same as the number of the synthetic frame). Then a read in method keyword. Currently three such methods are supported:
• ASCIN two columns ASCII spectrum, wavelength in nanometers
• ASCIA same, but wavelengths in Ångstrom
• AUTO ASCII spectrum, the code will decide whether in nm or Å (if central wavelength is >1000, Å are assumed).
• Finally, the file name for the observed frame is read, up to 35 character long.