isotopic abundance corrections mess up default radiative gamma recipe

[ajwheeler]

When the radiative broadening factor is not available, it is estimated from the wavelength and log_gf value. That log_gf value will be wrong if it was adjusted for isotopic abundances.

173 addresses this for turbospectrum and VALD linelists in the case that Korg does the adjustment itself, but in cases where VALD has already done the adjustment, it's not obvious what should be done.

options:

• Nothing, just add a warning to the documentation. (I don't like this one.)
• Refuse to parse. This is easy and prevents things from going wrong, but it would likely annoy people.
• Try to do things correctly. We could in principle undo the adjustment if we knew what VALD assumed, and it will work as long as they never change it. This is the most seemless, but it's also brittle.

[andycasey]

I think it's unacceptable to refuse to parse. There are plenty of papers that use VALD line lists as-is on scientific investigations where they should have changed the isotopic mixture. Rightly or wrongly, because those papers are published it means at least someone in the community said that was OK (maybe because they didn't know the consequences). It's good to hope for a higher standard, but I don't think we can enforce it by just not parsing.

As we discussed on Slack, I'm not sure that we can even do things correctly here. I can't seem to find what isotopic fractions VALD assumed for any element. Thankfully, it doesn't seem to be an option for the user to change, otherwise users could change their mixtures and the mixture would not be outputted in the VALD format, which would make it totally impossible to undo.

I think the right balance here could be:

• Add a documentation page on line lists, which includes a section on VALD.
• Parse VALD line lists, but emit a warning if isotopic scaling has been applied. That warning should refer users to the documentation page and encourage them to disable isotopic scaling in VALD.
• If we can get the isotopic mixtures from VALD, and it's never changed, then we could keep the warning (for future proofing against isotopic mixture changes) but undo the adjustment when estimating radiative broadening factors.

If we did this I'd say that the documentation page should highlight exactly why this is an issue, with some figures. I am thinking something like:

1. A figure showing a synthesis with/without isotopic scaling to show how dramatic the effect can be.
2. A figure showing a synthesis with the radiative broadening factor of a few lines correctly estimated from the unscaled loggf, and with the radiative broadening factor incorrectly estimated from the unscaled loggf.

But doing any of this also means we should also make it easy and well-documented for users to adjust the line list to a new isotopic mixture. You've already got the logic for this, but it's not yet in an idiot-proof set of functions in Korg (AFAIK). On that note: doing this would mean you'd have to keep track of the current isotopic mixtures in the line list object, right?

[ajwheeler]

I think emitting a warning, and creating a docs page is a good option.

But doing any of this also means we should also make it easy and well-documented for users to adjust the line list to a new isotopic mixture. You've already got the logic for this, but it's not yet in an idiot-proof set of functions in Korg (AFAIK).

Not yet, correct. Part of the hesitation has that really isotopes should be more deeply integrated into Korg than they currently are. It's easy to enough to to linelist preprocessing, and I suppose I could write functions to make it easier, but I'm kind of inclined to hold off on making it dead-easy to adjust isotopes until there's a solution I'm happier with.

On that note: doing this would mean you'd have to keep track of the current isotopic mixtures in the line list object, right? I don't think so. It could be convenient, but I really like that a linelist is currently just a vector of Line objects. It might not be rational, but I don't really like it when libraries force me to use fancy types unnecessarily.