Lucy L'TES Liens ================ Documentation ============= --> The July 2024 version of the SIS could use some updates. For example, Table 3-4 identified Local Time as stream text. In the PDS4_Viewer, it’s identified as an ASCII table. The version of the PDS4_Viewer that I was using could not read the ASCII table. However, I was able to extract the data using the data offset, extracting the data as bytes, and converting to string. All local times stored were “99:99:99.” I also had to use this work-around to read the UTC table. --> Should ideally also explain why there’s no post-close approach data --> Update SIS with target type information. --> --> Per the Lucy team, target_type_num=0 is a valid value. This flags data that cannot be used for calibration purposes. A common reason for this designation is the record having insufficient samples in the interferogram. Fixing it will require updates to the XML label and the SIS. Update in the label is to add something like "0=not useable" to the for the target_type_num and similarly in the SIS for the description of "target_type_num" in Table 3-4 on page 38. Data ==== Calibrated Data --> Cannot read in using IDL read_pds, likely because of the local time and UTC tables. IDL was unable to read the science data file. Attempts to use IDL pds_read.pro resulted in a “End of file encountered” error suggesting there is missing data somewhere in the file. --> The departure target observations do not have associated calibrated radiance, even when voltage spectra were available. Were these data somehow contaminated? --> The “hot” space looks bothered me. Fig. 3 shows an example of one of them (SCLK = 798441111). The calibrated spectrum is consistent with “seeing” a T=270K object that fills 50% of the FOV. What is LTES looking at? Is this the same reason the departure observations were not calibrated? Is the scene being contaminated by the spacecraft being in the FOV? --> --> Per the Lucy team, The "hot" space data (target_type_num=1) in question weren't used by the calibration pipeline to calibrate any target data, so the pipeline did not perform the full set of processing on them, resulting in those apparent high temperatures. There is no intention to use these data, but we understand they could cause confusion, so the L'TES team will provide a fix in the pipeline. Labels ====== --> Target_Type_Number appears to have issues. ----> Target type 0 is not defined. ----> Target type 1 is space looks, some of which appear hot. Somewhere this should be explained. Maybe “hot” space needs its own target type number. ----> Target type 2 is internal calibration looks. -------> Per the Lucy team, target_type_num=0 is a valid value. This flags data that cannot be used for calibration purposes. A common reason for this designation is the record having insufficient samples in the interferogram. Fixing it will require updates to the XML label and the SIS. Update in the label is to add something like "0=not useable" to the for the target_type_num and similarly in the SIS for the description of "target_type_num" in Table 3-4 on page 38. -------> Per the Lucy team, The "hot" space data (target_type_num=1) in question weren't used by the calibration pipeline to calibrate any target data, so the pipeline did not perform the full set of processing on them, resulting in those apparent high temperatures. There is no intention to use these data, but we understand they could cause confusion, so the L'TES team will provide a fix in the pipeline. file: 'bundle.xml' --> Missing the File_Area_Text class for the readme.txt file. file: 'data_donaldjohanson_hkraw/collection.xml' --> The needs to be differentiated from the raw data collection. Suggest changing it from "Raw Data" to "Raw Housekeeping Data" as was done with the Dinkinesh delivery. --> Citation_Information.description (i.e. abstract) needs to make it clear it is not the raw products, but the raw housekeeping products. The description in the Dinkinesh delivery was much more verbose and useful and so I suggest you bring over that text and update accordingly. file: 'data_donaldjohanson_calibrated/collection_overview.xml' --> The LID for this file says dinkinesh, but it should be for donaldjohanson. Please correct the logical_identifier. file: 'data_donaldjohanson_calibrated/tes_0798357094_donaldjohanson_sci_03.xml' --> The Modification_History has been dropped. Please add it back and ensure the pipeline produces it (it was present in Dinkinesh). --> PIPELINE CONCERN: Why has the calseqid changed from a Array_1D (as found in Dinkinesh) to a Stream_Text in DJ? --> PIPELINE CONCERN: Why has the source_files object moved down 5 places as compared to Dinkinesh? --> PIPELINE CONCERN: Why has the Special_Constant n/a 9999 dropped from the incidence_angle, lat, lon, phase_angle, ? --> PIPELINE CONCERN: Fixed typo is back: (line 2006) "Scan length in seconds with possible values of 2, 1, 0.5." => "Scan length in seconds with possible values of 2, 1, or 0.5." --> [Dinkinesh Lien]: Lien fixed in Dinkinesh regarding "ticks", but back here. Better text has been removed on line 2053, expect: "<description>Spacecraft clock sub-seconds of each observation in the data product. Each tick is 1/65536 sec.</description>. Also the unit has changed from "ticks" to "s/65536" --> Why does the proc:software_version_id for UDP says "?"? Should this even be here for calibrated product? There is an additional software line for CDP which has remained unchanged, version 1.8. file: 'data_donaldjohanson_hkraw/tes_0797932680_00000_eng_01.xml' --> PIPELINE CONCERN: The Identification_Area.title should probably include "housekeeping" to differentiate from the raw products found in the raw collections. This was clarified in the description in the Dinkinesh collection, but now the description says it is a "science data product". Which is it? --> PIPELINE CONCERN: The purpose is now "Science" instead of "Engineering" as it was in Dinkinesh. --> The Target_Identification is now urn:nasa:pds:context:target:calibrator.unk whereas in Dinkinesh it was urn:nasa:pds:context:target:calibrator.non_science. Which should it be? --> [Dinkinesh Lien]: Lien fixed in Dinkinesh regarding "ticks", but back here. Better text has been removed on line 2053, expect: "<description>Spacecraft clock sub-seconds of each observation in the data product. Each tick is 1/65536 sec.</description>. Also the unit has changed from "ticks" to "s/65536". This affects the sclk_sub object. files: 'data_donaldjohanson_raw/tes*.xml' --> The Citation_Information.description in the Dinkinesh lien addressed copy added the word "Uncalibrated" to the beginning, but now it is gone. --> [Dinkinesh Lien]: Lien fixed in Dinkinesh regarding "ticks", but back here. Better text has been removed on line 2053, expect: "<description>Spacecraft clock sub-seconds of each observation in the data product. Each tick is 1/65536 sec.</description>. Also the unit has changed from "ticks" to "s/65536". This affects the sclk_sub object. Raw Data --> Some parameters are missing units in the labels: BB and mirror temperatures are explicitly in degrees C, but detector and board temperatures don’t list units. Cal_res also missing units, though probably could be guessed? Calibrated Data --> Note that the phase angle is missing from all of these data, showing 9999. The emission and incidence angles also show 9999. So, need to get phase angle from different source, which requires cross-referencing the times LTES was looking at the target with UTC times, then going to ephemeris. Confirm that this is documented in the SIS and add if missing. EN Liens ======== *.xml - The document/ dir and any associated SIS were not part of this review, but many files have a lid_ or lidvid_reference to urn:nasa:pds:lucy.ltes:document:ltes_sis Please ensure this will be available in the real bundle. */collection_overview.* - "collection" is a "reserved base name component" in the PDS4 Standards. Suggestion: rename these files to "overview.*". bundle.xml - This has lid_references to collections not in the bundle under review: urn:nasa:pds:lucy.ltes:data_dinkinesh_calibrated::1.0 urn:nasa:pds:lucy.ltes:data_dinkinesh_hkraw::1.0 urn:nasa:pds:lucy.ltes:data_dinkinesh_raw::1.0 Please ensure those collections will still be in the real bundle. - Since readme.txt exists, bundle.xml should point to it, something like <File_Area_Text> <File> <file_name>readme.txt</file_name> </File> <Stream_Text> <offset unit="byte">0</offset> <parsing_standard_id>7-Bit ASCII Text</parsing_standard_id> <record_delimiter>Carriage-Return Line-Feed</record_delimiter> </Stream_Text> </File_Area_Text> between Bundle and Bundle_Member_Entry - The bundle under review has no document/ directory, but bundle.xml has <lidvid_reference>urn:nasa:pds:lucy.ltes:document::1.0</...> data_donaldjohanson_calibrated/collection_overview.xml - This file's LID is ...:data_dinkinesh_calibrated:... instead of ...:data_donaldjohanson_calibrated:... If that's intentional, many files would have to change. data_donaldjohanson_hkraw/collection.xml - Suggestion: since the label in this collection has it, add lid_references to urn:nasa:pds:context:target:calibrator.unk data_donaldjohanson_raw/ - Too many files sit at the top level. Is there a natural split into subdirectories, perhaps by lucy:observation_id? data_donaldjohanson_raw/collection.xml - Suggestion: since labels in this collection have them, add lid_references to urn:nasa:pds:context:target:calibration_field.space urn:nasa:pds:context:target:calibrator.test_image urn:nasa:pds:context:target:calibrator.unk bundle.xml should add these 3 as well