New sensor models and auto-switch for ITL or e2v

[welucas2]

Craig Lage has provided us with new models of the ITL and e2v sensors used in LSSTCam which use four points along each pixel edge; previous models (provided with GalSim) use 8 and 32 points. Using lower resolution sensor models saves memory, which is particularly helpful for the photon pooling pipeline in which the full detector has to be retained in memory.

I've added all the models, including those we had previously, to the imSim repository. A new pair of tests (heavily inspired by GalSim's test_sensor.py) check the various models and ensure that the spot size doesn't differ more than would be expected across the different model resolutions, and regression tests are there on the second moments and ellipticities of generated in the test images.

Finally, I noticed while doing this that imSim was always using the default SiliconSensor model from GalSim, which is the 8-point ITL model. I added a little logic to lsst_image.py in the image setup that switches the sensor between the 4-point ITL and e2v models according to which LSSTCam detector is being simulated -- unleass a sensor model name has already been given in the config, in which case that's used instead.

[welucas2]

test_atm_psf_fft is failing on an assertion that requires the FWHM of the source drawn with a photon shooting reference image and then with FFT to be consistent to within 8%:

FWHM of reference PSF: 0.8782953667200731
FWHM of FFT PSF: 0.9589184638055415

with

> np.testing.assert_allclose(ref_img.view(scale=0.2).calculateFWHM(), img.view(scale=0.2).calculateFWHM(), rtol=0.08)
E AssertionError:
E Not equal to tolerance rtol=0.08, atol=0
E
E Mismatched elements: 1 / 1 (100%)
E Max absolute difference among violations: 0.08062313
E Max relative difference among violations: 0.08407714
E ACTUAL: array(0.878295)
E DESIRED: array(0.958918)

I haven't yet been able to reproduce this on either my own Mac or Perlmutter where all the tests complete successfully, but I do find that the FWHMs reported were passing and consistent across different LSST pipelines releases until at least w_2025_07, then changing:

• My Mac with release v28.0.0 passes with

FWHM of reference PSF:  0.9679986011305037
FWHM of FFT PSF:  0.9590216810458915

• Perlmutter with release v28.0.0 passes identically to previous

FWHM of reference PSF:  0.9679986011305037
FWHM of FFT PSF:  0.9590216810458915

• Perlmutter with release w_2025_07 passes identically to previous

FWHM of reference PSF:  0.9679986011305037
FWHM of FFT PSF:  0.9590216810458915

• Perlmutter with release w_2025_07 passes identically to previous

FWHM of reference PSF:  0.9679986011305037
FWHM of FFT PSF:  0.9590216810458915

• Perlmutter with release w_2025_10 passes, just, with relative difference of 0.0765, with different values

FWHM of reference PSF:  0.8855398558204481
FWHM of FFT PSF:  0.9588756007275189

The values above are identical across both main and this PR's branch for a given pipelines release. That last pair of FWHMs looks very close to the ones which caused the test to fail in the latest CI run. I suspect that something in this particular test is sensitive to a change in the pipeline, now causing it to fail this assertion.

[jmeyers314]

That's very weird. Can you extract the actual images (both Perlmutter w_2025_07 and w_2025_10 perhaps?) I wonder if that'd show something obvious to check.

[rmjarvis]

On my machine with galsim 2.6.1, I get

FWHM of reference PSF:  0.9679986011305037
FWHM of FFT PSF:  0.9590216810458915

So it's not something with the latest galsim version. Maybe numpy changed something? Seems weird, but I can't think what else in the environment would be a likely culprit. We don't go too crazy with our dependencies in GalSIm, and the AtmosphericPSF class being used in that test doesn't seem to use any lsst stack details. So I don't think there should be too much in the dependency list that is even relevant to this.

If you can reproduce this locally, it would probably be helpful to try to figure out what env changes make the problem appear. (Sorry, I know that might be quite tedious.) Maybe that will give us a clue.

[welucas2]

Thanks @jmeyers314 @rmjarvis, I'll take a look and see if anything turns up.

[welucas2]

I think I've found the problem. The images are identical (thanks for the suggestion!) so I looked into how the FWHM itself was being calculated from them. It turns out that how np.argsort() sorts the equal-valued elements of your array is determined by your NumPy version. I've just created a GalSim issue with more detail. I need to check with NumPy 2.2.6 now (as was used in CI here) but I expect I'll be able to reproduce the small FWHM from the test and see argsort as the cause for it.

[jmeyers314]

Looks like there's a kind="stable" argument to argsort. Bet that'd help.

[jmeyers314]

Ah. I see you already mentioned that in the other thread...

[rmjarvis]

I'm looking into how best to address the GalSim issue, but for this imsim test, I think you can just remove the FWHM test. The MomRadius test is already doing a sufficient check, so I don't think we also need the FWHM one.

[welucas2]

I've just rebased onto main after merging #494.

[rmjarvis]

LGTM. Just one very minor suggestion.

[rmjarvis]

I think you could probably just test that image0 and image1 are equal above and then only test 2,3,4 against one of them, rather than duplicating these tests for 0 and 1.

[welucas2]

Yes, that's probably overkill! I've just condensed these as requested.

[rmjarvis]

lgtm

[welucas2]

Thanks! Merging in now.