Fix observation id naming for *FRINGE

[SharonGoliath]

Querying the observation ID GS-CAL20171119-8-001* shows that in this case the observation ID is set to GS-CAL20171119-8-001-RG-FRINGE for the unprocessed file and it is shown to be a ‘composite’.

It should be:

file id	observation id
rgS20171119S0123_fringe	GS-CAL20171119-8-001-RG-FRINGE
S20171119S0123	GS-CAL20171119-8-001

[dbohlender]

A query of Gemini's archive returns 115 processed fringe datasets. I think these are
missing in CAOM2 tables:

Data label	File ID
GN-CAL20110313-900-188	N20110313S0188_fringe.fits
GN-CAL20120203-900-281	N20120203S0281_fringe.fits
GS-CAL20060208-1-001-G-FRINGE	rgS20060208S0100_FRINGE.fits
GS-CAL20060208-2-001-G-FRINGE	rgS20060208S0107_FRINGE.fits
GS-CAL20061129-3-001-G-FRINGE	rgS20061129S0108_FRINGE.fits
GS-CAL20070913-2-001-RG-FRINGE	rgS20070913S0050_FRINGE.fits
GS-CAL20100713-2-001-RG-FRINGE	rgS20100713S0080_FRINGE.fits
GS-CAL20100715-1-001-G-FRINGE	rgS20100715S0038_FRINGE.fits
GS-CAL20101027-1-001-G-FRINGE	rgS20101027S0022_FRINGE.fits

[dbohlender]

The following are NOT processed fringe frames according to a Gemini archive query. Not sure if this provides a clue for incorrect product ID/observation ID combos. Likely not.

Observation ID	Product ID #1	Product ID #2
GS-CAL20030903-16-001	rgS20030903S0090_FRINGE	S20030903S0090
GS-CAL20070912-5-001	rgS20070912S0032_FRINGE	S20070912S0032
GS-CAL20100213-2-001	rgS20100213S0048_FRINGE	S20100213S0048
GS-CAL20171119-8-001-RG-FRINGE	S20171119S0123	rgS20171119S0123_fringe

For some reason a query of the Gemini archive using the last example's observation ID returns nothing but a search by the second file name prefix does.

I think these are all identified as composites but not all have members in CAOM2.

[dbohlender]

I've attached a file listing Gemini CAOM2 observations that are identified as composite observations but have no members. (The query used is at the top of the file.) The good news is that 9140 of more than 9500 of these are TReCS observations. I think these should NOT be composites. I believe processed TReCS files in Gemini's archive are derived by combining the NNODSETS x NSAVSETS contained within a single unprocessed image into a simpler image array.

Most TReCS files are being processed correctly except for the 'composite' algorithm. The exceptions might be those with data labels ending in -G. I may have only found examples with -R suffixes previously. The latter are correctly combined with the unprocessed observations (again, except for 'composite') whereas the -G versions show up as distinct observations.

There are 373 GMOS-N/S observations and a handful of hrwfs and michelle observations.

no_members.txt