Red arm reduction producing 1 file for every 4 observed

[gannonjs]

When reducing red arm data I am noticing that only every 4th file is getting all the way to the end of the pipeline. It seems to be because the pipeline gives files 4 at a time the same group ID in the .proc file. e.g., here is a column from my proc.

2023-09-15-1 | 2023-09-15-1 | 2023-09-15-1 | 2023-09-15-1 | 2023-09-15-1 | 2023-09-15-5 | 2023-09-15-5 | 2023-09-15-5 | 2023-09-15-5 | 2023-09-15-5 | 2023-09-15-8 | 2023-09-15-8 | 2023-09-15-8 | 2023-09-15-8 | 2023-09-15-8 |

You will note there are 5 entries for each 4 files. That is because one is the icubed final file while the others all finish at intf.

Is the pipeline stacking files 4 at a time or is this a bug?

Note: using the kcrm_merge branch of the pipeline

[scizen9]

The GROUPID is set when the data are taken, not by the DRP. Were these intended to be grouped like this? If not, you can set the object_min_nframes parameter in the kcwi.cfg file to 1. It used to default to 3, but it was recently changed back to 1 to avoid this kind of confusion.

[gannonjs]

No, they shouldn't be grouped like this. I have noticed that the grouped red files were all observed during the same blue exposure so I think this may be a bug somewhere when the files are first generated.

[scizen9]

I was able to reduce the files separately using the latest update of the kcrm_merge branch. The default was previously to group 3 object frames, but now the default is 1, so you should get a cube for each image.