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

Make ANetAstrometryTask more configurable

    Details

    • Type: Improvement
    • Status: Done
    • Resolution: Done
    • Fix Version/s: None
    • Component/s: meas_astrom
    • Labels:
      None

      Description

      The current ANetAstrometryTask has a solver that is not easy to retarget. This makes testing with hscAstrom needlessly difficult. My suggestion is to make the solver a true Task instead of a task-like object, and make it retargetable using a ConfigurableField instead of a ConfigField. This is very easy to do because the solver is already a task in all but name.

        Attachments

          Issue Links

            Activity

            Hide
            rowen Russell Owen added a comment -

            All work is in meas_astrom on tickets/DM-2740. In addition to making ANetAstrometryTask's solver a subtask, but also added a plotter for matches and made a few other minor cleanups.

            Show
            rowen Russell Owen added a comment - All work is in meas_astrom on tickets/ DM-2740 . In addition to making ANetAstrometryTask's solver a subtask, but also added a plotter for matches and made a few other minor cleanups.
            Hide
            boutigny Dominique Boutigny added a comment -
            • Making the solver a subtask is a very good thing.
            • I don't know if it is compatible with the unit tests' design policy but it would be good to be able to pass the "doPlot" as an option when running the test on the command line.
            • In astrometry.py::_matchAndFitWCS in the if block displaying the "TAN-SIP WCS" match : https://github.com/lsst/meas_astrom/blob/tickets/DM-2740/python/lsst/meas/astrom/astrometry.py#L298 it would be better to plot the goodSources instead of the sources, in this way, one could see which sources have been rejected.
            Show
            boutigny Dominique Boutigny added a comment - Making the solver a subtask is a very good thing. I don't know if it is compatible with the unit tests' design policy but it would be good to be able to pass the "doPlot" as an option when running the test on the command line. In astrometry.py::_matchAndFitWCS in the if block displaying the "TAN-SIP WCS" match : https://github.com/lsst/meas_astrom/blob/tickets/DM-2740/python/lsst/meas/astrom/astrometry.py#L298 it would be better to plot the goodSources instead of the sources, in this way, one could see which sources have been rejected.
            Hide
            rowen Russell Owen added a comment -

            I like your suggestion to display good sources instead of all sources in _matchAndFitWCS. I handled it slightly differently:

            • I renamed "clean" sources to "usable" sources, which I think is a clearer name. These may be saturated but they may also be used to by the matcher, so I think they are what should be plotted.
            • I return the usable sources from the matcher and plot them in _matchAndFitWCS

            Your suggestion of making "doPlot" a command-line argument to some tests is a good one, but I'm not ready to implement it yet. The problem is that I find I usually only want to display plots for a single test method (rather than all in a suite). Thus I don't think a simple boolean command-line argument would offer enough control. For now I'm happier forcing users to tweak the test before running it.

            Show
            rowen Russell Owen added a comment - I like your suggestion to display good sources instead of all sources in _matchAndFitWCS. I handled it slightly differently: I renamed "clean" sources to "usable" sources, which I think is a clearer name. These may be saturated but they may also be used to by the matcher, so I think they are what should be plotted. I return the usable sources from the matcher and plot them in _matchAndFitWCS Your suggestion of making "doPlot" a command-line argument to some tests is a good one, but I'm not ready to implement it yet. The problem is that I find I usually only want to display plots for a single test method (rather than all in a suite). Thus I don't think a simple boolean command-line argument would offer enough control. For now I'm happier forcing users to tweak the test before running it.

              People

              • Assignee:
                rowen Russell Owen
                Reporter:
                rowen Russell Owen
                Reviewers:
                Dominique Boutigny
                Watchers:
                Dominique Boutigny, Russell Owen, Simon Krughoff
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Summary Panel