Metallicity definition in the documents for Icat method

[mgennaro]

@pllim I would like to point out a small mistake in the definition of metallicity in the pysynphot documentation (appendix A, but maybe somewhere else as well). This concerns the use of some spectral libraries (Castelli&Kurucz, Phoenix, maybe more) The docs say that one should call the S.ICat method using log (Z). However from reading the Kurucz 1993 readme, from experience with these spectral libraries, and from testing, I think that instead of log Z, one should be using [Fe/H] or (almost equivalently) log (Z/Zsun) (the two are equivalent for solar-scaler elemnt mixtures, i.e. when, for example, tehre is no alpha enhancement). The idea is that for solar metallicity one should use a enter a 0 in the call for S.Icat, but as the documents read now, that's not what one would enter.

To verify this I have considered the following: 1) The solar Z is ~0.015, thus log (Z) is about -1.8. I have thus called Icat with this value, for the Castelli and Kurucz library 2) I have called the model spectrum from calspec for P330E, a solar analog 3) I have called Icat with log(Z/Zsun) = 0

In the attached plot you can see that the solar analog's spectrum is reproduced by the models, when I call Icat using logZ/Zsun, not logZ, thus I think the documentation is wrong.

I'd like to make sure that whenever the HST and JWST ETCs use pysynphot with the Icat method (if they do), this problem with the definition of metallicity is correctly taken into account. For example both ETCs use the Castelli spectra and the JWST one uses the Phoenix ones. The provided spectra are generally only for solar metallicity, I believe (at least in theory). Now if the ETC uses hard-coded link to the correct tables, then no problem. But if for any reasons the ETC makes a pysynphot.Icat call, using logZ = -1.8 instead of logZ/Z_sun = 0, then it may be calling the wrong tables (in practice it'd be using spectra of much lower metallicity than solar).

[pllim]

Pinging ETC folks as requested: @vglaidler , @cdsontag , @ibusko

[rizeladiaz]

Looking at the README file for the Castelli and Kurucz models, it correctly states that we are talking about [M/H]. The documentation for Kurucz 93 is less clear. I assume that is the reason for which it ended with Log Z in the README file rather than [M/H]. His paper refers to abundances as [+1.0], [+1.5], without indicating what he means. One can assume that he means [M/H] but it is worth checking more about it. I will do that.

[pllim]

@rizeladiaz , any final word on this? Is it safe to say that we can change all mention of Log Z to [M/H]?

[rizeladiaz]

Yes, it is safe

[mileslucas]

I have noticed, actually, that the Phoenix models seem to use log Z metallicity (-1.8 works better than 0 for solar-like stars). However, the allowed parameters when calling ICat allows log Z > 0 which would imply a star with impossible metallicity.

[mgennaro]

All the Allard stuff is done in [Fe/H], and I am not sure I follow the "impossible metallicity argument". You mean if the solar metallicity is truly -1.8, then >0 would mean 100 times solar, right? Truth is, I am not sure which version of the Allard models was used here for cool stars, but it has been certainly superseded since. I would not be surprised that the agreement of the old phoenix models with respect to a solar spectrum is less than ideal. They have since changed the code, the opacity tables and the clouds treatment (last one relevant for very cool stars). The most up-to-date Allard Modles would be the BT-settl ones, which are however not available through synphot.

[mileslucas]

My argument was that if the Phoenix Models are actually log Z then if that parameter is greater than 0, it would imply Z>1 which would mean it is a rock. If it is, however, [Fe/H] then that would be a different story. As of right now, the docs simply say log Z for the Phoenix models.

Edit: Correct me if I am wrong, but a solar-like star would have [Fe/H] = 0, which contradicts what I have seen in trying to fit such stars with Icat. In my fitting, the metallicity parameter of best fit is -1.8.

[mgennaro]

Could you produce something like my plot above? As I said, the PHOENIX models within the Icat, may not be the most up-to-date, but it is strange that you get the best fit at a metallicity parameter that would imply that the Icat methoid is called using logZ (are you actually performing a fit?)

BTW, you are rigth, Z>1 would be absurd and impossible. By definition X+Y+Z = 1 and each of X,Y,Z >= 0, thus Z can be at most 1 not larger than one. Thus, if there are Icat models with "metallcity paramter" greater than 0, then that metallicity paramter cannot be logZ, but rather logZ/Zsun (or equivalently, [M/H])

[mileslucas]

Here is an example plot:

As you can see, when the metallicity parameter is 0, the fit is not good. I especially noted that the lines at 1.6 um and 1.7 um, approximately, are way too large for a star with solar-metallicity. The strong Paschen-series lines are consistent between the three spectra but with the metallicity parameter set to -1.8 there is much more agreement with the data.

I am not fitting metallicity right now with an algorithm. I am using reported values from my mentor's previous study of the star in order to develop a python package for us to fit similar stars.

[mgennaro]

Ok, and I guess you are using the appropriate Teff for that star, correct?

....not sure what's going on. I think no one in the community uses log Z as a variable in their grid of spectral models. Allard, if you look at her website, provides spectra in [Fe/H] grids. I also find it hard to believe that there has been any preprocessing of the spectra before ingesting them into Icat, so that the [Fe/H] values have been converted to log Z (but then I may be wrong). Also, as per our earlier conversation, values of loZ>0 would be impossible, but Icat can be called with metallicity parameter greater than 0.

Maybe someone who's watching this can help?

[pllim]

Now I am confused as well. Is the documentation correct after all or does it still need to be changed? PySynphot package itself is not responsible for the quality of the data; it merely reads in what is provided.

@rizeladiaz , do you have any clarifications on this?

[rizeladiaz]

MIles and Mario,

can we meet next wednesday to talk about it? I can meet at 2 pm

[pllim]

Update: Documentation is to be updated as https://jira.stsci.edu/browse/REDCAT-47 .

[pllim]

@mgennaro , the fix is now in dev and will be folded into the next release. Thanks for bringing this to our attention!