Hiya,
I have been reducing some archival data from Subaru, and using gaia DR2 for astrometric calibrations. I noticed that the Gaia ref_cat is propagated to the mean epoch of the data I am using for jointcal, via the logs. However, this is not necessarily what I want to do, since the archive data can sometimes cover quite a range in date. I realised all this is controlled by the epoch keyword, but I cannot seem to find any way of setting the epoch (i.e. epoch=2000. or such) in my jointcal runs. Could somehow in the dev community point me in the right direction?
1 Like
There is no facility for specifying the epoch in jointcal. Why do you think the mean epoch would be incorrect for your data? All of the gaia matched stars will be shifted to that epoch in jointcal, so for every source that has a gaia PM, the fit will be self-consistent.
Note that Clare recently fixed a bug in our proper motion calculations that might affect you: DM-38808.
We’re also phasing out support for jointcal (replacing it with GBDES), so there’s very little effort available to work on it.
hmmm, ok. So, then what happens when I have let say two tracts side by side and one is mostly archive data from years ago and one is recent data? Sounds like those will then be put on quite different epochs.
Ideally I would like everything to be on the same epoch. Is there a way to turn the proper motion correction off, so everything is on native Gaia epoch?
Ah, I see: you want to have a consistent epoch across all Tracts. Now I understand the use case, and that does sound useful.
Turning off proper motion correct (not something we support) wouldn’t get you that: it would leave the sources with known Gaia PMs at incorrect locations in the input visits, and thus give a less accurate astrometry fit.
I’ve pushed a jointcal branch that should add this functionality for you, though I haven’t tested it. Get a local version of jointcal following these instructions, checkout branch u/parejkoj/epoch-override, and build it per those instructions.
Thanks! I will have a look at that change. Though it strikes me that the proper way of doing things would be to have jointcal do the proper motion correction, but have down stream functions such as coaddDriver accept an epoch to which the images should be warped. That way, the best of both worlds is preserved.
For that matter, this whole thing gets me thinking of how the stacking itself is working. Hard to find a lot of information on this. If I were to stack a new image and an old archive image from a few years back that both overlap the same sky tract, what happens? If we do jointcal with gaia coords shifted in epoch to each image, they are essentially shifted offset by a few years. Do these then just get stacked/swarped as is? In that case, the galaxies are lined up fine, but the stars are not, and the resulting stellar PSFs in the coadd are likely not great.
Hi @tdboer, just wanted to check if your initial question was addressed by @parejkoj’s post 9d ago and, if so, if you wouldn’t mind marking that as a solution.
I also wanted to ping @parejkoj to see if he has any thoughts @tdboer’s follow-up question.
Right, yes, good point. And indeed the answer does address my initial question. Marking the reply as the answer!
1 Like
Our image warping and stacking is based on the WCS of the image, which only indirectly depends on the PM/parallax epoch (in that fitting with PM corrections takes out some of the systematic error in the determination of the distortions for the WCS). We do not have any facility for warping individual stars based on their proper motions. This does mean that stars with significant proper motion will have bad PSFs in the coadds.
I’m not sure whether we have plans to do per-source PM/parallax corrections in the coadds; it’s a similar type of problem to DCR corrections in the coadds, where source positions are not actually the same even once images are warped. If we do have such plans, I suspect they are quite a ways off.