# meas.mosaic.updateExposure.applyMosaicResultsExposure will not if there is no mosaic solution

XMLWordPrintable

## Details

• Type: Story
• Status: Done
• Resolution: Done
• Fix Version/s: None
• Component/s:
• 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.

## Activity

Hide
Paul Price added a comment -

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 sub commit 6ea395a4ce466e7d67e8004b2d81def6a09ac6c2 Author: Paul Price  Date: Wed May 17 15:58:11 2017 +0900    updateExposure: allow exceptions if data doesn't exist    The various functions to retrieve and apply the correction data  were 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 if  we can't do that there's a problem that the user needs to know  about.    python/lsst/meas/mosaic/updateExposure.py | 101 ++++++++++++++----------------  1 file changed, 48 insertions(+), 53 deletions(-)  Show Paul Price added a comment - 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 sub commit 6ea395a4ce466e7d67e8004b2d81def6a09ac6c2 Author: Paul Price <price@astro.princeton.edu> Date: Wed May 17 15:58:11 2017 +0900   updateExposure: allow exceptions if data doesn't exist The various functions to retrieve and apply the correction data were 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 if we can't do that there's a problem that the user needs to know about.   python/lsst/meas/mosaic/updateExposure.py | 101 ++++++++++++++---------------- 1 file changed, 48 insertions(+), 53 deletions(-)
Hide
Lauren MacArthur added a comment -

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.

Show
Lauren MacArthur added a comment - 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.
Hide
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?

Show
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?
Hide
John Swinbank added a comment -

Is this reasonable, Lauren MacArthur and John Swinbank?

No objection from me.

Show
John Swinbank added a comment - Is this reasonable, Lauren MacArthur and John Swinbank? No objection from me.
Hide
Lauren MacArthur added a comment -

Ditto

Show
Lauren MacArthur added a comment - Ditto
Hide
Bob Armstrong added a comment -

Looks good. No comments from me.

Show
Bob Armstrong added a comment - Looks good. No comments from me.
Hide
Paul Price added a comment -

Thanks Bob.

Merged to master.

Show
Paul Price added a comment - Thanks Bob. Merged to master.

## People

• Assignee:
Paul Price
Reporter:
Paul Price
Reviewers:
Bob Armstrong
Watchers:
Bob Armstrong, John Swinbank, Lauren MacArthur, Paul Price
0 Vote for this issue
Watchers:
4 Start watching this issue

## Dates

• Created:
Updated:
Resolved: