Hi Jane,

On Jan 13, 2009, at 1:22 AM, Jane Buckle wrote:

> I'm trying to reduce a series of 9 files that should all go into a  
> single group using oracdr_acsis. In -batch mode, the groups are pre- 
> defined, and the software decided on the following four groups, for  
> reasons that I am not clear about:
>
> Storing: a20071123_00051_01_0001.sdf
> A new group 20071123#51#1 has been created
> Storing: a20071123_00052_01_0001.sdf
> A new group 20071123#52#1 has been created
> Storing: a20071123_00055_01_0001.sdf
> This observation is part of group 20071123#51#1
> Storing: a20071123_00056_01_0001.sdf
> This observation is part of group 20071123#51#1
> Storing: a20081007_00048_01_0001.sdf
> A new group 20081007#48#1 has been created
> Storing: a20081007_00050_01_0001.sdf
> This observation is part of group 20081007#48#1
> Storing: a20081007_00054_01_0001.sdf
> A new group 20081007#54#1 has been created
> Storing: a20081008_00081_01_0001.sdf
> This observation is part of group 20081007#48#1
> REDUCING: a20071123_00051_01_0001.sdf
>
> I realise that changes to OT software, for example, may force  
> observations from different nights into different groups, but I  
> think that all of the observations from 20071123 should go into the  
> same group - I have checked that they are all the same source/line.

You're correct in that the four observations from 20071123 should all  
end up in the same group. With the subversion version of ORAC-DR, they  
do. Are you using this version? Installation directions are on the GBS  
wiki.

Also, observations 48 and 50 from 20081007 and observation 81 from  
20081008 should end up in the same group as well, given they have the  
same reference position as those from 20071123, but because of a  
change in the SAM_MODE header (it was changed from 'raster' to 'scan')  
these wouldn't end up in the same group. I've made a change to ACSIS's  
grouping algorithm to take this into account, so the subversion  
version will now group these three in with those from 20071123.

Observation 54 from 20081007 ends up in its own group because it has a  
difference reference RA/Dec. You can see this by doing 'ndftrace  
a20081007_00050_01_0001 fullframe' and 'ndftrace  
a20081007_00054_01_0001 fullframe'. For observation 50 the reference  
Declination is -1:54:27, whereas for observation 54 it's -1:54:10.  
This change in the reference position means they get split up into  
separate groups -- the reference position has to be the same to within  
an arcsecond. I can adjust this "slop" though, if necessary.

> However, there is then a further problem, on the second observation  
> - which is reduced after all of the observations from group 51 are  
> reduced:
>
> REDUCING: a20071123_00052_01_0001.sdf
> Using recipe REDUCE_SCIENCE_NARROWLINE_ADV specified on command-line
> Observing Mode: HARP /  /
>
> Sorting time-series data in time order...
> a20071123_00052_01_0001 to a20071123_00052_01_ts001:
> Sorted time slices in increasing time.
> a20081007_00052_01_0001 to a20081007_00052_01_ts002:
> Sorted time slices in increasing time.
>
>
> Creating cube.
> #52 Err: Observation type not defined for _GET_MAKECUBE_PARAMS_.  
> Programm
> ing error.#52 Err: Observation type not defined for  
> _GET_MAKECUBE_PARAMS_
> . Programming error. at /star/bin/oracdr/lib/perl5/ORAC/Print.pm  
> line 765.

If you take a look at the files that are reportedly in the same  
observation as a20071123_00052_01_0001, you'll see that one from  
20081007 is in there, which is clearly wrong. I have fixed this since  
the lehuakona release (submitted to subversion four days ago) so if  
you get the subversion version this will be fixed.

Cheers,
  Brad.