'ra' and 'dec' in 'src' catalogs resulted by 'obs_decam+processCcd+DECam data+ps1_pv3 ref' are inaccurate

Support
#1

I’m working on running processCcd.py on ISR removed DECam data under the ‘setup obs_decam’ using PanSTARRS reference catalog for astrometry and photometry.

To do that,

  1. used Docker container ‘lsstsqre/centos:7-stack-lsst_distrib-v20_0_0’
  2. ‘setup obs_decam’,
  3. retargeted ISR following 6th item on https://github.com/lsst/obs_decam
  4. I put ‘dqmask’, ‘instcal’, and ‘wtmap’ files under three directories each,
  5. ingested by running ‘ingestImagesDecam.py DATA --filetype instcal --mode=link r/instcal/*.fits.fz’
  6. downloaded PanSTARRS1 catalog fits files that cover our data, ‘config.py’, and ‘master_schema.fits’ from http://tigress-web.princeton.edu/~HSC/refcats/ps1_pv3_3pi_20170110/, and saved in ‘DATA/ref_cats/ps1_pv3_3pi_20170110/’

But the ‘ra’ and ‘dec’ in ‘src’, ‘forcedSrc’ neither the Butler-read ‘deepCoadd_forced_src’ was right (e.g., original data centered at ra=359, dec= -11, but resulted ra=6.2, dec=-0.18).

I checked with the data from ‘https://github.com/lsst/testdata_decam/tree/master/cpData’ and found a similar result.

Any comments? Thank you for reading!

#2

I believe (ra, dec) in the src catalogues are reported in radians. If you convert the 6.2 and -0.18 into degrees (from radians) you get values close to 359 and -11 (not exactly, however - most likely as you’ve reported the radians to 1dp).

1 Like
#3

Specifically, those fields are stored as lsst.geom.Angle. How are you reading the output catalogs? They are lsst.afw.table.SourceCatalogs, which has a readFits method to correctly interpret all of the field types.

EDIT: Expanding on this: you generally shouldn’t need to read the files themselves at all, since butler.get('src', dataId) will give you the data you need in the correct format.

#4

I think jrmullaney solved my question.

And parejkoj, yes, I was trying to read ‘src~.fits, forcedSrc~.fits’ files themselves which now I realize I should not.

(ra, dec) was same when I read via butler.get('src', dataId), but rSources.getSchema().find('coord_ra').field.getUnits() gave me a blank.

Now, I’m struggling with another problem that is occurring when I try to instantiate an object Butler on a Mac (it seems like the issue is about dylib or failing to make a directory /home/lsst), which is different from Docker environment that I have been using on.

#5

I’m not sure I fully understand your latest problem, but it sounds like you may be running into a permissions problem. This can be a problem when a user has a different ID when logged into a Docker container vs. when not. Could that be the case?

If you’re still encountering this problem, could you upload the code you’re trying to execute and the subsequent error message in full?