If I wasn't concerned with history and backwards compatibility, I do like the name PhotoCalib somewhat better, and I felt it might be a clearer term for readers of LDM-151 who were not familiar with the stack. But I have no problem with continuing to call the code object Calib in the interest of backwards compatibility, or with renaming the term in LDM-151 for consistency with it.

I view the design John Parejko has proposed as an intermediate step towards what we eventually need: it adds spatial dependence without adding wavelength dependence, and does so in a way that we think will make it easy (and minimally disruptive) to add wavelength dependence in the future. When that happens, I expect us to add versions of most of the conversion functions that also ask for some sort of SED object, while leaving the existing ones to assume some canonical SED. I don't expect us to add a wavelength dimension to BoundedField, though; the methods exposing a BoundedField here will provide a way to get the spatial variation assuming a given or canonical SED, which we'll frequently want in order to scale images.

John Parejko and Russell Owen: I hadn't appreciated this in our previous discussion, but I think the above suggests we should add composition by making a BoundedField implementation backed by AST or our own composition-of-BoundedField implementation, rather than replacing the BoundedField objects with AST objects directly. If there is some other strong reason to have AST objects replace BoundedField (I can't think of one), we should consider removing it from the public interface here or clearly document those parts of the interface as placeholders.

I'm more than happy to change the name to PhotoCalib: that makes the intention clearer. Since this is breaking the current API anyway (e.g. getMagnitudes()->countsToMagnitudes()), changing the object's name now seems reasonable.

As to the rest of LDM-151, this seems like a reasonable step towards the end goal of the object described there, as Jim Bosch says above. Adding wavelength dependence seems like a logical next step (much like this one collapses to the current Calib for spatially-constant zero points). I'd rather work toward that incrementally as-needed, instead of trying to implement it all at once.

To a few of the points raised in LDM-151 9.9:

• BoundedField is already persistable, so this object should be trivially persistable.
• One could add absolute calibration to this by adding countsToJanskys() methods that take into account knowledge of the absolute calibration of the system.
• Uncertainty is currently constant across the field, but could be extended in the future with something more complicated.
• I'm not entirely sure what the point about representating rescalings means, but I believe it is included via the computeScalingTo method.

To Jim Bosch's comments re: AST and BoundedField, the current RFC only says that we should implement PhotoCalib with BoundedField for now. If we want to replace that with AST objects (possibly a good route to adding wavelength dependence), I'm fine with that, or with just backing BoundedField with AST. I don't have an opinion on that at the moment, and I don't think it's directly relevant to this RFC (but it's certainly a good topic to keep in mind for the future).

I'm fine with it. It's a good step in the right direction. My only question are mostly how this fits in to Jim Bosch, Merlin Fisher-Levine, and Robert Lupton 's vision of what will be necessary to report such calibration information.

My apologies for the delay.

As an object that's ultimately returned from the jointcal photometric fitter this sounds fine – the zero point at a point if we neglect the colour terms is well described by a BoundedBox. We're going to have to face the SED-dependance at some point soonish, but it's clearly out of scope for now.

Internally to the fitter the object must be much more complicated – it's a combination of things which depend on the detectors (so a tiled set of BoundedBoxes??), the filters (a function of position, maybe just a central wavelength and an equivalent width), the atmosphere (taken as uniform over each visit for now, but varying in time), the extinction (let's say gray for now), the distortion (the flats applied may or may not have taken this out – that depends on whether the sky has been subtracted), and probably other things that I can't recall just now. The fitter has to be able to solve for these simultaneously (with suitable precautions to return something sane for things that are under-constrained or nearly-fixed), and we need to be able to interrogate the results of the fitter for the separate components. For example, if I take the filter to be uniform (or described by low-order radial terms in equivalent width) I want to be able to ask for the CCD efficiency as a function of pixel position from a set of dithered images.

Similar comments apply to the astrometric solver of course.

Robert Lupton are you proposing that we instead implement that more complicated model now in PhotoCalib? The goal of this proposal is to build up a PhotoCalib (and, by extension, the jointcal model) one step at a time, as needed.

I think that we (you!) should continue to get jointcal photometry working. My second paragraph was intended to make that clear – this is fine as an output of jointcal for now, and maybe in the long-run.

What I am concerned about in this context is that your proposed PhotoCalib is not the sole long-term output of jointcal for the reasons given, so I want to be sure that this RFC is not taken to define what PhotoCalib will become.

I would hope that the BoundedField itself could combine the different models required to represent the spatially varying component of the PhotoCalib. That seems natural if BoundedField is defined in terms of AST models. Such a model could be expanded to include wavelength dependence, as well.

I'm proposing this now, because it's the minimum thing I need now, and we don't have a way to represent such a calib.

As I said above re:LDM-151, this is the proposal for a new PhotoCalib that has room to be extended in the future. We already know there needs to be an SED term eventually, and as Russell Owen says, one could make a composite BoundedField to represent a more complicated set of transforms.

My vision for the composition and tiling was indeed that it happen within the BoundedField.

I believe AST is an option for implementing that, though I should emphasize that my previous comment about where AST would go should not be taken to imply that I endorse using it here. Those kinds of implementation questions do to be considered in the larger context Robert Lupton brought up (and probably not on this ticket) - for example, for fitting we probably need to have objects that are not only composable/tileable but differentiable w.r.t. some set of parameters as well, and hence we may find ourselves having to reimplement a lot of what we may have thought AST would provide for us.

This proposal sounds good to me. It seems like the current proposal can go through with the understanding that the extensions need in the future may be available through a re-design of BoundedField.

Adopted as written above. Implementation ticket is DM-9192.

NOTE: One of the various changes in the final implementation is that I've removed the throwOnNegativeCounts argument, as it appears to be almost never used in the current stack.