search

Vital-Fernandez / lime

Line Measuring library in python
Other
16 stars 6 forks source link

Reference wavelengths missmatch with NIST #41

Open Knusper opened 1 month ago

Knusper commented 1 month ago

I noticed that the file https://github.com/Vital-Fernandez/lime/blob/master/src/lime/resources/parent_bands.txt (and thus also the output of lime.lime_bands) contains reference wavelengths that differ significantly from the reference wavelengths provided by NIST and Peter van Hoff's Line List.

For example, [OIII] 4995,5007:

Now, a common mistake is too query the databases for vacuum wavelengths, and then to convert back to air wavelengths. This approach is, however, only correct if the same formalism is used. In principle there does not exist an inversion for going from air to vacuum, only the other way around. Only the approach in VALD3 database seems to be "roundtrip" compatible: https://www.astro.uu.se/valdwiki/Air-to-vacuum%20conversion -- however, that doesn't mean that you get the "correct" air wavelengths as defined in the databases (needs to be checked),

The way adopted by atomic spectroscopists is to measure everything above 200 nm and below 10000 nm in air (standard atmosphere) and everything outside this boundary in vacuum.

A classical UV line is Lya, but also here you have strange vacuum reference values:

Best, ECH

Vital-Fernandez commented 1 month ago

Thank you @Knusper very much for your comment.

Currently there are two important wavelength values in LiMe.

  1. The first one is the "label" wavelength for example "O3_5007A" or "O3_0.5007um". If there isn't a "wavelength" column in the input bands or a "wavelength=value" key in the input configuration files LiMe will convert this string to a float for its initial wavelength value for the fitting and as the output "wavelength" column value in the output measurements frame.

  2. The second is the "wavelength" column in the input configuration bands.

For the former (label wavelengths) , I would like to use the default wavelength values that are used by astronomical packages which could use LiMe fluxes (for example Cloudy or PyNeb). However, so far these packages do not have a standard way to define these labels (Cloudy people are working on that for the next release). Currently, I am using round ups of the default database wavelengths (see next)

For the database wavelength I had picked values from NIST. However, most line fluxes are the result of multiple transitions contributing to the observed fluxes. These values are in vacuum and I convert them to air with Greisen et al. (2006) (astropy also uses this reference). This procedure is not very robust though... I would like to use FIASCO library to get a weighted wavelength... or use Cloudy default values...

Have you seen any standarised line wavelength in another package or survey?

Knusper commented 4 days ago

Thank you @Knusper very much for your comment. Currently there are two important wavelength values in LiMe.

1. The first one is the "label" wavelength for example "O3_5007A" or "O3_0.5007um".  If there isn't a "wavelength" column in the input bands or a "wavelength=value" key in the input configuration files LiMe will convert this string to a float for its initial wavelength value for the fitting and as the output "wavelength" column value in the output measurements frame.

2. The second is the "wavelength" column  in the input configuration bands.

Yes - this is clear.

For the former (label wavelengths) , I would like to use the default wavelength values that are used by astronomical packages which could use LiMe fluxes (for example Cloudy or PyNeb). However, so far these packages do not have a standard way to define these labels (Cloudy people are working on that for the next release). Currently, I am using round ups of the default database wavelengths (see next)

The labelling part is very clever constructed. It will be interesting to see what the cloudy people come up with, the lead authors have

For the database wavelength I had picked values from NIST. However, most line fluxes are the result of multiple transitions contributing to the observed fluxes. These values are in vacuum and I convert them to air with Greisen et al. (2006) (astropy also uses this reference). This procedure is not very robust though... I would like to use FIASCO library to get a weighted wavelength... or use Cloudy default values...

Have you seen any standarised line wavelength in another package or survey?> Thank you @Knusper very much for your comment. Currently there are two important wavelength values in LiMe.

1. The first one is the "label" wavelength for example "O3_5007A" or "O3_0.5007um".  If there isn't a "wavelength" column in the input bands or a "wavelength=value" key in the input configuration files LiMe will convert this string to a float for its initial wavelength value for the fitting and as the output "wavelength" column value in the output measurements frame.

2. The second is the "wavelength" column  in the input configuration bands.

Yes - this is clear.

For the former (label wavelengths) , I would like to use the default wavelength values that are used by astronomical packages which could use LiMe fluxes (for example Cloudy or PyNeb). However, so far these packages do not have a standard way to define these labels (Cloudy people are working on that for the next release). Currently, I am using round ups of the default database wavelengths (see next)

The labelling part is very clever constructed. It will be interesting to see what the cloudy people come up with, as the lead authors have a very long history in spectroscopic analysis. Nevertheless, I think what is used here is a good start.

For the database wavelength I had picked values from NIST. However, most line fluxes are the result of multiple transitions contributing to the observed fluxes. These values are in vacuum and I convert them to air with Greisen et al. (2006) (astropy also uses this reference). This procedure is not very robust though... I would like to use FIASCO library to get a weighted wavelength... or use Cloudy default values...

By default the NIST values are not in vacuum, rather lines below 200nm and above 2000nm are given in vacuum, the rest is in air. Of course, the default values can be overriden. The conversion of vacuum to air is explained in the NIST documentation, and they refer to this paper. I don't know how the Greisen et al. formalism compares to the NIST formalism, but perhaps the [OIII] example above indicates that there are non-neglible differences.

Have you seen any standarised line wavelength in another package or survey?

NIST, as per their mission, should always be the standard. CHIANTI (as queried with FIASCO) gets its input values from NIST. I think its advantage is that it contains quantites of astrophysical interest (collisional- and recombination rate coefficents) that are not available in NIST. For the wavelengths it should not matter.

Of course, the problems with the multiplets (fine- and hyper-fine structure) remains. CHIANTI calculates relative intensities (based on assumptions collisionally excited lines), perhaps these could be used as weights?

Honestly, the topic seems quite messy, and each astrophysicist seems to have it's own line list somehow (it depends also on the spectral resolution they work with and the sub-field). I always rely on PvH's line list. See also his short paper: https://www.mdpi.com/2075-4434/6/2/63

He is also responsive to questions via email.