Uploaded image for project: 'Data Management'
  1. Data Management
  2. DM-4393

Get analysis script working for HSC/LSST stack comparisons

    XMLWordPrintable

    Details

    • Type: Story
    • Status: Done
    • Resolution: Done
    • Fix Version/s: None
    • Component/s: pipe_tasks
    • Labels:
      None
    • Story Points:
      6
    • Sprint:
      Science Pipelines DM-W16-3, Science Pipelines DM-W16-4
    • Team:
      Data Release Production

      Description

      A script for performing pipeline output QA is under development for HSC. The script provides many useful tools for plotting and analyzing pipeline outputs on single visits and coadds. This is of general use for LSST and, in particular, will be adapted/expanded to include tools for the direct comparisons of identical data sets processed with both the HSC and LSST pipelines (i.e. DM-2984). Appropriate adaptations for this script to run with the LSST stack will be made here (with the understanding that development is still ongoing on HSC and further adaptations will be accommodated as necessary/desired).

      See HSC-1320 and HSC-1359 for details and examples of the output of this script.

        Attachments

          Issue Links

            Activity

            Hide
            swinbank John Swinbank added a comment -

            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?

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

            Lauren and I just went over this and it looks fine. I had lots of comments, of course, about extra things to plot but that's out of scope!

            Show
            rhl Robert Lupton added a comment - Lauren and I just went over this and it looks fine. I had lots of comments, of course, about extra things to plot but that's out of scope!
            Hide
            lauren Lauren MacArthur added a comment -

            Thanks Robert Lupton!

            John Swinbank: I guess I'm just looking for a green light to call this ticked "done". I will create the new tickets discussed above tomorrow.

            Show
            lauren Lauren MacArthur added a comment - Thanks Robert Lupton ! John Swinbank : I guess I'm just looking for a green light to call this ticked "done". I will create the new tickets discussed above tomorrow.
            Hide
            swinbank John Swinbank added a comment -

            In that case, consider it green-lit!

            Show
            swinbank John Swinbank added a comment - In that case, consider it green-lit!
            Hide
            lauren Lauren MacArthur added a comment -

            Thanks John.

            I also meant to add that the occurrences of HSC-specific code you pointed to are part of the (recently added) color-color analysis which I have not looked at yet. When I do get to this (on a later ticket), I will look into making the camera-specific transformations a config that needs to be set by the obs_camera packages.

            Show
            lauren Lauren MacArthur added a comment - Thanks John. I also meant to add that the occurrences of HSC-specific code you pointed to are part of the (recently added) color-color analysis which I have not looked at yet. When I do get to this (on a later ticket), I will look into making the camera-specific transformations a config that needs to be set by the obs_camera packages.

              People

              Assignee:
              lauren Lauren MacArthur
              Reporter:
              lauren Lauren MacArthur
              Reviewers:
              John Swinbank
              Watchers:
              John Swinbank, Lauren MacArthur, Paul Price, Robert Lupton
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:

                  Jenkins

                  No builds found.