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

Add initial support for Gen3 Butler to obs_decam

    Details

      Description

      In order to best support AP PipelineTask conversion work at PCW2019, we need to have a Gen3 data repository for ap_verify_hits2015 (or maybe ap_verify_ci_hits2015, or both?).

      Anyhow, first step towards that is Gen3 Butler support for obs_decam, which is what this ticket is about.  That includes:

      • Writing an Instrument subclass for DECam.  The docs for the base class should tell you most of what you need to do (though I've just discovered they're not appearing in the Sphinx HTML for some reason), but I'm sure a concrete example will be even more useful, which HSC provides.  Note that because this will be only the second Instrument subclass, it's probable we'll find we want to adjust the ABC-subclass boundary a bit.
      • Writing a Formatter for raw DECam data (or if necessary, different formatters for different CCDs), probably by inheriting from FitsRawFormatterBase.  Once again, you can use HSC as an example.  This should do the same thing as the Gen2 CameraMapper's std_raw method.  A test that shows the kind of consistency we expect (for HSC) can be found in ci_hsc_gen2 - note that the Gen3 version generally tries much harder to clean things up and make things are components are internally consistent, so it may not be possible to make them entirely consistent with the Gen2 version.  We may not have a good place to put such a test for DECam until we're further along converting an actual test dataset, but it'd be great to write one for one-off testing now and attach it to this ticket, with the expectation that we'll put it in a CI'd package in the future.

      After those steps (and after running the Instrument class's register method on a Gen3 repo), I think it should be possible to run the Gen3 raw ingest task on DECam, and I consider that the end point for this ticket as long as any unexpected problems aren't huge.   This will rely a lot on the DECam translator in astro_metadata_translator as well as the above, but I think that's already working.

      Note that there's no command-line driver script for that task yet, but it's pretty straightforward to run from an interactive Python prompt.  Given that we know that DECam has buggy boresight information in the headers, I don't expect it to populate the database with good spatial regions yet, and I'm okay with fixing that on another ticket (probably by using astro_metadata_translator's on-the-fly header-patching system to just fix the boresight values to something we've fit for the test data we care about).

      Please ping #dm-middleware on Slack with any questions.

        Attachments

          Issue Links

            Activity

            jbosch Jim Bosch created issue -
            jbosch Jim Bosch made changes -
            Field Original Value New Value
            Description In order to best support AP PipelineTask conversion work at PCW2019, we need to have a Gen3 data repository for {{ap_verify_hits2015}} (or (maybe {{ap_verify_ci_hits2015}}, or both?).

            The first step towards that is Gen3 Butler support for obs_decam, which is what this ticket is about.  That includes:
             * Writing an [Instrument|https://github.com/lsst/daf_butler/blob/7220349561d794e99e523aff29bdb5c3bd80f379/python/lsst/daf/butler/instrument.py#L36] subclass for DECam.  The docs for the base class should tell you most of what you need to do (though I've just discovered they're not appearing in the Sphinx HTML for some reason), but I'm sure a concrete example will be even more useful, which [HSC|https://github.com/lsst/obs_subaru/blob/e6ea06fa94726c5b0f3c7e020223bbc1a58a2d70/python/lsst/obs/subaru/gen3/hsc/instrument.py#L50] provides.  Note that because this will be only the second {{Instrument}} subclass, it's probable we'll find we want to adjust the ABC-subclass boundary a bit.
             * Writing a {{Formatter}} for raw DECam data (or if necessary, different formatters for different CCDs), probably by inheriting from [FitsRawFormatterBase|https://github.com/lsst/obs_base/blob/master/python/lsst/obs/base/fitsRawFormatterBase.py#L29].  Once again, you can use [HSC|https://github.com/lsst/obs_subaru/blob/e6ea06fa94726c5b0f3c7e020223bbc1a58a2d70/python/lsst/obs/subaru/gen3/hsc/rawFormatter.py#L38] as an example.  This should do the same thing as the Gen2 CameraMapper's {{std_raw}} method.  A test that shows the kind of consistency we expect (for HSC) can be found in [ci_hsc_gen2 |https://github.com/lsst/ci_hsc_gen2/blob/tickets/DM-19817/tests/test_butlerShims.py#L81]- note that the Gen3 version generally tries much harder to clean things up and make things are components are internally consistent, so it may not be possible to make them entirely consistent with the Gen2 version.  We may not have a good place to put such a test for DECam until we're further along converting an actual test dataset, but it'd be great to write one for one-off testing now and attach it to this ticket, with the expectation that we'll put it in a CI'd package in the future.

            After those steps (and after running the {{Instrument}}} class's {{register}} method on a Gen3 repo), I think it should be possible to run the [Gen3 raw ingest task|https://github.com/lsst/obs_base/blob/master/python/lsst/obs/base/gen3/ingest.py] on DECam, and I consider that the end point for this ticket as long as any unexpected problems aren't huge.   This will rely a lot on the DECam translator in {{astro_metadata_translator}} as well as the above, but I think that's already working.

            Note that there's no command-line driver script for that task yet, but it's pretty straightforward to run from an interactive Python prompt.  Given that we know that DECam has buggy boresight information in the headers, I don't expect it to populate the database with good spatial regions yet, and I'm okay with fixing that on another ticket (probably by using {{astro_metadata_translator's}} on-the-fly header-patching system to just fix the boresight values to something we've fit for the test data we care about).

            Please ping #dm-middleware on Slack with any questions.
            In order to best support AP PipelineTask conversion work at PCW2019, we need to have a Gen3 data repository for {{ap_verify_hits2015}} (or maybe {{ap_verify_ci_hits2015}}, or both?).

            Anyhow, first step towards that is Gen3 Butler support for obs_decam, which is what this ticket is about.  That includes:
             * Writing an [Instrument|https://github.com/lsst/daf_butler/blob/7220349561d794e99e523aff29bdb5c3bd80f379/python/lsst/daf/butler/instrument.py#L36] subclass for DECam.  The docs for the base class should tell you most of what you need to do (though I've just discovered they're not appearing in the Sphinx HTML for some reason), but I'm sure a concrete example will be even more useful, which [HSC|https://github.com/lsst/obs_subaru/blob/e6ea06fa94726c5b0f3c7e020223bbc1a58a2d70/python/lsst/obs/subaru/gen3/hsc/instrument.py#L50] provides.  Note that because this will be only the second {{Instrument}} subclass, it's probable we'll find we want to adjust the ABC-subclass boundary a bit.
             * Writing a {{Formatter}} for raw DECam data (or if necessary, different formatters for different CCDs), probably by inheriting from [FitsRawFormatterBase|https://github.com/lsst/obs_base/blob/master/python/lsst/obs/base/fitsRawFormatterBase.py#L29].  Once again, you can use [HSC|https://github.com/lsst/obs_subaru/blob/e6ea06fa94726c5b0f3c7e020223bbc1a58a2d70/python/lsst/obs/subaru/gen3/hsc/rawFormatter.py#L38] as an example.  This should do the same thing as the Gen2 CameraMapper's {{std_raw}} method.  A test that shows the kind of consistency we expect (for HSC) can be found in [ci_hsc_gen2 |https://github.com/lsst/ci_hsc_gen2/blob/tickets/DM-19817/tests/test_butlerShims.py#L81]- note that the Gen3 version generally tries much harder to clean things up and make things are components are internally consistent, so it may not be possible to make them entirely consistent with the Gen2 version.  We may not have a good place to put such a test for DECam until we're further along converting an actual test dataset, but it'd be great to write one for one-off testing now and attach it to this ticket, with the expectation that we'll put it in a CI'd package in the future.

            After those steps (and after running the {{Instrument}}} class's {{register}} method on a Gen3 repo), I think it should be possible to run the [Gen3 raw ingest task|https://github.com/lsst/obs_base/blob/master/python/lsst/obs/base/gen3/ingest.py] on DECam, and I consider that the end point for this ticket as long as any unexpected problems aren't huge.   This will rely a lot on the DECam translator in {{astro_metadata_translator}} as well as the above, but I think that's already working.

            Note that there's no command-line driver script for that task yet, but it's pretty straightforward to run from an interactive Python prompt.  Given that we know that DECam has buggy boresight information in the headers, I don't expect it to populate the database with good spatial regions yet, and I'm okay with fixing that on another ticket (probably by using {{astro_metadata_translator's}} on-the-fly header-patching system to just fix the boresight values to something we've fit for the test data we care about).

            Please ping #dm-middleware on Slack with any questions.
            swinbank John Swinbank made changes -
            Description In order to best support AP PipelineTask conversion work at PCW2019, we need to have a Gen3 data repository for {{ap_verify_hits2015}} (or maybe {{ap_verify_ci_hits2015}}, or both?).

            Anyhow, first step towards that is Gen3 Butler support for obs_decam, which is what this ticket is about.  That includes:
             * Writing an [Instrument|https://github.com/lsst/daf_butler/blob/7220349561d794e99e523aff29bdb5c3bd80f379/python/lsst/daf/butler/instrument.py#L36] subclass for DECam.  The docs for the base class should tell you most of what you need to do (though I've just discovered they're not appearing in the Sphinx HTML for some reason), but I'm sure a concrete example will be even more useful, which [HSC|https://github.com/lsst/obs_subaru/blob/e6ea06fa94726c5b0f3c7e020223bbc1a58a2d70/python/lsst/obs/subaru/gen3/hsc/instrument.py#L50] provides.  Note that because this will be only the second {{Instrument}} subclass, it's probable we'll find we want to adjust the ABC-subclass boundary a bit.
             * Writing a {{Formatter}} for raw DECam data (or if necessary, different formatters for different CCDs), probably by inheriting from [FitsRawFormatterBase|https://github.com/lsst/obs_base/blob/master/python/lsst/obs/base/fitsRawFormatterBase.py#L29].  Once again, you can use [HSC|https://github.com/lsst/obs_subaru/blob/e6ea06fa94726c5b0f3c7e020223bbc1a58a2d70/python/lsst/obs/subaru/gen3/hsc/rawFormatter.py#L38] as an example.  This should do the same thing as the Gen2 CameraMapper's {{std_raw}} method.  A test that shows the kind of consistency we expect (for HSC) can be found in [ci_hsc_gen2 |https://github.com/lsst/ci_hsc_gen2/blob/tickets/DM-19817/tests/test_butlerShims.py#L81]- note that the Gen3 version generally tries much harder to clean things up and make things are components are internally consistent, so it may not be possible to make them entirely consistent with the Gen2 version.  We may not have a good place to put such a test for DECam until we're further along converting an actual test dataset, but it'd be great to write one for one-off testing now and attach it to this ticket, with the expectation that we'll put it in a CI'd package in the future.

            After those steps (and after running the {{Instrument}}} class's {{register}} method on a Gen3 repo), I think it should be possible to run the [Gen3 raw ingest task|https://github.com/lsst/obs_base/blob/master/python/lsst/obs/base/gen3/ingest.py] on DECam, and I consider that the end point for this ticket as long as any unexpected problems aren't huge.   This will rely a lot on the DECam translator in {{astro_metadata_translator}} as well as the above, but I think that's already working.

            Note that there's no command-line driver script for that task yet, but it's pretty straightforward to run from an interactive Python prompt.  Given that we know that DECam has buggy boresight information in the headers, I don't expect it to populate the database with good spatial regions yet, and I'm okay with fixing that on another ticket (probably by using {{astro_metadata_translator's}} on-the-fly header-patching system to just fix the boresight values to something we've fit for the test data we care about).

            Please ping #dm-middleware on Slack with any questions.
            In order to best support AP PipelineTask conversion work at PCW2019, we need to have a Gen3 data repository for {{ap_verify_hits2015}} (or maybe {{ap_verify_ci_hits2015}}, or both?).

            Anyhow, first step towards that is Gen3 Butler support for obs_decam, which is what this ticket is about.  That includes:
             * Writing an [Instrument|https://github.com/lsst/daf_butler/blob/7220349561d794e99e523aff29bdb5c3bd80f379/python/lsst/daf/butler/instrument.py#L36] subclass for DECam.  The docs for the base class should tell you most of what you need to do (though I've just discovered they're not appearing in the Sphinx HTML for some reason), but I'm sure a concrete example will be even more useful, which [HSC|https://github.com/lsst/obs_subaru/blob/e6ea06fa94726c5b0f3c7e020223bbc1a58a2d70/python/lsst/obs/subaru/gen3/hsc/instrument.py#L50] provides.  Note that because this will be only the second {{Instrument}} subclass, it's probable we'll find we want to adjust the ABC-subclass boundary a bit.
             * Writing a {{Formatter}} for raw DECam data (or if necessary, different formatters for different CCDs), probably by inheriting from [FitsRawFormatterBase|https://github.com/lsst/obs_base/blob/master/python/lsst/obs/base/fitsRawFormatterBase.py#L29].  Once again, you can use [HSC|https://github.com/lsst/obs_subaru/blob/e6ea06fa94726c5b0f3c7e020223bbc1a58a2d70/python/lsst/obs/subaru/gen3/hsc/rawFormatter.py#L38] as an example.  This should do the same thing as the Gen2 CameraMapper's {{std_raw}} method.  A test that shows the kind of consistency we expect (for HSC) can be found in [ci_hsc_gen2 |https://github.com/lsst/ci_hsc_gen2/blob/tickets/DM-19817/tests/test_butlerShims.py#L81]- note that the Gen3 version generally tries much harder to clean things up and make things are components are internally consistent, so it may not be possible to make them entirely consistent with the Gen2 version.  We may not have a good place to put such a test for DECam until we're further along converting an actual test dataset, but it'd be great to write one for one-off testing now and attach it to this ticket, with the expectation that we'll put it in a CI'd package in the future.

            After those steps (and after running the {{Instrument}} class's {{register}} method on a Gen3 repo), I think it should be possible to run the [Gen3 raw ingest task|https://github.com/lsst/obs_base/blob/master/python/lsst/obs/base/gen3/ingest.py] on DECam, and I consider that the end point for this ticket as long as any unexpected problems aren't huge.   This will rely a lot on the DECam translator in {{astro_metadata_translator}} as well as the above, but I think that's already working.

            Note that there's no command-line driver script for that task yet, but it's pretty straightforward to run from an interactive Python prompt.  Given that we know that DECam has buggy boresight information in the headers, I don't expect it to populate the database with good spatial regions yet, and I'm okay with fixing that on another ticket (probably by using {{astro_metadata_translator's}} on-the-fly header-patching system to just fix the boresight values to something we've fit for the test data we care about).

            Please ping #dm-middleware on Slack with any questions.
            swinbank John Swinbank made changes -
            Assignee John Parejko [ parejkoj ]
            swinbank John Swinbank made changes -
            Epic Link DM-20336 [ 337097 ]
            swinbank John Swinbank made changes -
            Sprint AP F19-2 [ 940 ]
            Parejkoj John Parejko made changes -
            Status To Do [ 10001 ] In Progress [ 3 ]
            tjenness Tim Jenness made changes -
            Link This issue relates to DM-20842 [ DM-20842 ]
            tjenness Tim Jenness made changes -
            Link This issue blocks DM-16297 [ DM-16297 ]
            Parejkoj John Parejko made changes -
            Reviewers Jim Bosch, Tim Jenness [ jbosch, tjenness ]
            Status In Progress [ 3 ] In Review [ 10004 ]
            Parejkoj John Parejko made changes -
            Link This issue is triggering DM-20994 [ DM-20994 ]
            jbosch Jim Bosch made changes -
            Status In Review [ 10004 ] Reviewed [ 10101 ]
            Parejkoj John Parejko made changes -
            Link This issue is triggering DM-21016 [ DM-21016 ]
            Parejkoj John Parejko made changes -
            Resolution Done [ 10000 ]
            Status Reviewed [ 10101 ] Done [ 10002 ]
            swinbank John Swinbank made changes -
            Story Points 8 12
            Parejkoj John Parejko made changes -
            Link This issue is triggering DM-22708 [ DM-22708 ]

              People

              • Assignee:
                Parejkoj John Parejko
                Reporter:
                jbosch Jim Bosch
                Reviewers:
                Jim Bosch, Tim Jenness
                Watchers:
                Eli Rykoff, Jim Bosch, John Parejko, John Swinbank, Tim Jenness
              • Votes:
                0 Vote for this issue
                Watchers:
                5 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Summary Panel