L'TES Liens =========== These liens are for the entire bundle and all collections therein. Liens may not apply or be relevant in all places. SPECIAL_NOTE ============ The final reconstructed Lucy-target ephemeris (SPK) for the Dinkinesh flyby was generated using data dependent on an SCLK kernel (version 29) that had been frozen by the project before the encounter for uplink planning purposes. Compared to later SCLK kernel versions, the version used in processing did not properly account for the drift in the spacecraft clock that occurred during the freeze period. This resulted in an ephemeris timing error of a few tenths of a second. The instrument data products included in this submission were processed using the final SPK noted above, but with a later version of the SCLK kernel (version 33) and with attitude kernels (CKs) whose pointing timings were derived directly from this later SCLK version. The net effect of all this is that there are small errors in the geometry as calculated using NAIF SPICE, and these errors are most significant, small as they are, at the time of encounter close approach. Product labels are affected to the extent they inherit geometric quantities from the data above. The instrument data product portions affected are as follows: (1) header data (keyword/value pairs) related to geometry (ALL products) (2) L’Ralph LEISA "backplane" FITS extension that contains geometry information for each frame (UDP and CDP products) (3) L’TES geometry arrays in CDP products. To mitigate the effect of the geometry timing error, the user may choose to re-calculate the SPICE information using the latest kernel set published in the Lucy SPICE archive. Note that the erroneous SPK was not published to the archive, although SCLK versions 29 and 33 were. During lien resolution, all data will be reprocessed using an updated SPK that corrects the aforementioned timing issue. The geometric reprocessing will use SPK lcy_230815_240201_240101_dinkinesh_reconstruction_final_v2.bsp, which has been delivered to NAIF and appears in the Lucy SPICE archive. Documentation ============= file: document/ltes_sis.pdf --> The arrays in this table do not align with the actual data. For example, the table has sclk either located in at array index number 54 for hkraw or at 56 for raw. But the actual data files have sclk as the first data array. The table order appears to have been alphabetized by array name, as opposed to data order within structure. The data appears to be organized in a practical order. --> The documentation table should be adjusted to reflect this order or update the Array Index Number. --> There are some statements that are inconsistent with the datasets themselves. The most obvious one is that “LTES collects data in the spectral range 5.71—100 µm”, while the calibrated data runs from 3.3-1157µm. The label for the calibrated data disagrees with both of those, with the “Field Of View” saying it collects data from 6-75 µm. --> The SIS says “The instrument will start collecting data one day before closest approach…continue until one day after closest approach”. That’s not true for the Dinkinesh data. --> The SIS says in the section on calibrated data that “The interferograms…are converted into voltage spectra…then converted into calibrated radiance spectra using the LTES calibration software”. Include document detailing steps taken by calibration software. --> --> The equation on Page 10 includes terms that are the Fourier transform of the interferogram, and are in Volts (”Voltage value”). Array index 26 (on page 21) is “ifgm”, which claims to be the interferogram, but is also in Volts. Are all of these consistent? --> The “intended_target” keyword explicitly says that it may differ from the actual target. Documentation should specify what keyword identifies the actual target. --> The only “applicable software” listed is Davinci, but the page pointed to has been updated once since 2011 (to include new binaries to download) and has very little in the way of support for new users. Data ==== file: data_dinkinesh_calibrated/tes_0752123018_dinkinesh_sci_01.hdf --> Science data file corrupted --> --> 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 PDS4_VIEWER was able to read and export all data arrays that I tried except the local_time array (IndexError: list index out of range) --> Type=0 observation type not described in SIS. --> The values for ”xaxis” (which really should be renamed ”wavenumber”) in slots 348-399 are all identical. Is there a reason they aren’t trimmed? --> At least some values are not what I’m expecting for some keywords. The phase angle, for instance, is 9999 for all samples, despite it pointing at the target. The same is true of the emission angle, for instance. Sub-spacecraft latitude is there, though. --> In future deliveries, for example starting with the 52246 Donaldjohanson encounter data, SBN would prefer that L'TES deliver its data in a more user-friendly standard format, like FITS, rather than a hierarchical data format (hdf; in this case hdf5) or hdf-derived format. Labels ====== Should double check the following Label Context Reference Mismatches, if they are using the correct target reference LID. Note there is always the option to not use a reference LID when none other is appropriate, or one may be created if it makes sense: --> --> "INT_CAL" vs "INTERNAL SOURCE" (urn:nasa:pds:context:target:calibrator.internal_source) --> --> --> affected files: 'data_dinkinesh_raw/tes_0752123094_02098_eng_03.xml' and 'data_dinkinesh_raw/tes_0752136681_02115_eng_03.xml' --> --> "SPACE_CAL" vs "SPACE" for urn:nasa:pds:context:target:calibration_field.space (urn:nasa:pds:context:target:calibration_field.space) [2 instances] --> --> --> affected files: 'data_dinkinesh_raw/tes_0752123018_02097_eng_03.xml' and 'data_dinkinesh_raw/tes_0752136759_02116_eng_03.xml' --> --> --> Note that LEISA and MVIC uses the value 'Space Stare' instead. --> --> "UNKNOWN" vs "TEST IMAGE" for urn:nasa:pds:context:target:calibrator.test_image --> --> --> This may be a case where we drop the LID. --> --> --> Why is this labeled as a 'Calibrator' type? --> --> --> affected file: 'data_dinkinesh_hkraw/tes_0751610627_00000_eng_02.xml' file: 'data_dinkinesh_hkraw/collection.xml' --> Add Identification_Area.Citation_Information.doi = "10.26007/5svc-pd48" --> typo in Identification_Area.Citation_Information.description: "intiation" => "initiation" files: 'data_dinkinesh_raw/tes*xml' --> There are instances of Element_Array.unit having a number in it (ex: "s/65536"). This is unexpected. Would the number better be identified as a Element_Array.scaling_factor in this particular case? file: 'document/collection.xml' --> suggest updating Identification_Area.Citation_Information.description to spell out the "L'TES" instrument and/or state "Lucy L'TES" file: 'document/ltes_ssr.xml' --> The Identification_Area.Citation_Information.description says this paper is the "(L'TES) data products explanation" but isn't this an instrument description? For other SSR papers, they either state it is the SSR of the instrument or describes the instrument. EN Review ========= lucy.ltes:data_dinkinesh_calibrated *.xml - Suggestion: to match the context products, change Lucy Mission Lucy Spacecraft Lucy Thermal Emission Sepctrometer (LTES) DINKINESH to Lucy Lucy Lucy Thermal Emission Spectrometer (L'TES) (152830) Dinkinesh collection.xml - The product in this lid_reference isn't given here. Verify the LID is correct urn:nasa:pds:lucy.mission:document:lucy_mission_info In the 2023.05 review, many collection.xml had a lid_reference to urn:nasa:pds:lucy.mission:document:lucymissioninfo tes_0752123018_dinkinesh_sci_01.xml - The Array_1Ds emission_angle and phase_angle (and others?) have many values of 9999.0. Add Special_Constants to those Array_1Ds. lucy.ltes:data_dinkinesh_hkraw *.xml - Suggestion: to match the context products, change Lucy Mission Lucy Spacecraft The Lucy Thermal Emission Spectrometer (L'TES) Lucy Thermal Emission Sepctrometer (LTES) to Lucy Lucy Lucy Thermal Emission Spectrometer (L'TES) Lucy Thermal Emission Spectrometer (L'TES) collection.xml - The product in this lid_reference isn't given here. Verify the LID is correct urn:nasa:pds:lucy.mission:document:lucy_mission_info In the 2023.05 review, many collection.xml had a lid_reference to urn:nasa:pds:lucy.mission:document:lucymissioninfo tes_0751610627_00000_eng_02.xml - Suggestion: to match the context product, change UNKNOWN urn:nasa:pds:context:target:calibrator.test_image to TEST_IMAGE urn:nasa:pds:context:target:calibrator.test_image lucy.ltes:data_dinkinesh_raw *.xml - Suggestion: to match the context products, change Lucy Thermal Emission Sepctrometer (LTES) DINKINESH SPACE_CAL INT_CAL to Lucy Thermal Emission Spectrometer (L'TES) (152830) Dinkinesh SPACE INTERNAL SOURCE collection*.xml - Suggestion: to match the context products, change Lucy Mission Lucy Spacecraft to Lucy Lucy collection.xml - The product in this lid_reference isn't given here. Verify the LID is correct urn:nasa:pds:lucy.mission:document:lucy_mission_info In the 2023.05 review, many collection.xml had a lid_reference to urn:nasa:pds:lucy.mission:document:lucymissioninfo lucy.ltes:document *.xml - Suggestion: to match the context products, change Lucy Mission Lucy Spacecraft Lucy Thermal Emission Sepctrometer (LTES) to Lucy Lucy Lucy Thermal Emission Spectrometer (L'TES) collection.xml - The product in this lid_reference isn't given here. Verify the LID is correct urn:nasa:pds:lucy.mission:document:lucy_mission_info In the 2023.05 review, many collection.xml had a lid_reference to urn:nasa:pds:lucy.mission:document:lucymissioninfo - Suggestion: add lid_reference to target Global Liens ============ issue: There are no subdirectory structure, with all products placed at the root of the collection directories. --> TB: Strongly suggest adding some structure for the user that may browse the collection, so as to not overwhelm them with number of files, perhaps unrelated, mixed together. issue: Label Context Reference Mismatch --> The 'name' values associated with internal references to context objects do not match the Context_Area.*.name values as found in the context object file referenced. For targets, it is probably fine to be different if it conforms to SBN formatting. Many of these context files were provided by the Lucy mission, and so it is expected to match. Note, usages are not consistent across all bundles or even files within a bundle or collection (correct in some labels, not in others). Those unique to a particular bundle will be mentioned with that bundle. Lastly, please note that the PDS validate tool will identify all instances of these if you need a complete list of what and where. Examples common across all bundles: --> --> "Lucy Mission" vs "Lucy" (urn:nasa:pds:context:investigation:mission.lucy) --> --> "Lucy Spacecraft" vs "Lucy" (urn:nasa:pds:context:instrument_host:spacecraft.lucy) --> --> "Dinkinesh" or "DINKINESH" vs "(152830) Dinkinesh" (urn:nasa:pds:context:target:asteroid.152830_dinkinesh) issue: Copies of published papers in PDS --> Identification_Area.Citation_Information.doi should not be for the published paper. PDS should never produce a DOI for a paper primarly published elsewhere. --> Add to the Identification_Area.Citation_Information.description the fact these papers of exact copy of open access documents. --> Add to the an to the published paper and add a description mentioning the relation between the PDS copy and the publish copy. Ex: "Original published source of this Open Access document." --> For any other label referencing these PDS copies in their Reference_List, we should include the external paper doi reference along side the internal reference to the internal copy. issue: Reference_List references missing or , or not being necessary. --> Whenever you reference a paper in a data product, please add a (for external_reference) or (for internal_reference) stating very briefly why this paper is being referenced. This can be as simple as saying it is the "SSR paper" or "description of the mission". An example is where the Calibration paper is being referenced; we should add a Calibration paper. For internal references to data products, usually the is clear enough, but this is not the case when referencing documents. If the referenced paper is not considered essential to either understanding or using the product, it should not be referenced. --> --> Example: lucy.leisa/data_dinkinesh_calibrated/lei_0752129330_02298_sci_04.xml (lines 1042-1049, two references) issue: Mission Phase --> Is the mission_phase_name keyword going to be in any of the labels? Suggest adding this to the Lucy LDD, with a standard list of values to validate against. You can use the New Horizons LDD (nh:mission_phase_name) as an example. issue: Adding sb:Calibration_Information --> For the calibrated products, I see that the Reference_List includes the data_to_raw/calibration_product. You can also add this information, plus additional information for the user to the "sb:Calibration_Information". I would highly highly encourage this. files: '*/bundle.xml' --> Suggest removing PDS4 jargon, "Bundle", from Identification_Area.title and replace with "Archive" or something similar. --> Suggest clarifying in the Identification_Area.Citation_Information.description that there are more than just "data products" in these bundles. There are also document products for instance; also Calibration products, though this is a usually a data product of one sort or another. --> Why does each bundle (except mission and rss) have a Reference_List that includes the mission:document, [instrument]:document (which is found within the bundle), and [instrument] SSR paper (found within the bundle)? Are these necessary for the generation of the bundle? If so, why are they not included in the collection.xml files? files: '*/*/collection.xml' --> For the Identification_Area and Citation_Information sub-area, we take these values as what we would want to use for reference and citation information for the PDS product (collection in this case), like titles, authors, editors, and abstract (pds:description). We use these to populate DOI meta data, for assigned DOIs. Please have these values reflect what you would want to see in the DOI meta data, and by consequence at the ADS. --> --> Note that first occurrences of acronyms will be spelled out with the acronym being in parentheses. Ex: "L'LORRI" => "Lucy LOng Range Reconnaissance Imager (L'LORRI)". I would recommend doing this in your bundle/collection labels, in the abstract (pds:description) and/or title. --> Suggest removing PDS4 jargon, "Collection", from Identification_Area.title --> Strongly (on verge of requiring for active missions) suggest adding Funding_Acknowledgement to Identification_Area.Citation_Information. --> entries are not consistent. Please confirm these are correct. In general there is an internal reference to a copy of Levison et al. (2021) paper and an internal reference to the instrument SIS. Exceptions noted below: --> --> urn:nasa:pds:lucy.llorri:calibration::1.0 (only lists SIS) --> --> urn:nasa:pds:lucy.ltes:document::1.0 lists the instrument SSR paper as well --> --> urn:nasa:pds:lucy.mvic:document::1.0 lists the instrument SSR paper as well --> --> urn:nasa:pds:lucy.mission:document::1.0 lists no references (probably correct) --> Please add to the Reference_List an internal link to the collection_overview product. files: '*/readme.txt' --> At the end of this file it suggests questions can go to "https://pds-smallbodies.astro.umd.edu/about/contact_info.shtml or pds-operator@jpl.nasa.gov". Using this url and/or email sounds like a bad idea. SBN website may move, or the pds-operator may change address. Remove contact info.