Thanks for all those clarifications. A few thoughts in response:
While I like the idea of splitting out the single visit components and merging in stages, the single visit analysis class inherits from the coadd analysis class, so it's not really practical (although probably not impossible...do let me know if you think it's worth the restructuring).
Since you're not planning to merge any of the analysis script to master at the moment, this isn't necessary. When merges to master do happen, they should obviously only contain finished & reviewed code, so if you did want to push the single visit analysis in before the coadd stuff was ready there'd be an issue... but you don't, so no problem.
I don't think the single visit analysis code had previously been exercised thoroughly as the qa focus for HSC has been on coadd outputs, so I also made some updates to fix/improve some of the plotting. This is also why I did not just run the HSC side equivalent to show that the outputs agree. I could do this (and perhaps coordinate with Paul about backporting my changes to his script) if you think it's worth it.
I don't think this is necessary, except insofar as Paul thinks your changes would be useful on the HSC side, so long as Robert is happy that your output is sane and will constitute a useful comparison between the HSC and LSST stacks.
Can you point me to the HSC-specific code you are referring to?
I've not had time to seriously attempt to read or understand the analysis task, but just grepping for "hsc" produces a lot of results. For example here and here.
I may be able to test this conjecture on some decam data I ran through processDecamCcd.py a while back (I'll need to add datasets to the mapper)...perhaps that should be a separate ticket?
We're really under time pressure to finish the HSC merge. I'd rather see this work complete on HSC so we can declare the merge done, and worry about portability to other instrumentation later – don't spend any time on making this generic for now, but do feel free to file tickets describing what ought to be done in future.
Given all that ... what would you actually like me to do in terms of a review here? It sounds like the changes you've made to afw will go in as a separate ticket, which I'll stand ready to review when it appears; meanwhile there's no code which we expect to merge to the stack from this ticket, and Robert has volunteered to sanity check it. Is there anything I can add to that?