Rose: all examples from COCIRS_5509

General data organization

The organization is nice. If you don't need to read GEO files, it's very straightforward to step through the data by reading files in parallel. If you need the GEO data, it's a little trickier, but manageable.

I checked a couple of the volumes to ensure that all the data rows had the right SCET values, but did not do this exhaustively on all volumes. (I presumed you had already done that.)

DATA directory

1. FP3 data files have non-FP3 detector numbers. E.g., on COCIRS_5509:

- APODSPEC/ISPM0509160800_FP3.TAB line 6 has detector 12

- POIDATA/POI0509160800_FP3.TAB line 6 has detector 12

- RINDATA/RIN0509160800_FP3.TAB line 6 has detector 12

- TARDATA/TAR0509160800_FP3.TAB line 6 has detector 12 (= FP4 pixel 2)

2. Different focal planes sometimes have different target sets. This may be correct (since the three focal planes have slightly different pointing), but I wanted to make sure. Sometimes it's just a target missing from one or more focal planes, but sometimes there is a completely different satellite, which may be correct but looks suspect. E.g., on COCIRS_5509 at 0509022120, we have:

- FP1 targets: 602, 611, 699

- FP3, FP4 targets: 602, 603, 699

(another example is at 0509160800)

3. Targets are not identified correctly via TARGET_NAME in label files. For example, on COCIRS_5509 at 0509022120:

- APODSPEC/ISPM0509022120_FP1.LBL, _FP3.LBL, and _FP4.LBL all show TETHYS as the only target in TARGET_NAME keyword. However, there are 3 targets according to GEO files.

- Corresponding POIDATA, RINDATA, and TARDATA files also show only TETHYS.

4. ISPM*.LBL: SAMPLING_PARAMETER_UNIT = "INVERSE CENTIMETER". Is this correct? It is different from the "CM^-1" which would be used in a unit expression. If "CM^-1" is legal here, it would be better to be consistent.

CALIB directory

5. All the calibration files are really table files rather than text files. They should be made more like tables via one of these two fixes:

a. change to a real PDS TABLE, remove the header lines and add column specifications to the label;

b. or, keep as text, but make the headers line up with the data. (There are extra spaces in the header line that cause the header labels not to line up with the data columns.)

CATALOG directory

All examples from COCIRS_5509.

6. CATINFO.TXT has a PUBLICATION_DATE that is prior to the publication date of the original publication date of COCIRS_0509 (2006-04-28 vs. 2006-07-01).

7. DATASET.CAT

- DATA_SET_TERSE_DESC: Should mention "Saturn" to help with full-text search and to make result rows more readable.

- ABSTRACT_DESC: Should mention "Saturn" to help with full-text search and to make result rows more readable.

- DATA_SET_TARGET descriptions: These are identical with original volumes. Do original volumes include satellites discovered during the observations for the volume? If not, need to augment them here.

- START_TIME doesn't match the value of the original volume (COCIRS_0509).

- line 533: "This dataset is composed of CIRS Time Sequential Data Records": TDSR is deemphasized elsewhere within this file (data set description, etc.). Are the reformatted tables also supposed to be called TDSRs, or does that imply Vanilla formatting?

DOCUMENT directory

8. Publication dates in the labels are sometimes less then the publication date in the corresponding file from the original CIRS volume.

- E.g., COCIRS_5509, CASSINI-RSP.LBL: COCIRS_0509=2006-06-08, COCIRS_5509=2006-03-08

9. CIRS_FOV_OVERVIEW.TXT: It appears that all \r\n newline sequences in the original file have been replaced with \n\n. I think this is wrong, since the PDS standard (I think) is to have \r\n. Secondly, the new file prints double-spaced.

10. DATASIS.TEXT: It appears that all \r\n newline sequences in the original file have been replaced with \n\n. I think this is wrong, since the PDS standard (I think) is to have \r\n. Secondly, the new file prints double-spaced.

11. DATASIS_OCR.PDF and .LBL: Perhaps merge this label information into DATASIS.LBL, as is done for the TEX and PDF files, to make more explicit the fact that this is a 3rd, alternate format.

CALIB directory

12. Publication dates in the labels are sometimes less then the publication date in the corresponding file from the original CIRS volume.

INDEX directory

13. Publication dates in the labels are sometimes less then the publication date in the corresponding file from the original CIRS volume.

14. It would be more convenient if the bandwidth and resolution were in the POIINDEX.TAB and RININDEX.TAB files, as well as the ISPMINDEX.TAB file. Reason: Since some ISPM files won't be in the RININDEX.TAB file (and perhaps not in the POIINDEX.TAB file either, since some ISPM files are just SKY or, perhaps, just rings), correlating the files is more complicated. As well, some indication of the mode might be nice, but a single character, as in the original CIRS volumes (A/C/E/O/P/B) would be better than the separate flag approach.

15. ISPMINDEX.TAB: It would be better to have a single mode flag (all/even/odd/pairs/centers/blinking), rather than the 6 separate flags.

16. The original volumes included tables of the CIRS requests and their times. This by itself is not that useful for the reformatted volumes, since the products are arranged around the CIRS requests. However, some other information from the science kernel might be appropriate, such as a table of CIRS request IDs and their description or science objective. (Or perhaps a scientist could tell me what would be appropriate. And as I mentioned, the info is in the science kernel, so a sophisticated user could get the info anyway by using INSPEKT or writing a SPICE program.)

Nixon =============================================================

A few comments:

1) REF.CAT: this is very far out of date. CIRS normally provides a file

now called CIRSREF.CAT which is (almost) current. I will work on

updating it.

2) My second comment was going to be about the file naming convention: I

was expecting that the re-formatted data, which adheres to Cassini

observation boundaries, would therefore use the request name as part of

the file name. However, I see that that the request name is included in

the .LBL file as "OBSERVATION_ID" and I understand that custom PDS

software is under development for browsing the CIRS dataset, so maybe it

doesn't matter so much.

3) The minute part of the file name does not exactly correspond to the

minute of the time of the first data item in the file. This is probably

known to the data producers judging by the reference to "approximate

minute" in the tutorial.txt file. Examples of such instances are

ISPM0505280401_FP3.TAB which starts at 04:02:04 and

ISPM05050311800_FP1.TAB which starts at 18:01:04. This is hardly a major

problem but I was curious as to why the difference exists.

Chanover ================================================================

Compliance with PDS standards:

I didn't find anything wrong here, although I am by no means an expert in the PDS standards so I defer to Lyle on this. The data volumes were structured as I expected, and with some familiarity with the STRUCTURE of PDS data sets, I had no trouble navigating through the volumes and finding what I need.

Scientific Merit of the Data:

Very high!! Yes, these are definitely the proper data to be archived, and yes, the reformatted data are MUCH easier to work with! I am not a Vanilla user - I tried it once and got very frustrated very quickly - so this is a welcome addition to the CIRS data archive. After reading over the documentation I was able to read in some data using IDL and make plots of spectra with very little trouble. I liked that you broke up a given observation by focal plane - this made it much easier to work with.

Usability of the Data:

Formats are appropriate. Data set is very complete. Documentation is comprehensive. I wonder about the utility of providing sample software for reading in the data? Or does that get too complicated because it is dependent on what sort of processor/platform the user has? I thought of this because in going through some of the Huygens data, I noticed that some of the instrument teams did provide software in a SOFTWARE directory, even when the data were provided in ASCII format. [They would say "we know it is not required to provide this software since the data are in ASCII format, but here it is anyway..."]

Comments on the documentation:

- In both the TUTORIAL.TXT and AAREADME.TXT files, in the section on file naming convention, you discuss the additional bbb suffix in the GEO data. You define bbb as "the NAIF body ID indicating which moon's position and viewing geometry is described by the file..." Since one of the options is 699 (Saturn), might it be better to replace the word "moon" with "target?"

- Calibration: is there a way of determining which calibration data were used to generate the "calibrated" spectra? You may have said this somewhere, but I don't remember where. As we all know, instrument calibrations change (improve?), and if someone is going to be accessing this calibrated data many years from now, it would be useful to know what "vintage" calibration files were used to reduce the data.

OK, that's it for now. I did find a misspelling in one of the CATALOG files, but I'll have to dig back and find it. It was "Rayleigh peack" instead of peak, but I don't remember which file it was in. I can tell you tomorrow during the telecon.

Huber ================================================================

A couple random PDS comments:

- As I noted to Mitch yesterday, there are some double quotes in DATASET.CAT

that should be single quotes.

- I really don't think FMT files should be used for INDEX TABLEs. You're

using a separate FMT for each index anyway so why bother?

- I'm not all that thrilled with the explicit FILE object labelling method.

Are you trying to be consistent with the original labels or is it just

because you wanted to have both ASCII and BINARY tables for everything?

If it's the second, then I could come up with a reasonable alternative

to using the FILE object but I'll raise that in a telecon.