Jointcal using DECam data

Support
,
#1

I am running jointcal on a set of DECam images processed by the community pipeline in the VR filter using gaia dr2 for my reference catalog. I am testing on a single tract to see how the performance improves when using jointcal. The observing strategy is to take many exposures in the same position and then shift the pointing by almost the whole focal plane for another set of exposures. There are five different pointings with a total of ~70 exposures that overlap the tract I am testing. Here is a plot of the object density:

image
image2568×2452 441 KB
.

When I run jointcal on this data it seems to perform worse astrometrically than without jointcal. I used the chi2 initia/final files to compute residuals and here are x and y residuals for over the dataset.

image
image1168×894 20.8 KB

image
image1166×892 18.4 KB

Here is an example of the residuals of a single exposure with the original solution on the left and the jointcal results on the right:

image
image3178×1590 1.01 MB

You can clearly see how the residuals are worse after running jointcal.

My question is what are the best parameters I can fiddle with to get improved performance. I tried to change the fitting order and that didn’t improve the residuals. I’d appreciate any advice or recommendations.

#2

Can you please post your jointcal config? What pipeline version are you running, and can you please also post the jointcal log? Just INFO level is fine.

This is certainly not a case where jointcal would shine, as there is almost no sensor/sensor or cross-focal plane information available. But I wouldn’t expect it to do so clearly worse.

Because of the lack of significant overlap, you could try running with astrometryModel="simple" and astrometrySimpleOrder=5 (play around with that, though: default is 3, but I don’t have a sense for an ideal number here). That model is the equivalent of doing the regular AstrometryTask but using all the measurements: one model per sensor, no focalplane term.

What is the “VR” filter?

#3

I initially was using an older v18 version of the stack to do the processing, but then upgraded to w_2020_28 for the most recent set of processing. Both versions seemed to give similar results. I think I used almost the default settings for the configuration. I am attaching the log and config files that I used.

I will try the specific config changes you recommend and see if that makes a difference.

Here is a link to some information on the VR filter: www.ctio.noao.edu/noao/node/7470
log.jointcal (2.9 MB) jointcal_config.py (16.9 KB)

#4

Thank you for posting those: the log implies that the final jointcal fit had a reasonable reduced chi2 value, but that may be because there were very few stars being fit at the end. I think one problem is that there were many stars with zero or one catalog cross-matches or reference stars.

Instead of object density, do you have a plot of number of observations per field?

My guess is this is just not a situation that the current jointcal constrained model can do well with, without a better depth-matched reference catalog to provide more matched refstars. I suspect you should have better luck with the simple model, but that will likely still have failed sensors if there are fields with a single observation and no good refstars on some sensors.

This is similar to the situation described in DM-6354, though that case was more drastic. I could explore completely removing visit+sensor combinations that have fewer than X matched stars during the course of the fit, but that could cause the model to become singular without some care.

#5

Here is a plot with the number of observations on the sky where I have just approximated each exposure with a circle.

image
image1506×1150 37 KB

Here is a plot with the number of matches per object from the reference stars and measured stars:

image
image3180×1564 134 KB

It does seem like there are a good number of matches, but there are some reference sources with only a few matches.

I tried using the simple model and that failed. I’m attaching the log.log.jointcal.simple (1008.0 KB)

#6

Sorry, getting back to this finally. Your simple model definitely has something wrong with it, as I see this in the log during initialization:

CHOLMOD warning: not positive definite
jointcal.AstrometryFit ERROR: minimize: factorization failed

In addition there are several errors about having to reduce the polynomial order due to having too few sources on some sensors while the model is being constructed. You could try again, rejecting those sensor+visit combinations (see the log you posted for warnings about has only X stars for which ones to not include.

In general, you can usually start seeing the most useful jointcal fitter information beginning at this log marker:

=== Starting astrometric fitting
#7

Hi @rearmstr, I was just checking on unresolved Support posts and wondered if @parejkoj’s suggestions for modifications to the jointcal model worked for you, or if this application of jointcal remains an issue?