PDS/SBN New Horizons K4 peer review derived data set liens =============================================== NOTE: (1) For your reference or to clarify liens, all reviewer presentations can be found here: https://sbnreview.astro.umd.edu/202202_NH_KEM/notes-presentations OR linked into the agenda here: https://sbnreview.astro.umd.edu/202202_NH_KEM/agenda.shtml =============================================== Datasets Validated: NH-A-LEISA/MVIC-5-COMP-V1.0 NH-A-LORRI/MVIC-5-GEOPHYS-V1.0 NH-P/PSA-LORRI/ALICE/REX-5-ATMOS-V2.0 NH-X-ALICE-5-IPM-V1.0 NH-X-PEPSSI-4-PLASMA-V1.0 NH-X-SWAP-5-DERIVED-SOLARWIND-V2.0 =============================================== Errors for: GLOBAL (all datasets) Remember that when fixing mission-wide or instrument-wide catalog files to update the LABEL_REVISION_NOTE. file: 'catalog/mvic.cat' --> TH: typo (line 45) "Intgration" => "Integration" --> MC: Clean up the missing spaces and tabbing on lines 292-296. file: 'catalog/nh.cat' --> RF (swap typos): small typo on line 74 "unlit" => "sunlit" file: 'catalog/nh_kem.cat' --> RF (PEPSSI slide 30) The MISSION_STOP_DATE specifies "2021-09-30" and in the MISSION_DESC just a few lines later the sentence says "the end is TBD." Please make sure these values are correct, and if not correct them. Aug 2022? --> TF (LORRI/MVIC slide 5): Several references to Arrakoth call it MU69. Should be 2014 MU69. --> --> TB: See the MISSION_OBJECTIVES_SUMMARY for all remaining examples. file: 'catalog/ref.cat' --> Ensure that this file is up to date and matches the one found in the L2/3 data sets. files: 'data/*' --> SPACECRAFT_CLOCK_{START,STOP}_COUNT: In many instances these are listed as "UNK" when as NH put it "for a value when we know a start/stop time but don’t have a convenient way to translate it into a precise spacecraft time." In these cases we can mark them as "N/A" since the data is derived and not taken by the spacecraft. files: 'index/index.*' --> Column 5 PRODUCT_CREATION_TIME is wrong. They all say "2021-11-15" which was after when the data set was produced AND is not the same as the corresponding keyword value found in the PDS label for each product. --> In the label, the DESCRIPTION for Column 7 TARGET_NAME, has a minor typo. "identifies target" => "identifies the target" file: 'voldesc.cat' --> Note that PDS-SBN will need to update the PUBLICATION_DATE field for when the data sets are actually released to the public. =============================================== Errors unique to: NH-A-LEISA/MVIC-5-COMP-V1.0 Certification Status: CERTIFIED, with minor liens (assuming the data does not change during lien resolution). Note that Trent Hare (TH) is willing to help fix/address any of the data label issues that were discovered. file: 'aareadme.txt' --> CE: note that "Linear Etelon Imaging Spectral Arrray" is misspelled twice (lines 8-9,17-18). Note that "Etelon" => "Etalon" and "Arrray" => "Array". file: 'catalog/catinfo.txt' --> CE: The new name for the LEISA instrument is mentioned in this file (TB: twice I might add). But the old name is no longer mentioned (TB: unlike in the LEISA L2/3 versions of this file). It might be helpful to mention both names in the catinfo.txt document since the original acronym is used almost everywhere else in the documentation. file: 'catalog/dataset.cat' --> typos in DATA_SET_DESC needed to be forced to lowercase or uppercase: --> --> 'CA05_MVIC_cube.fit' --> --> 'LEISA_Charon_flat.fit' --> --> 'CA04_LEISA_cube.fit' file: 'catalog/leisa.cat' --> CE: I was not aware until looking through the documentation that LEISA was officially retitled to the Lisa Hardaway Infrared Mapping Spectrometer. This new name appears in the catinfo.txt document. The leisa.cat document does not mention this new name. --> --> TB: I would not change the INSTRUMENT_NAME (changing this keyword will have a very large cascading affect), but please please please document this new name prominently, and preferably towards the front of the document. --> CE: typo (line 243) "tranmitting" => "transmitting" file: 'data/ca04_leisa_cube.lbl' --> There are some values in this DESCRIPTION that are being obscured and should be found in geometry related PDS3 keywords. For instance PHASE_ANGLE, SC_TARGET_POSITION_VECTOR or TARGET_DISTANCE or TARGET_CENTER_DISTANCE or etc, and possibly SCALED_PIXEL_WIDTH + SCALED_PIXEL_HEIGHT. Please check the keyword definitions to determine if these keywords fit your values. May want to discuss at peer review. Example DESCRIPTION text: =================== This file is the highest spatial resolution LEISA observation, designated as CA04, which was executed on 2019 January 1 around 4:58 UTC, from a phase angle 12.6deg and mean range of 31,000 km, resulting in a mean image scale of 1.9 km per pixel =================== --> TH: In the DESCRIPTION of the IMAGE object, it says "The third axis (BAND) is image number and could also be thought of as time." Please explain this better. --> --> CE: I understood the statement and just understood it as a stack going from earlier to later in time. Maybe warrants a parenthetical explaining that. --> TH: There is no attempt to "mask" or define Nodata in the label (outside of the image). It would be nicer for the user to have this included. Suggest if possible please add this if it is applicable. --> --> TB: Before adding a mask, consider the issues/solution for the nh-a-lorri_mvic-5-geophys-v1.0/data/albedo/*.lbl images. --> TH: This file appears to be related to the ca04_leisa_wavelengths.lbl/tab files. If so, please add some DESCRIPTION text or the like to link the two files. --> TH: Is 64bit float point bit type really warranted here or would 32bit floating point be enough? --> --> TB: Note that if you change the data, it will need to be reviewed again. file: 'data/ca05_mvic_cube.lbl' --> There are some values in this DESCRIPTION that are being obscured and should be found in geometry related PDS3 keywords. For instance PHASE_ANGLE, SC_TARGET_POSITION_VECTOR or TARGET_DISTANCE or TARGET_CENTER_DISTANCE or etc, and possibly SCALED_PIXEL_WIDTH + SCALED_PIXEL_HEIGHT. Please check the keyword definitions to determine if these keywords fit your values. May want to discuss at peer review. Example DESCRIPTION text: =================== This file is the highest spatial resolution MVIC color observation of Arrokoth designated as CA05, which was obtained on 2019 January 1 at 5:14 UTC (coordinated universal time), from a mean range of 17,200 km, at an image scale of 340 meters per pixel, and phase angle 15.5deg." =================== --> TH: The IMAGE object's DESCRIPTION is much more terse (but okay). But please spell out the first occurrence of the PDU acronym, for the non-FITS users may not know this FITS terminology. See the LEISA cube for example. --> TH: There is no attempt to "mask" or define Nodata in the label (outside of the image). It would be nicer for the user to have this included. Suggest if possible please add this if it is applicable. --> --> TB: Before adding a mask, consider the issues/solution for the nh-a-lorri_mvic-5-geophys-v1.0/data/albedo/*.lbl images. --> TH: No keyword or comment in the label mapping the bands. Perhaps just listing: The color filters are identified as 'BLUE' (400-550 nm), 'RED' (540-700 nm), 'NIR' (780-975 nm) and 'CH4' (860-910 nm) --> --> TB: This can easily be resolved by adding the keyword BAND_NAME = ( band1, band2, band3, band4 ) to the IMAGE object. file: 'data/leisa_charon_flat.lbl' --> Since this product was created using 3 images (LSB_0299176809, LSB_0299172889 and LSB_0299172014 per prior DESCRIPTION text) and there are only 3 sources, strongly suggest adding the SOURCE_PRODUCT_ID keyword to link those products with this one. --> --> Ex: SOURCE_PRODUCT_ID = "[DS_ID]:[PRODUCT_ID]". For multiple instances, just enclose the values with {} delimiting with a comma. --> TH: There is no attempt to "mask" or define Nodata in the label (outside of the image). It would be nicer for the user to have this included. Suggest if possible please add this if it is applicable. --> --> TB: Before adding a mask, consider the issues/solution for the nh-a-lorri_mvic-5-geophys-v1.0/data/albedo/*.lbl images. file: 'document/docinfo.txt' --> TH: typo (line 103) "Latutide" => "Latitude" =============================================== Errors unique to: NH-A-LORRI/MVIC-5-GEOPHYS-V1.0 Certification Status: NOT CERTIFIED, delta review required. file: 'aareadme.txt' --> MC: Minor corrections in the Directory structure: =================== 38c38 < |--/CATALOG/ Directory containing PDS catalog objects. --- > +--/CATALOG/ Directory containing PDS catalog objects. 50,56c50,61 < | /ALBEDO/ < | +-- *.LBL Data product PDS labels < | +-- *.* Data product data files < | /SHAPE_MODELS/ < | +-- *.LBL Data product PDS labels < | +-- *.* Data product data files < | /TEMPERATURE/ --- > | +--/ALBEDO/ Albedo data directory > | | | > | | +-- *.LBL Data product PDS labels > | | +-- *.* Data product data files > | | > | +--/SHAPE_MODELS/ Shape models directory > | | | > | | +-- *.LBL Data product PDS labels > | | +-- *.* Data product data files > | | > | +--/TEMPERATURE/ Temperature data directory > | | =================== file: 'catalog/dataset.cat' --> MC: Suggest removing the parentheses on lines 160-161. --> TF: The Pole orientation and spin rate should be included somewhere in the data set for reference, and for orienting the shape model. (The SPICE kernels at NAIF only contain a pole orientation.) --> --> TB: This may be resolved with other documentation, but it is probably good to have brief details in this file as well. --> TF (slide 5): On lines 130-133, you should specify Noon on the given day to remove ambiguity. --> TF (slide 5): Regarding lines 236-243 which references the V4.0 L2/3 data sets, if version 4.0 of the datasets were used to produce the models and maps, then this should be noted as such. If this is pointing to the most recent calibration effort, as it says, then they should now be version 5.0. --> TF (slide 7): Regarding the Temperature maps, it is not clear to me what these tables represent. They don’t seem to agree with what is shown in the papers that are cited. file: 'data/albedo/*.lbl' --> TH: The label defines the NULL and SATURATION values, but they are not used. Is this correct? --> SBN: In the label, the values for FILE_RECORDS and RECORD_BYTES appear to be wrong - swapped, specifically. Each pixel is 4 bytes and the RECORD_BYTES is presumably intended to indicate the length of a single row of pixels, so it should 4096, and FILE_RECORDS should be 1024. --> SBN: The label defines a bit mask. Applying a bit mask to a real valued data item will produce implementation-dependent results that are unlikely to be what you expect, so it would be best to remove the bit mask from the label in this case. files: 'data/shape_models/*' --> TH: It would be great if OBJs had a texture applied. Could these be supplied? file: 'data/shape_models/asp_ca04_06_icp_smooth_spi.* --> MC/TF: This model is rotated -90 deg WRT the +X axis. The model should be aligned appropriately as the other models. See: cosmo_asp_ca04_06_icp_smooth_spi.png --> MC: It is suggested to include "mu69" in the file name: mu69_asp_ca04_06_icp_v01.* --> COLUMN 3 of the VERTEX_NORMAL_TABLE is missing it's UNIT keyword and value, unlike COLUMNs 2 & 4. Assuming it and the other columns should have it, please add. file: 'data/shape_models/mu69_fr2kf_lopoly.lbl' --> COLUMN 3 of the VERTEX_TABLE is missing it's UNIT keyword and value. file: 'data/shape_models/mu69_fr2kf_hipoly.lbl' --> COLUMN 3 of the VERTEX_NORMAL_TABLE is missing it's UNIT keyword and value, unlike COLUMNs 2 & 4. Assuming it and the other columns should have it, please add. files: 'data/shape_models/mu69_merged_browse.{lbl,png}' --> The PNG_DOCUMENT=>DESCRIPTION states uses the text "ASP-CA04-CA06-LORRI-ICP-smooth.obj" but it has been renamed. Feel free to use the PRODUCT_ID instead. file: 'data/shape_models/mu69_merged.{lbl,tab}' --> In the DESCRIPTION: The "ASP-CA04-CA06-LORRI-ICP-smooth.obj" file has been renamed. Please fix. Feel free to use the PRODUCT_ID instead. --> COLUMN 3 of the VERTEX_NORMAL_TABLE is missing it's UNIT keyword and value, unlike COLUMNs 2 & 4. Assuming it and the other columns should have it, please add. file: 'document/docinfo.txt' --> TH: typo (line 119) "Latutide" => "Latitude" file: 'document/nh_ralph_v100_ti.txt' --> TF (slide 6) It would be better to edit this down into its own document (not a SPICE kernel) and remove the unnecessary items, so the user doesn’t have to make decisions about what should be avoided. –-> TF (slide 6): Renaming it something like RALPH_FOV_INFO.TXT would also make it more obvious what information it is providing. REFERENCE_FRAME for SHAPE_MODELS (etc) (MC/NAIF) ------------------- We cannot find a MU69 coordinate system document that the project agreed upon with SBN. If yes, it would be good to look at it in the context of this review. If not, are there any plans to produce such document, and most important of all, will it define the frame consistent with frames used in the shape model data provided in this data set? The DSKs have been generated using the reference frame 'MU69_FIXED'. This reference frame is not defined anywhere in the current NH SPICE data set. Our understanding is that this frame looks like something like: \begindata FRAME_MU69_FIXED = 2486958 FRAME_2486958_NAME = 'MU69_FIXED' FRAME_2486958_CLASS = 2 FRAME_2486958_CLASS_ID = 2486958 FRAME_2486958_CENTER = 2486958 OBJECT_2486958_FRAME = 'MU69_FIXED' \begintext Note that from the SPICE Toolkit N67 onwards (released on Jan 3 2022), the IAU_ARROKOTH frame is provided with the toolkit and its orientation data is provided via PCK from nh_stars_kbo_centaur_v003.tpc provided in the NH SPICE data set. ------------------- Missing DSK Surface names for SHAPE MODELS (MC/NAIF) ------------------- The Arrokoth shape models are stored in the DSKs as surfaces"; as any other SPICE "body", surfaces have a name and an ID. These surface names must be defined during the generation of the DSK and by an auxiliary Frames Kernel (FK) that defines the surfaces. The surfaces can be added in the MKSDSK setup file as indicated in the MKDSK User Guide: NAIF_SURFACE_NAME += 'surface name' NAIF_SURFACE_CODE += integer surface ID code NAIF_SURFACE_BODY += integer body ID code These assignments are needed if the surface name-ID association is not defined in a kernel listed in a KERNELS_TO_LOAD assignment. The same text can be included in the auxiliary FK. This latter solution is preferred. The OSIRSI-ReX Frames Kernel defining the Surface IDs can be used as a template: https://naif.jpl.nasa.gov/pub/naif/pds/pds4/orex/orex_spice/spice_kernels/fk/orx_shape_v03.tf Surfaces names are used by SPICE APIs to use the shape models as inputs. This auxiliary FK (e.g.: nh_shape_v01.tf) should be present in the data set and must be present in the SPICE data set. We recommend that the names of the surfaces are provided by this data set as defined by their authors. Each shape model provided by each DSK consists of a single surface; each surface should have a unique NAIF_SURFACE_NAME. Using the DSK filenam as the surface name without the *.bds extension and using capital letters is good enough. ------------------- Missing orientation information for SHAPE MODELS (MC/NAIF) ------------------- In order to use the shape models, especially the SPICE DSK files, the orientation model of MU69 is required. In addition DSK files usually require extra files to be used. Within this data set the rotation model of MU69 is only present in the refernced article [SPENCERETAL2020]: "Arrokoth’s rotational period is 15.92 ± 0.02 hours, with its rotational pole pointing to right ascension = 317.5 +- 1deg, declination = −24.9 +- 1deg, J2000 equinox" This article is not easy to access (requires at least a user at NATURE.) The current orientation information available from the SPICE data set https://naif.jpl.nasa.gov/pub/naif/pds/data/nh-j_p_ss-spice-6-v1.0/nhsp_1000/data/pck/nh_stars_kbo_centaur_v003.tpc is: ASTEROID 486958 (2014 MU69); 2486958 \begindata NAIF_BODY_NAME += ( 'ASTEROID 486958 (2014 MU69)' ) NAIF_BODY_CODE += ( 2486958 ) NH_TARGET_BODIES += ( 2486958 ) BODY2486958_POLE_RA = ( 317.4880752 0. 0. ) BODY2486958_POLE_DEC = ( -24.8876496 0. 0. ) BODY2486958_PM = ( 270. 0. 0. ) BODY2486958_RADII = ( 100. 100. 100. ) \begintext The file is: This model does not include the 15.92 hours rotation specified in [SPENCERETAL2020], to include it the BODY2486958_PM value should be corrected as in: BODY2486958_PM = ( 270, 542.71, 0 ) The RADII should be corrected as well to fit the ellipsoidal approximation of MU69. But this file is not referenced in this data set. The recommendation is to either explicitly cite the SPICE kernel data set and indicate that the information will be available there, to include the updated/corrected PCK in the document collection in a similar manner to the included IKs: document/nh_ralph_v100_ti.txt document/nh_lorri_v201_ti.txt or to include this information elsewhere within the data set. ------------------- DSK comment area for SHAPE MODELS (MC/NAIF) ------------------- DSK binary files have a comment area accessible using NAIF's utility COMMNT. The comment area contains important information to understand the DSK file. We find that comment are included in the DSKs requires more work. Typically comment areas for DSKs have different sections: 1-Abstract 2-Objects 3-Pedigree 4-Related SPICE kernels 5-References 6-Contact Information 7-DSKBRIEF Summary 8-MKDSK Setup File and Run-time Traceback The current comments only contain section 8. An example of a complete DSK comment is attached: bennu_g_00880mm_alt_obj_0000n00000_v020.cmt The comment area should be extended to include all the sections mentioned above following the Bennu OSIRIS-ReX example. All the information required to fill the comment should be present elsewhere in the data set. We would like to emphasize that is very important to include in the comment area a complete list of all the kernels needed to use the shape model. This goes in section 4. A better example than the one for OSIRIS-ReX is provided hereunder: " Related SPICE kernels ------------------------------------------------------------------------ This file should be used together with the kernel set described below (*): Kernel Comments ------------------------------- ------------------------------------- nh_shape_v01.tf is a mission specific Frame Kernel that complements the mission's Frame Kernel to complete the DSK Surface ID Codes for the mission. nh_stars_kbo_centaur_v003.tpc is the Planetary Constants Kernel that provides the cartographic, physical constants data, and Name/ID mapping for bodies not covered by the project kernels (including Arrokoth.) nh_recon_arrokoth_od147_v01.bsp Contains ephemerides for the NH Spacecraft, the Pluto system bodies, and solar system bodies (including Arrokoth.) naif0012.tls is a Leapseconds Kernel file used in conversions between ephemeris time and UTC (coordinated universal time.) (*) or any higher version of the same kernels " Please note that the FK nh_shape_v01.tf does not yet exist so its generation should be considered, it is recommended to use the OSIRIS-ReX one as a template: https://naif.jpl.nasa.gov/pub/naif/pds/pds4/orex/orex_spice/spice_kernels/fk/orx_shape_v03.tf Note that as specified before, nh_stars_kbo_centaur_v003.tpc should be updated. In addition, either the 'MU69_FIXED' frame should be defined or the DSKs should be re-generated using 'IAU_ARROKOTH'. Since these prior items will have to be included in the SPICE data set please coordinate with Brian Enke (SWI). ------------------- PDS labels for DSK SHAPE MODELS (MC/NAIF) ------------------- * The DESCRIPTION field of the label is too poor, it is recommended to use the description provided in the catalog/dataset.cat following the style of the OSIRIS-ReX DSKs the description of which is as follows: SPICE DSK file containing shape model data for the surface of asteroid (101955) Bennu, with Global coverage at .880 meter resolution, ALT-based, version 020, created by the ORX Altimetry Working Group (AltWG). The original name of this file was g_00880mm_alt_obj_0000n00000_v020.bds. From https://naif.jpl.nasa.gov/pub/naif/pds/pds4/orex/orex_spice/spice_kernels/dsk/bennu_g_00880mm_alt_obj_0000n00000_v020.xml * Note that the DSK labels that will be included in the SPICE data set will be different. This should be OK. ------------------- =============================================== Errors unique to: NH-P/PSA-LORRI/ALICE/REX-5-ATMOS-V2.0 Certification Status: CERTIFIED, with minor liens. directory: 'document/' --> LF: Suggest adding some of the documents from the L2/3 data sets that are applicable to this data set, for instance: nh_met2utc, nh_fov, and payload_ssr. file: 'index/index.tab' --> Note that the PRODUCT_CREATION_TIME should have remained unchanged for almost all of these data products since V1.0. The values in this column do not match the corresponding value in the label file. This should always be the case. Please do not update the values in the data labels, but fix the index table to match what is found in the data labels. file: 'voldesc.cat' --> The ADDRESS_TEXT has a typo in the street address line. It should say "SUITE 300", not "SUITE 400". =============================================== Errors unique to: NH-X-ALICE-5-IPM-V1.0 Certification Status: CERTIFIED, with minor liens. Integration Space Description --> JN: Ran into issue w/ definition of integration space. lbl file says "total flux", aareadme.txt says Lyman-alpha, dataset has clarification that total counts are assumed to be Lyman-alpha. --> --> Joel said that Clarification important because we don't want people to think these are h alpha bright stars. It's the total count. --> --> Please add clarifications in all the appropriate places. file: 'catalog/dataset.cat' --> JN: In the DATA_SET_DESC, it describes that they integrated over Lyman-alpha, but a wavelength range should be given. --> --> Joel said that they did not impose a wavelength cutoff when doing IPM scans. It is a full UV detector, but lyman alpha dominates signal. --> --> LF: Please make sure that this is clear in the data set that it's integrating over the whole detector. file: 'data/nh_alice_ipm_scan_countrate.lbl' --> RC: Not necessary to fix, but it is odd that there are parentheses surrounding the PRODUCT_ID value. Parentheses are for ordered lists, and that keyword needs a single value. Suggest removing the parentheses. --> RC: line 45: ROWS = 135156 is one too many (it matches the entire file, when it should only be the spreadsheet part). Please fix. --> RC: lines 60,73: DATA_TYPE should be changed from MSB_INTEGER to ASCII_INTEGER. file: 'data/nh_alice_ipm_scan_countrate.lbl' --> LF: Fields 3-90 are all defined as F10.6 format, but some sig fig trailing 0’s are omitted, so the fields are not all F10.6 (see examples of F7.3, F8.4, and F9.5). Please add back the missing zeros in the data values to have them match the expected FORMAT for each column. file: 'voldesc.cat' --> The ADDRESS_TEXT has a typo in the street address line. It should say "SUITE 300", not "SUITE 400". =============================================== Errors unique to: NH-X-PEPSSI-4-PLASMA-V1.0 Certification Status: NOT CERTIFIED, needs quick delta review of documentation. Data appears good, but documentation incomplete and could mislead scientists. file: 'catalog/dataset.cat' --> RC: The DATA_SET_NAME has a trailing comma. Please remove. --> RC: You should add OBJECT = DATA_SET_MISSION for MISSION_NAME = "NEW HORIZONS KUIPER BELT EXTENDED MISSION" --> SJ: The text does not provide a column naming convention and the data labels do not provide that information in the descriptions. This should be corrected. --> --> RF (slide 36): Further description and suggestions: =================== The labels are criptic and not explained. These should be included and below is an example (although it could be written in many ways): LTTSDDI_X where L means Doubles and TT is the channel (0-15), S means the Sensor and DD is the sensor number (0-6), I is the species combined with "Unc" to indicate an Uncertainty, and X is the segment (a or b). LIonsAllAllS00_B or LIonsAllAllS00Unc_B … LionsAllAllSAll_B or LionsAllAllSAllUnc_B ... LIonsAllAllS012_B orLIonsAllAllS012Unc_B … L01toL13OddAllS00_B or L01toL13OddAllS00Unc_B … L01toL13OddAllSAll_B or L01toL13OddAllSAllUnc_B ... L01toL13OddAllS012_B or L01toL13OddAllS012Unc_B ... L01toL13OddAllS00_B or L01toL13OddAllS00Unc_B … L01toL13OddAllSAll_B or L01toL13OddAllSAllUnc_B ... L01toL13OddAllS012_B or L01toL13OddAllS012Unc_B … The explanation of the J’s in the "Data File Types" section is good, the Doubles and Triples files should be the same. Right now, the general user does not know how to interpret the labels. =================== --> SJ: The text describes the units of the flux data files BFLUX and LFLUX as counts per second while the labels correctly list them as "c/s/ster/cm^2/keV". See lines 126,139 for examples of where possible fixes are needed. --> RF (slide 32): The STOP_TIME and DATA_SET_DESC do not agree. See lines 14,25. Please fix. --> RF (slide 33): Missing information about how the data are organized into separate subdirectories. This should probably live before the Data File Headers section. Please add. Suggested text (please verify and adjust as needed): =================== data: total_counts: pepssi_reduced_j_YYYY (csv and lbl) double: pepssi_reduced_lZZZ_YYYY_X (csv and lbl) triple: pepssi_reduced_bZZZ_YYYY_X (csv and lbl) Where: YYYY is the year the measurements were taken X is the segment number (a or b) ZZZ is the units of the data (csv or flux) =================== --> RF (slide 34): The Data File Contents section currently is a description of the dataset and the section title is mislabeled (should be Dataset Contents). This section should be placed above the section labeled "Data File Headers". The "Data File Contents" section should describe what is in the data files. It should describe the contents of each type of data file and what is inside of each. The section "Data File Types" makes a stab at this. --> RF (slide 37): ABSTRACT_DESC has the wrong "through [date]". Please correct as mentioned in DATA_SESC. file: 'catalog/pepssi.cat' --> RF (slide 31): The statement at the end of the Data validity section (lines 339-341), talk about referring to the Primary HDU and extensions of the data products for more details. The problem is that this is only relevant for the L2 and L3 products, not the L4 product (which has only csv files). Suggest to remove the statement or clarify that this is for the L2 and L3 products only. files: 'data/*/*' --> SPECIES_HEADER and UNITS_HEADER are okay, but this information should not be hidden in 'header' text, but should be in the PDS label itself. It is fine to keep these headers, but we need the data in the PDS label as well, i.e. found in DESCRIPTION and UNIT for the individual FIELDS. --> --> SBN-TB: I see that you fixed these up, but including the data into the SPREADSHEET's FIELD objects in their DESCRIPTION, including the Lower/Upper energy bound. But the unit needs to be in the UNIT keyword as well for each FIELD. Note that NULL is not an acceptable value for the keyword (since it is a placeholder and implies it will be filled in later), but "DATA NUMBER" or "N/A" are valid. You will need to determine which (or if another) applies. --> For the SPREADSHEET object, the FIELD_NAMEs are criptic, and the DESCRIPTION doesn't help. Please make it clear what each column is. This may be done in the dataset.cat file, but it best here. --> I will also note that many of the FIELD->DESCRIPTION values (lower/upper energy or species) for the SPREADSHEET object use the value NULL. Is this correct? NULL is supposed to be a placeholder. Would UNK or N/A be more appropriate? --> SJ (slide 15): The meaning of the time column (start, center, end) of 1 hr average is not provided. Please do clarify/describe. --> --> RF (slides 38-39): Assumptions: Not enough information in the documentation is given to register the data within the 1 hour accumulation period. The following assumption was made in order to analyze the data: Time stamp in the data files are at the beginning of the accumulation period. directory: 'document/' --> SJ: Consider adding the nh_mission_trajectory, bad time intervals (bti), and all relevant command history files (seq) to this data set for reference. --> RF: There is a need for documentation unique to L4 that describes the data. file: 'voldesc.cat' --> Is VOLUME_SET_NAME and VOLUME_NAME correct? They imply this is Pluto Encounter data, but this appears to be mission wide data. Please fix if not correct. --> The ADDRESS_TEXT has a typo in the street address line. It should say "SUITE 300", not "SUITE 400". =============================================== Errors unique to: NH-X-SWAP-5-DERIVED-SOLARWIND-V2.0 Certification Status: CERTIFIED, with minor liens. file: 'aareadme.txt' --> RF: The word "speed" in "solar wind speed" on the second line of the second paragraph (line 21) is a typo and should be deleted. "Solar wind" goes along with the following items on the third line: "proton density, proton speed, ..." file: 'catalog/dataset.cat' --> RF: typo line 22: insert "and" after "pressure," and before "proton". --> RF: typo line 35: "Spice" => "SPICE" --> RF: typo: Insert a blank line between the lines 75 and 76 to separate the two paragraphs. --> RF: typo line 101: Insert "a" after "is" in "system is heliocentric system" to be "system is a heliocentric system". --> RF: In the ABSTRACT_DESC, the word "speed" in "solar wind speed" on the second line of the second paragraph (line 147) is a typo and should be deleted. "Solar wind" goes along with the following items on the third line: "proton density, proton speed, ..." --> RF: In the ABSTRACT_DESC, add the word "and" at the end of line 148, so to read "thermal pressure, and spacecraft ...". --> RF: In the ABSTRACT_DESC, remove "and speed" from "spacecraft position and speed." --> RF: IN THE ABSTRACT_DESC, add a blank line between the second and third paragraphs (lines 154-155). file: 'catalog/swap.cat' --> RF (slide 44): On line 103, it says "as of 20.April, 2007" for a weblink to the SSR. It still works today; recommend updating the date. --> RF (slide 45): The "Note on Reading the Data and Extensions" (lines 248-264) only apply to the L3 data and not the L5 data. file: 'data/nh_pickupions_2008_11_16.{csv,lbl}' --> In the label DESCRIPTION it references "MCCOMAS2017" twice, but I think it should be "[MCCOMASETAL2017]". --> --> If this reference is correct, then this reference needs to be spelled out in the file and/or REF.CAT --> FORMAT should not equal "TIME" but "A##" where "##" is the same as BYTES. Do not confuse FORMAT with DATA_TYPE. file: 'data/nh_sw_20081010_20200127.lbl' --> RF: line 116 typo: "Tolar" => "Solar" in the DESCRIPTION for FIELD 5.