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

Potential development directions for the pessimisticMatcher.

    XMLWordPrintable

    Details

    • Type: Story
    • Status: Done
    • Resolution: Done
    • Fix Version/s: None
    • Component/s: meas_astrom
    • Labels:
      None
    • Story Points:
      2
    • Sprint:
      AP S22-1 (December)
    • Team:
      Alert Production
    • Urgent?:
      No

      Description

      Ticket summarizing suggestions to further improve the astrometric matcher.

        Attachments

          Activity

          Hide
          cmorrison Chris Morrison [X] (Inactive) added a comment - - edited

          Below are some suggestions on how to improve the match/fit cycle within matchPessimisticB beyond (and using) the significant speedup after the merge of DM-32299. I'll break this up into two sections: algorithmic and speed. To test any of these, one should use a large amount of difficult data to test for improvements in astrometric accuracy and speed of the algorithm. RC2 is a good test for speed and "normal" operation fitting. One should also test with ultra dense stellar fields for speed and % success of astrometric fitting.

          Algorithmic:

          • Instead of fitting the matrix outside of the main loop in _construct_pattern_and_shift_rot_matrix, fit the intermediate matrix within the C++ loop following what happens in the current python _intermediate_verify method in the python side of PessimisitcPatternMatcherB.
          • If you attempt any of these, do this one for sure! Now that the algorithm is much faster, one could decrease step size per matching attempt that max_dist takes. Currently this doubles after each attempt but could increase by say sqrt(2) instead. This is set currently by the value (2) in this link. Making this a configurable with a value <2 will make the algorithm more reliable at the cost of potentially more matching attempts. As the code is much faster for this step, the trade off will likely be worth it.
          • The match/fit cycle for the code currently takes three steps, with the wcs for the previous cycle being used in the next. The matching step can fail on the 2nd or third step likely meaning that the match was bad on the first one. At this point the Wcs should likely be reset to the original estimate from that came with the exposure. The MatchTolerance class/struct in matchPessimisticB could store the original wcs and when a failure is found and replace the current wcs with the original when starting over. This could be done at the same point the pattern that represented the failure is added to the skip list Fair warning though that this would require recalculating the locations of the the sources with the original WCS though that original array could also be stored in MatchTolerance at the cost of a bit of memory.
          • With the above, the AstrometryTask code checks for scatter against references to reject badly fit wcs's. This in principle could be done at every step of the matchFit cycle in AstrometryTask and used to reject bad fits before they are returned. This would be done by: Moving a similar test to here to within the matchFit loop. If the test fails, set the wcs to the original estimate in the exposure and then edit the match_tolerance object as follows: append the lastMatchedPattern to the failedPatternList and set lastMatchedPattern to None similar what is done here in the following line. That way a bad fit can be found early and subsequent attempts can be made to find a good one.

           

          That way, the matching will start from the beginning and won't look at the pattern that resulted in a bad fit potentially giving the code another chance at producing a good WCS.

          Speed:

          • There a few for loops in matchPessimisticB that strip the ra dec flux from the input catalogs that could be better vectorized. They were written at a time when afw catalogs were much more clunky.
          • The automated tolerance calculation likely takes up some time for larger catalogs. Basically, it's computing a bunch of test patterns to see how self similar they in a n-d space defined by the distances of their spokes. This likely takes up some time for larger catalogs (likely not too much as it's all in numpy for the most part). For those dense fields, the value of the match tolerance likely always ends up as the same value, the minimum allowed which is the pixel scale in arcseconds. Likely you could just set it to that for very dense fields (>1000 candidate sources). The easiest suggestion would be to plot the result of get_pair_pattern_statistics vs reference/source density and either make a lookup table for the tolerance given a pattern complexity and density or just set a hard cutoff for given density to set the tolerance to the pixel scale.
          Show
          cmorrison Chris Morrison [X] (Inactive) added a comment - - edited Below are some suggestions on how to improve the match/fit cycle within matchPessimisticB beyond (and using) the significant speedup after the merge of DM-32299 . I'll break this up into two sections: algorithmic and speed. To test any of these, one should use a large amount of difficult data to test for improvements in astrometric accuracy and speed of the algorithm. RC2 is a good test for speed and "normal" operation fitting. One should also test with ultra dense stellar fields for speed and % success of astrometric fitting. Algorithmic: Instead of fitting the matrix outside of the main loop in _construct_pattern_and_shift_rot_matrix, fit the intermediate matrix within the C++ loop following what happens in the current python _intermediate_verify method in the python side of PessimisitcPatternMatcherB. If you attempt any of these, do this one for sure! Now that the algorithm is much faster, one could decrease step size per matching attempt that max_dist takes. Currently this doubles after each attempt but could increase by say sqrt(2) instead. This is set currently by the value (2) in this link . Making this a configurable with a value <2 will make the algorithm more reliable at the cost of potentially more matching attempts. As the code is much faster for this step, the trade off will likely be worth it. The match/fit cycle for the code currently takes three steps, with the wcs for the previous cycle being used in the next. The matching step can fail on the 2nd or third step likely meaning that the match was bad on the first one. At this point the Wcs should likely be reset to the original estimate from that came with the exposure. The MatchTolerance class/struct in matchPessimisticB could store the original wcs and when a failure is found and replace the current wcs with the original when starting over. This could be done at the same point the pattern that represented the failure is added to the skip list Fair warning though that this would require recalculating the locations of the the sources with the original WCS though that original array could also be stored in MatchTolerance at the cost of a bit of memory. With the above, the AstrometryTask code checks for scatter against references to reject badly fit wcs's. This in principle could be done at every step of the matchFit cycle in AstrometryTask and used to reject bad fits before they are returned. This would be done by: Moving a similar test to here to within the matchFit loop. If the test fails, set the wcs to the original estimate in the exposure and then edit the match_tolerance object as follows: append the lastMatchedPattern to the failedPatternList and set lastMatchedPattern to None similar what is done here in the following line. That way a bad fit can be found early and subsequent attempts can be made to find a good one.   That way, the matching will start from the beginning and won't look at the pattern that resulted in a bad fit potentially giving the code another chance at producing a good WCS. Speed: There a few for loops in matchPessimisticB that strip the ra dec flux from the input catalogs that could be better vectorized. They were written at a time when afw catalogs were much more clunky. The automated tolerance calculation likely takes up some time for larger catalogs. Basically, it's computing a bunch of test patterns to see how self similar they in a n-d space defined by the distances of their spokes. This likely takes up some time for larger catalogs (likely not too much as it's all in numpy for the most part). For those dense fields, the value of the match tolerance likely always ends up as the same value, the minimum allowed which is the pixel scale in arcseconds. Likely you could just set it to that for very dense fields (>1000 candidate sources). The easiest suggestion would be to plot the result of  get_pair_pattern_statistics vs reference/source density and either make a lookup table for the tolerance given a pattern complexity and density or just set a hard cutoff for given density to set the tolerance to the pixel scale.
          Hide
          sullivan Ian Sullivan added a comment -

          Thank you for writing up this list! My one request would be for you to please clarify the final bullet point of the suggested algorithmic changes:

          With the above, the AstrometryTask code checks for scatter against references to reject badly fit wcs's. This in principle could be done at every step of the matchFit cycle in AstrometryTask and used to reject bad fits before they are returned. This would be done by: resetting the wcs to the original, and adding the duplicating the skip list code in matchPessimisticB including this code

          match_tolerance.lastMatchedPattern = None

          I don't quite follow your instructions under "This would be done by:". Could you please clarify and expand this description?

          Show
          sullivan Ian Sullivan added a comment - Thank you for writing up this list! My one request would be for you to please clarify the final bullet point of the suggested algorithmic changes: With the above, the AstrometryTask code checks for scatter against references to reject badly fit wcs's. This in principle could be done at every step of the matchFit cycle in AstrometryTask and used to reject bad fits before they are returned. This would be done by: resetting the wcs to the original, and adding the duplicating the skip list code in matchPessimisticB including this code match_tolerance.lastMatchedPattern = None I don't quite follow your instructions under "This would be done by:". Could you please clarify and expand this description?
          Hide
          cmorrison Chris Morrison [X] (Inactive) added a comment -

          Done. Does that help clarify things?

          Show
          cmorrison Chris Morrison [X] (Inactive) added a comment - Done. Does that help clarify things?

            People

            Assignee:
            cmorrison Chris Morrison [X] (Inactive)
            Reporter:
            cmorrison Chris Morrison [X] (Inactive)
            Reviewers:
            Ian Sullivan
            Watchers:
            Chris Morrison [X] (Inactive), Eric Bellm, Ian Sullivan
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved:

                Jenkins Builds

                No builds found.