Adding VISTA near-IR bands to Monster

Support
#1

Hi all,

I’m working on the LSST–VISTA fusion pipeline (using LSST Science Pipelines via the obs_vista package to combine LSST and VISTA data). As part of this, I’m building a LSST–VISTA calibration refcat. For VIRCAM Z/Y I’m following a Monster-style calibration approach (fits/splines between bandpasses), and for J/H/K I’m attaching VISTA photometry to Monster via crossmatch to build a combined Monster–VISTA refcat (keeping Monster coordinates).

The issue is cross-matching robustness in dense fields when the external VISTA catalogue positions are not at the same epoch as Monster. In my DP1 test case (VIDEO CDFS), I attempted a PM-aware matching scheme: I propagated Monster positions from the Gaia reference epoch to the VISTA catalogue epoch using Monster proper motions, did an initial loose crossmatch to estimate and remove a bulk offset, then re-matched with a tighter radius enforcing unique 1–1 pairs. I then propagated the matched VISTA positions back to the Monster epoch as a consistency check. Despite this, a residual mismatch remains, so I’m concerned about incorrect associations (wrong VISTA flux attached to a Monster source) rather than a simple global shift.

I suspect this is a known class of problem — e.g. when Monster was constructed, many input surveys such as DES/DECam are not at exactly the Gaia DR3 epoch either — so I’d like to understand the recommended DM approach.

What is the DM-recommended approach / existing pipeline pattern for reliably matching Monster to an external catalogue with different/unclear epoch handling, especially in dense fields? Is there an existing LSST Task/workflow for ingesting external photometry into a Monster-like refcat that already handles these matching/epoch pitfalls?

Thanks in advance for your help.

1 Like
#2

The Monster refcat was designed for our internal use to get initial calibrations. The way we handled “bad matches” was just to remove them, since all we need the catalog for is getting an initial guess at the photometric and astrometric calibration, and even after removing outliers we typically have plenty of reference stars in the Monster. Your use case certainly sounds like a more difficult problem, and not one that we plan to concern ourselves with. Apologies that we don’t have more advice to offer you, but I think that the problem you’re facing is not something that we have addressed.

It may be worth asking this as more of a science question in other channels of the Community Forum (rather than in “Support”) – I’m guessing there are people in the broader community who have thoughts on this!

#3

Thanks for your answer. Just to make sure I’m not reinventing your outlier-rejection step: when building Monster, how did you define and remove “bad matches” in practice (e.g. mutual nearest-neighbour + separation cut, sigma-clipping on ΔRA*/ΔDec residuals after an initial fit, etc.)? Even a pointer to the relevant Task/config (if there is one) would be very useful.

#4

I agree with Jeff’s comment.
It looks like we ran the IsolatedStarAssociationTask to select gaia sources that had no other gaia sources within 1 arcsecond.
Then our matching only kept stars from the source refcat within 0.5 arcsec of a isolated gaia source
Look at the isolate_and_transform step of the monster creation.

#5

Thank you so much for your answer.