SMURF responsivity images no longer have FPLANE coordinate frame

[aggibb]

/stardev in Hilo is at 3204cbba and produces responsivity files with no FPLANE coordinate frame. Unfortunately this breaks the pipeline (which mosaics them in FPLANE coordinates). Here are the command line arguments used by the pipeline (with suitable dummy names):

% calcflat in=^inlist method=polynomial order=1 resist=^$STARLINK_DIR/share/smurf/resist.cfg \
    respmask=true snrmin=3 resp=resp1 out=flat1

The output responsivity images has only 4 coordinate frames (grid, pixel, axis and fraction) where it should also have BOLO and FPLANE.

The bug was introduced after daf2bb2e, as /stardev at the JCMT works fine.

[timj]

Well, if you hadn't told me it worked after this commit I would have put money on the breakage being introduced with 8a7d69845fe404e4586a36227d5889d70910d6c2 from July.

[dsberry]

On 17 September 2014 01:46, Tim Jenness notifications@github.com wrote:

Well, if you hadn't told me it worked after this commit I would have put money on the breakage being introduced with 8a7d698 https://github.com/Starlink/starlink/commit/8a7d69845fe404e4586a36227d5889d70910d6c2 from July.

Yes indeed. When I try running calcflat, I find that refdata->hdr->tswcs is NULL at line 197 of smf_create_bolfile.c. This is because no time-series WCS is stored in the output smfData created by smf_flat_mergedata. May be 8a7d698 should be changed to use the old scheme if refdata->hdr->tswcs is NULL or contains no FPLANE frame ???

David

— Reply to this email directly or view it on GitHub https://github.com/Starlink/starlink/issues/40#issuecomment-55834829.

[timj]

I'd prefer it if WCS flowed through the system properly rather than being magically created at the last moment. The problem is that we need to isolate SCUBA-2-specific calls if we hope to use SMURF to reduce data from other instruments. Do the heat frames in smf_flat_mergedata have WCS?

[dsberry]

No they don't. Looking into this some more, the smfData returned by smf_flat_fastflat no longer has time as it's third axis, and so its tswcs frameset is left NULL. I think this is where it comes from. Maybe we could change smf_flat_fastflat so that the output smfData has a non-NULL tswcs which retains the spatial axes on the input, and adds a third axis representing heater value. The use of the variable name "tswcs" - which I presume means "time series WCS" - is then a bit wrong, since it's being used to describe something other than a time series.

[timj]

Presumably we could do what we do when reading a 2D image in that we put the 2D frameset in the wcs slot and leave tswcs NULL (also istseries=0). Then we just look for wcs in preference to tswcs. Would that work?

[dsberry]

Hum - that would then break the expectation that "wcs" is a 2-D FrameSet. In fact, what I've done is to use "tswcs", on the basis that there is a precedent for this in the use of "tswcs" to describe the spectral axis of an FFT. Commit 9750b85d7 seesm to fix this issue.

[aggibb]

Thanks David - it does indeed look like it's fixed as I'm looking at some FPLANE mosaics from the pipeline right now.