Hi Andy,
I think Tim is right that the behaviour you are seeing
is what is intended. I suppose there could be a case for an option
that completely eradicates all memory of the third axis from the NDF,
but at the moment that's not what happens - instead, as you've seen,
the original 3D Frame is retained in case it is needed again, and a
new 2D Frame is added and made current.
However, I think Tim may be wrong about the TRIM=FALSE TRIMWCS=TRUE
issue. If TRIM is FALSE, then TRIMWCS is not used - in effect a value
of FALSE is always used for TRIMWCS if TRIM is FALSE. So I think you
must be loosing the WCS axis somewhere else.
Looking at the history from "broken.sdf" I see that at step 12)
NDFCOPY TRIM=TRUE TRIMWCS=TRUE is used, thus removing the 3rd axis
(both pixel and wcs). But then at step 14)
setbound gs20120627_6_850_foc1(,,1:1)
is used, thus re-introducing a 3rd pixel axis, but no 3rd wcs axis.
David
On 28 June 2012 06:19, Tim Jenness <[log in to unmask]> wrote:
> On Wed, Jun 27, 2012 at 4:49 PM, Andy Gibb <[log in to unmask]> wrote:
>> On Wed, 27 Jun 2012, Tim Jenness wrote:
>>
>>> What command are you running?
>>>
>>> If I do
>>>
>>> ndfcopy ~/Downloads/s2map.sdf blah trim trimwcs
>>>
>>> then blah.sdf is 2d PIXEL and WCS.
>>>
>>
>> Right - but the file now has 6 Frames (s2map.sdf has 5), and the 5th
>> (which is the same type as the original 3-d Frame, SKY-SPECTRUM in
>> this case) is 3-d. I'm wondering if it's this leftover Frame that is
>> causing the problem.
>>
>> If you do:
>>
>> % wcsframe blah 5
>> % ndftrace blah
>>
>> it'll show you a 3-d Frame. Any other number shows a 2-d Frame.
>>
>
> Your example file is fundamentally different to the broken file that
> the pipeline was generating for me yeserday. ndfcopy does create a 6th
> frame when it trims the WCS and that's perfectly fine because it makes
> it the current WCS frame (I think David implements the trim as an
> additional mapping that loses the 3rd dimension).
>
> The broken file from yesterday has 2d WCS but 3d pixel coordinates.
> The example file in this report has 2d pixel and 2d WCS.
>
> Looking at the history of the broken file I see this:
>
> 20: 2012 Jun 27 05:58:10.210 - NDFCOPY (KAPPA 1.13-7)
>
> Parameters: COMP='DATA' EXTEN=FALSE
> IN=@/export/data/visitors/timj/oracdr/oractemplmXLQ5(0~30,0~30,)
> LIKE=! OUT=@/export/data/visitors/timj/oracdr/oractempUOnML3 TITLE=!
> TRIM=FALSE TRIMBAD=FALSE TRIMWCS=TRUE MSG_FILTER=! QUIET=!
> Software: /stardev/bin/kappa/ndfpack_mon
>
> which is exactly what I was expecting to be the problem. TRIM=FALSE
> TRIMWCS=TRUE. What I haven't worked out though is what primitive was
> doing that (woe is me for us not enabling the pipeline feature of
> writing messages to the history). There are multiple entries in the
> history where we do NOTRIM TRIMWCS.
>
> The bug is how the pipeline is calling NDFCOPY with TRIM=NO TRIMWCS=YES.
>
> --
> Tim Jenness
|
