Special handling for lines with broad wings-- either dense sampling or larger sparse arrays

[gully]

Some lines, such as Hydrogen, sodium, potassium, neutral metal lines, etc. have extremely broad line wings, approaching larger than the 1000-6000 pixels we allocate for the sparse implementation. These need to be handled separately from the weak lines, both from a computational performance perspective and an accuracy perspective.

Computational performance

We may actually gain performance by isolating these strong lines as dense (i.e. evaluated across the entire bandwidth), or semi-dense (i.e. evaluated across a large fraction of the bandwidth, say 50,000 pixels or 20% of the bandwidth), since we reduce the sparse evaluation window on all the other spectral lines from 6000 to 1000 pixels, or even less, perhaps as low as 100 pixels for most lines.

Accuracy

Extremely broad lines will exhibit truncation effects if the sparse window is small compared to the linewing size. The truncation effects will look like tophat functions severing the asymptotic wings. We can afford to increase the sparse window on a few, say ~20 spectral lines. We would then evaluate two matrices at each forward/backward pass of the emulator: ~330,000 x 20 for the dense broad-wing lines, and ~2000 x 8000 for the sparse narrow lines. The number of FLOPS in each category scales as ~6 Million versus ~16 Million, depending on the exact choices for wingcuts.

[gully]

We also have to pre-discover these broad lines. There are two conceivable strategies:

1. Flag the lines identifies as having broad widths in the heuristic scipy phase
2. Pre-bake the broad lines from known astrophysics line lists, such has Hydrogen, Sodium, Potassium, etc.

Each strategy has its pros and cons: how much hand-holding and specialized code they need, and whether we are being overzealous in over-including lines that are not actually broad for a particular Teff choice, for example. There's also a circular logic to pre-baking and then finding local minima, since scipy is likely to double-count the peaks that are imperfectly identified. I suppose we could smooth-and-then-fit, or "low-pass-filter-and-then-fit" as a way to find just the broadest lines.

In any case, this task should be doable, we just have to work on it.