Closed acviana closed 11 years ago
I noticed this when looking at the header files:
--> imhead u2eu0101t_c0m_cr.fits[0] l+ | grep FILENAME
FILENAME= 'u2eu0101t_c0f.fits' / name of file
--> imhead u2eu0101t_c0m.fits[0] l+ | grep FILENAME
FILENAME= 'u2eu0101t_c0f.fits' / name of file
This is incorrect and the same in both the regular and cosmic ray rejected file. Since it's the same in the non-cosmic ray rejected files I don't think it's a result of my cosmic ray rejection script copying the headers into the cosmic ray rejected files. It's also the same in the directories I haven't processed yet. So, I wonder if the files came down that way.
This looks like a string parsing error to me where astrodrizzle expects the filename to be *_c0m.fits. I might be able to fix this by specifying the DQ file as an input parameter.
From Warren Hack:
This issue comes down to what mechanisms were used by the WFPC2 team to link DQ arrays with their science data. The only mechanism available (and used) was the naming convention which was not only used for DQ arrays, but also other calibrated products for a single exposure. With no other alternative, the drizzle code only had the naming convention to rely on to identify the DQ arrays for a given SCI array. No other datasets have separate SCI and DQ images, so there was even less need to try to find a astrodrizzle-specific solution to this problem, leaving only the naming convention to be followed with no manual alternative.
This will require a change in our file naming convention to correct.
Fixed in commit 74043b406ff8fe53ad531ceb531e345a840822dc
There is a warning showing up in the astrodrizzle outputs:
I need to figure out how the
/Users/viana/mtpipeline/archive/05221_neptune/u2eu0101t_c0_c1r.fits
filename is being generated. This seems to only be an issue for the CR rejected files, so it might be the something to do with the filename.