Support for wider NIRCam detector wavelengths

[ariedel]

The filter bandpasses defined for the JWST ETC require PSFs that cover: sw detector: 0.58199 to 2.425 microns lw detector: 2.33587 to 5.09955 microns

To support this, I've been manually editing code in webbpsf_core.py to change the wavelength limits to 0.5-2.5 microns (sw) and 2.2-5.5 microns (lw), but the very fact that it's manual means it's error prone and I'd like to avoid that.

I would like to get some kind of formal support for this. An optional boolean that would unlock larger wavelength limits while requiring manual specification of the detector would be fine.

[mperrin]

@shanosborne when you get back from break, would you be able to work on this for Adric, please?

[JarronL]

Is there any reason we cannot just say:

SHORT_WAVELENGTH_MIN = 0.5 * 1e-6
SHORT_WAVELENGTH_MAX = 2.5 * 1e-6
LONG_WAVELENGTH_MIN = 2.2 * 1e-6
LONG_WAVELENGTH_MAX = 5.5 * 1e-6

It seems these variables are only ever used to check the validity of filter wavelength ranges, or custom monochromatic wavelengths specified when generating a PSF.

I actually always modify these variables in my pynrc NIRCam code in order to access shorter wavelengths for the LW channel, for instance. Using a single cut-off between the SW/LW transition point has problems, because generalized code using webbpsf will likely calculate PSFs beyond the cut-off even though the throughputs are near 0.

[ariedel]

@JarronL I had the impression that somewhere else in the code WebbPSF uses those variables to check which detector to apply if it's not otherwise specified.

[mperrin]

Shoot, this one fell through the cracks, didn't it. Apologies @ariedel, not sure how that happened. We should see what we can do to resolve this promptly now.

[mperrin]

Does the existing option nrc..auto_channel = False not suffice for this case?

[ariedel]

Actually, I think @JarronL is correct and the wavelengths are only used to validate a setup, not choose it.