Details
-
Type:
Story
-
Status: Done
-
Resolution: Done
-
Fix Version/s: None
-
Component/s: meas_mosaic
-
Labels:
-
Story Points:1
-
Team:Data Release Production
Description
Furusawa-san pointed out that coaddDriver can produce outputs even if mosaicking has not been run though doApplyUberCal=True (which is the default value for HSC). This appears to be due to allowing null values of the wcs and ffp in updateExposure.py.
We should allow the functions in there to fail if the appropriate values are not available, or the user can be deceived as to what corrections have actually been applied.
Attachments
Issue Links
- blocks
-
- Done
Activity
If the user is permited to run with either doSolveWcs = False or doSolveFlux = False, then they should also be given the option to apply only the results they fit for. I know John Swinbank found this very useful in the getting-things-working-with-the-LSST-stack phase, but perhaps you no longer see a need/use for it? If those options are left in, could we also make their applications user configurable (defaulted to what you've got now, i.e. fail if not present, but may be skippable if explicitly requested)? Otherwise, I think they should be removed.
Supporting astrometry and photometry ubercal application separately would involve configuration changes in pipe_tasks which I would like to avoid: firstly because that would add an RFC overhead from renaming config parameters when I'm trying to get this change in quickly for the next HSC release; and secondly because anything I put in might be revised when we get jointcal (John Parejko) soon. I think it's fine for mosaic to run the astrometry and photometry solutions separately, but when we apply those solutions we want to (and the current pipe_tasks code restricts us to) apply them both together. Is this reasonable, Lauren MacArthur and John Swinbank?
Bob Armstrong, are you able to review this, please?
Paul Price
added a comment - Supporting astrometry and photometry ubercal application separately would involve configuration changes in pipe_tasks which I would like to avoid: firstly because that would add an RFC overhead from renaming config parameters when I'm trying to get this change in quickly for the next HSC release; and secondly because anything I put in might be revised when we get jointcal ( John Parejko ) soon. I think it's fine for mosaic to run the astrometry and photometry solutions separately, but when we apply those solutions we want to (and the current pipe_tasks code restricts us to) apply them both together. Is this reasonable, Lauren MacArthur and John Swinbank ?
Bob Armstrong , are you able to review this, please? Is this reasonable, Lauren MacArthur and John Swinbank?
No objection from me.
Ditto
Looks good. No comments from me.
Thanks Bob.
Merged to master.
Paul Price
added a comment - Thanks Bob.
Merged to master. 
Bob Armstrong, are you able to review this, please?
Lauren MacArthur, if you're able to have a look, that'd be great too, but I know you're away at the moment.
price@pap-laptop:~/LSST/meas_mosaic (tickets/DM-10546=) $ git subcommit 6ea395a4ce466e7d67e8004b2d81def6a09ac6c2Author: Paul Price <price@astro.princeton.edu>Date: Wed May 17 15:58:11 2017 +0900updateExposure: allow exceptions if data doesn't existThe various functions to retrieve and apply the correction datawere silently proceeding in the event that the data did not exist,misleading the user. Instead, allow exceptions to bubble up ---the user asked us to retrieve and/or apply the correction, so ifwe can't do that there's a problem that the user needs to knowabout.python/lsst/meas/mosaic/updateExposure.py | 101 ++++++++++++++----------------1 file changed, 48 insertions(+), 53 deletions(-)