LSSTDESC
Refactor image/stamp workflow
The latest commit aligns photon objects in the photon pooling pipeline with their positions in the original pipeline.
The latest set of commits should address most of the comments above. I'll respond to those individually. A couple do still need to be looked at.
Are you waiting on me for anything here? I thought you still had some more comments to address, so I was waiting for that to be done. But if it would be helpful for me to review this again at this point, let me know.
Not just yet -- I have a couple more commits on the way with fixes and tests for the batching. I'll push these later today or tomorrow, and then I think that should be everything ready for review again.
I think this is ready for re-review now, though CI is failing with an error in test_stamp_bandpass_airmass from numpy coming through GalSim. I saw the same error a couple of weeks ago on an ARM system when using GalSim 2.6 which introduces its own utilities.least_squares(). I wasn't able to investigate further before the system went down and only came back up yesterday.
I think there is actually one more commit incoming. I've realised that in edge cases where nominally bright photon objects' phot_flux falls below nbatch, we can end up with batches containing objects with 0 flux. I think I have a fix, by having these objects be treated as faint objects for batching purposes. I'll test this and if all is well push it tomorrow.
Assuming tests pass, that should be everything above. I've included changes to RubinOptics to use stamp_center rather than image_pos, changing the tests to fit, but let me know if you don't like that and I'll revert it.
I'll move on to seeing if I can make the old photon ops tests match the new ones as suggested.
I've just created PR #484 which corrects the photon op tests to be self-consistent. There were actually a couple of inconsistencies in the tests here too, but working through them now means everything should be in alignment pre- and post-photon pooling.
I hope this means that once #484 is merged in, this can be, too.