Status: To Do
Fix Version/s: None
While working on the implementation of RFC-593 (on
DM-18610, though the changes should have been on DM-19392 - that's another story), I rediscovered Box's "flipTB" and "flipLR" methods, which were added ages ago (trac ticket 1767, in September 2011) by Simon Krughoff (apparently with input from me, according to git) to aid in amp assembly. Their documentation was pretty vague, but I thought I could guess more or less what they were supposed to do.
I then tried to reimplement them by delegating to some new methods I added ("reflectedAboutX" and "reflectedAboutY") that I did know how to clearly document, and I got the existing tests for the "flip" methods passing. But then Krzysztof Findeisen pointed out that my implementation for the "reflected" methods had a pretty clear logic bug, and fixing it broke the tests for the "flip" methods, indicating that my guess about their behavior was pretty clearly wrong.
Simon (or maybe Paul Price or Robert Lupton, who may have encountered them over the years), do you remember what these do well enough to be able to describe what they do? If so, can you also comment on whether they really are fundamental operations on Boxes vs. something rather specific to amp assembly?
Some possibly helpful links to jog memories:
- The trac ticket where they first appeared: https://dev.lsstcorp.org/trac/ticket/1767
- The current docstrings: https://github.com/lsst/geom/blob/master/include/lsst/geom/Box.h#L232
- The only place they're used in afw (maybe the only place they're used anywhere): https://github.com/lsst/afw/blob/master/python/lsst/afw/cameraGeom/assembleImage.py#L144
Normally, I wouldn't consider a documentation archaeology project like this to be a high priority, but amplifier assembly is both an intrinsically a complicated piece of bookkeeping and something we're going to be dealing with more often as we get to commissioning, and I'm worried about leaving a key part of it to methods with unclear behavior.