CMD Frequently Asked Questions

NEW! Revised for CMD v3.2 on Feb 2019!

Why [M/H]=0 does not give the solar Z? For PARSEC tracks, [M/H]=0 will result in isochrones with Z=0.014711, instead of the Z=0.01524 expected for the present Sun (see Table 3 in Bressan et al. 2012). This small offset is caused by the intrinsic difference between the helium content in the model for the present Sun, and the initial helium content for which the PARSEC evolutionary tracks are computed. That is:

The model for the present Sun is forced to reproduce the observed ratio of Z_sun/X_sun=0.0207. This ratio defines the zero-point of the [M/H] scale, [M/H]=log(Z/X)-log(Z_sun/X_sun)
The same solar model has an initial surface composition of Z_initial=0.01774, Y_initial=0.28 (see Table 3 in Bressan et al. 2012). Together with the primordial helium content of Y_p=0.2485, these numbers define the relation Y=Y_p+1.78Z, which was used to build the set of initial (Z,Y) values for which we compute the tracks.
Therefore, the Y(Z) relation used to compute the grids, is respected by the initial Sun, but not by the present Sun (which is affected by diffusion). This creates a 0.015 dex offset between the metallicity scale of the present Sun, and the initial metallicity scale of the computed grids of tracks. See Table 4 in Bressan et al. (2012) for a more complete list of [M/H] values that follow from this approximation.

Therefore, this result is not a bug, but rather an intrinsic problem in the definition of [M/H] for our grids of tracks. Since this "[M/H] offset" is very small, compared to the typical spacing in metallicity of our grids, and to typical observational uncertainties, we prefer to just ignore it. There are certainly more critical approximations affecting grids of evolutionary tracks, than this one!

What is the meaning of the label (or stage) in the isochrones? The label was implemented with the PARSEC v1.2S tracks, to divide input tracks and output isochrones into rough "evolutionary sections". They have not been carefully checked for all masses and metallicities, and we know of the presence of some misclassified points in output. Nonetheless, many people (including ourselves) find these labels very useful. Use them with caution! Their approximate meaning is:

0 = PMS, pre main sequence
1 = MS, main sequence
2 = SGB, subgiant branch, or Hertzsprung gap for more intermediate+massive stars
3 = RGB, red giant branch, or the quick stage of red giant for intermediate+massive stars
4 = CHEB, core He-burning for low mass stars, or the very initial stage of CHeB for intermediate+massive stars
5 = still CHEB, the blueward part of the Cepheid loop of intermediate+massive stars
6 = still CHEB, the redward part of the Cepheid loop of intermediate+massive stars
7 = EAGB, the early asymptotic giant branch, or a quick stage of red giant for massive stars
8 = TPAGB, the thermally pulsing asymptotic giant branch
9 = post-AGB (in preparation!)

Is there a bug in the isochrones of log(age)=9.15? No. For this particular age, there is a pronounced peak in the production rate of AGB stars, that causes a transient red phase in the integrated SSP colours. The reason is explained in detail in Girardi et al. (2013), and in section 3.2.1 of Girardi & Bertelli (1998). It derives from a real physical effect, namely the sudden change in helium-burning lifetimes as stars of low mass develop electron-degenerate cores. Therefore, it is not a bug. The effect is well dealt by our algorithms, and appears either as a very populated single AGB sequence, or as multiple AGB sequences in the same isochrone, over a somewhat limited range of ages. However, this feature has caused problems to many users, especially when the isochrones are fed to population synthesis codes that do not deal properly with the (occasional) gaps in the mass distribution of AGB stars. In order to alleviate this specific problem:

In PARSEC-based isochrones: At the termination of the TP-AGB tracks we have inserted points with label=9 (which means post-AGB, see item above) and logL=-9.999. For most isochrones, this point represents a clear, single termination point, that can be safely ignored. However, for the isochrones with multiple TP-AGB sections, a couple of label=9 points will conveniently appear at the limits of the gap in initial mass between two TP-AGB sections. Therefore, these two label=9 points, with their neglegible luminosity, will prevent people from populating the gap with spurious, bright TP-AGB stars. The AGB-boosting effect will still be there, of course, but with its correct amplitude.

In pre-PARSEC versions of the isochrones: The problem was more evident at metallicities Z=0.008, and was mitigated by supressing the Z=0.008, 1.85 M_sun evolutionary track from the isochrone interpolation, then spreading the "overproduction" of AGB stars at log(age)=9.15 over a wider range of ages, and avoiding gaps in the mass distribution of AGB stars.

How do I refer to these isochrones? Use the references provided in the output header. These references however may not be complete and we strongly encourage you to look at the papers for the details!

In case you want to add a reference to this URL, use "http://stev.oapd.inaf.it/cmd". References to official papers are however to be preferred.

Why are overtone mode periods all equal to 0 for the brightest points of the TP-AGB phase? Highly-evolved TP-AGB stars most likely pulsate only in the fundamental mode. Moreover, overtone mode periods are currently available from linear calculations, who are not suitable for the final stages of the TP-AGB. Therefore the overtone mode periods are by default set to 0 for such highly-evolved stars, that are identified with the ones with radius larger than the "bending radius" Rb from Trabucchi+2021.

This service is mantained by Léo Girardi at the Osservatorio Astronomico di Padova.
Questions, comments and special requests should be directed to leo.girardi@oapd·inaf·it .
Last modified: Oct 29, 2021