#907 closed enhancement (fixed)
addstar on psphot output from stacked SDSS image complains about missing JD
| Reported by: | Owned by: | eugene | |
|---|---|---|---|
| Priority: | high | Milestone: | |
| Component: | ippconfig | Version: | 2.2 |
| Severity: | minor | Keywords: | |
| Cc: |
Description
(ipp001:stripe82/coadd/run_ipp) jester% addstar -D CAMERA _SDSS-SKYCELL photstack-run1.cmf
ERROR: missing JD Keyword
This is in /data/ipp001/jester/stripe82/coadd/run_ipp
Don't know if the bug is in psphot, addstar, SDSS image headers, or my config file setup. addstar worked on the psphot output from an individual SDSS image.
Change History (3)
comment:1 by , 19 years ago
| Component: | psphot → ippconfig |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
comment:2 by , 19 years ago
So I did that, both for FPA.TIME and FPA.CELL, and now addstar complains about TAIHMS:
(ipp001:stripe82/coadd/run_ipp) jester% addstar -D CAMERA sdss photstack-run1.cmf
ERROR: missing UT Keyword TAIHMS
Is it even meaningful to specify a date and time for a stacked image? I mean, there's an upper and lower bound to when photons arrived that made it into the stacked image, but there's no single time that would capture that information.
Maybe this is relevant?
pswarp -file ../input/fpC-001755-i1-0330.fit psWarp-001755-i1-0330 skycell_0484667_warptemplate.fits
Camera SDSS, format SDSS matches header.
Camera SIMPLE, format SIMPLE also matches header --- ignored.
using header astrometry
no mask supplied
no weight supplied
Camera SIMPLE, format SIMPLE matches header.
Unable to find header DATE-OBS --- assuming value is NULL
Unable to find header UTC-OBS --- assuming value is NULL
Unable to parse concept FPA.TIME, but concept not marked as required.
comment:3 by , 19 years ago
Some background:
- The Pan-STARRS IPP uses two (fairly) independent software packages: IPP and Ohana. These two packages have different configurations.
- The IPP was configured to write skycells with all the "concepts" as HIERARCH header keywords. Ohana can't read HIERARCH keywords.
- The format of skycell FITS files is very different from those of detector FITS files --- the skycells have the HIERARCH keywords (e.g., "HIERARCH FPA.AIRMASS = 1.234"), while the detectors have the usual FITS keywords (e.g., "AIRMASS = 1.234"). This means that you can't say "addstar -D CAMERA camera skycell.smf" because it's looking for the detector header keywords for that camera.
To work around this annoyance, I've added an extra section to the site configuration (.ipprc file) that specifies header keywords for skycells that are to be treated separately.
# Header keywords for skycell concepts; required because DVO doesn't read HIERARCH
SKYCELLS METADATA
FPA.TIME STR MJD-OBS
CELL.TIME STR MJD-OBS
FPA.EXPOSURE STR EXPTIME
CELL.EXPOSURE STR EXPTIME
FPA.AIRMASS STR AIRMASS
END
I've changed psModules to respect these for all skycells (all skycells have pretty much the same format, regardless of the source camera).
I've added an extra directory to ippconfig with DVO configuration data for skycells.
The result is that, after reproducing your skycell image/photometry files, you should be able to do:
addstar -D CAMERA skycell myPhotometry.cmf
Note that it's using a "skycell" camera, not the "sdss" or "megacam" camera.
Fixed in CVS head for psModules and ippconfig.

Firstly, you've got the wrong camera (at least so far as addstar is concerned; remember, DVO doesn't share the usual IPP camera configurations). DVO should know your camera by "sdss" (or whatever is the *directory name* under ippconfig).
However, this (along with your other e-mail about the photcode) pointed out to me that I hadn't updated the concepts for the output from the stack. I've put this into the source code for psModules and ppStack. Note that you're specifying the time wrong (where did this "Number of seconds since Nov 17 1858" system come from???); it should be something like:
TRANSLATION METADATA
END
FORMATS METADATA
END
Now, there may be a problem with addstar digging the date and time out of the HIERARCH formats....