Astrometric Matcher of Euclid Targets: Why so few matches? What criteria is used?

Support
#1

Hi,
After many months of failure, I’ve finally managed to use the LSST DM stack w_2021_04 release to process a simulated image frame of a set of Euclid targets produced by an ImSim-like Rubin simulator developed within the Euclid Consortium. These simulations are rather idealised, e.g. they do not include distortions. We would like to understand what criteria goes into the astrometric matching, e.g. S/N cuts, etc that could result in such a low number of matches.

processCcd.calibrate.astrometry INFO: Matched and fit WCS in 3 iterations; found 62 matches with scatter = 0.065 ± 0.049 arcsec

Here is an image produced by the debug.py code.

RubinSimExtAstrometryMatching-1
RubinSimExtAstrometryMatching-11860×1680 592 KB

#2

While the resolution of that image is awful, I did manage to observe that there are a lot of red (reference) sources, and most of the green (detections) have yellow (matches) counterparts. That means the matching is working, and the log line you posted agrees: 62 matches with a scatter of tens of mas indicates the solution is solid (as opposed to 4 matches with a scatter of 1 mas, or 20 matches with a scatter of 3 arcsec).

I don’t think there’s a need to worry about the large number of references that don’t have a match: the purpose of the astrometric solution performed in processCcd is to get close enough to be able to associate objects (~ hundreds of mas); downstream processing (in particular, jointcal) will refine the astrometric solution using deeper detections.

As for the particular criteria for the astrometric matching, you should check the configuration (in particular, config.calibrate.detection and config.calibrate.astrometry). E.g., for HSC I see:

# Minimum allowed signal-to-noise ratio for sources used for matching (in the flux specified by sourceFluxType); <= 0 for no limit
config.calibrate.astrometry.sourceSelector['matcher'].minSnr=40.0
config.calibrate.astrometry.sourceSelector.name='matcher'

# Threshold for footprints; exact meaning and units depend on thresholdType.
config.calibrate.detection.thresholdValue=5.0

# Include threshold relative to thresholdValue
config.calibrate.detection.includeThresholdMultiplier=1.0

# Apply magnitude limit?
config.calibrate.astrometry.referenceSelector.doMagLimit=False

# Apply signal-to-noise limit?
config.calibrate.astrometry.referenceSelector.doSignalToNoise=False
#3

Thanks for the prompt reply. I already confirmed that the matching was working. We were just curious to understand why the matches were so few. I will have a look at the configuration settings.

#4

Hey Jennifer, as Paul says that’s an uncommon number of matches to have. The green points you see in that image are sources in the image that were selected to be of high signal to noise (40 in this case of Paul’s example config) and suitable or the astrometric fitting. If you look above the line you show a bit you should see output that tells you how many sources the pipeline is using to try to match and fit.

#5

Hi Chris,
thanks for the reply, but do you mean it’s common to have that number? or did you really mean uncommon? In any case, we were just curious to understand why. I saw altering the minSNR setting changes the number of matches.

Another question I have regards ROTANGLE. It seems that if this value is not very precise, the astrometry matching fails. The only way I managed to get the astrometry to match and process my frame with a w_2021 release was to take a WCS from one of the DC2 ImSim runs and use that as the initial WCS for my image simulator (developed in Euclid) to render Rubin-like frames of Euclid targets.
I’ve come to realise that the Euclid simulator of Rubin exposures is too simplistic and lacks a level of realism required by more recent releases of LSST DM stack. For example, the WCS is the same for all visits (chosen by the previous developer). I am considering using the LSST DM tools and DESC ImSim modules within the Euclid development environment with singularity in order to produce a more appropriate WCS per visit and be more “Rubin-compliant”. If you have any comments or suggestions, they’re most welcome.

#6

Yeah, I meant “common” must have been trying to write it as “not uncommon”. The thing to keep in mind about the astrometry is that the algorithms all assume that the wcs solution is already close so if you’re expecting to solve for very large rotations or shifts that’s not the expected mode.

#7

I am talking about very small differences of ~0.5% to the rotation angle results in failed astrometry matching.