Document Properties

identifierSOL-SGS-TN-0009
shortSOMD
latest release2.5
latest release date2022-12-02
status
RELEASED
security classificationESA UNCLASSIFIED - For Official Use
owner

Helen Middleton 

Document Comments

Format required for Solar Orbiter’s data products and metadata. This technical note includes the SOC definition on the data formats and file naming convention, and a list of the common definition of processing levels. The metadata that are mandatory or optional, to be common for all Solar Orbiter science data, are defined in the form of FITS keywords (for imagery and some spectral data) and ISTP attributes.

Document Releases

  File Modified
PDF File SOL-SGS-TN-0009-MetadataStandard-2.5-TrackedChanges.pdf 02 Dec, 2022 by Helen Middleton
PDF File SOL-SGS-TN-0009-MetadataStandard-2.5.pdf 02 Dec, 2022 by Helen Middleton
PDF File SOL-SGS-TN-0009-MetadataStandard-2.4-TrackedChanges.pdf 02 Sep, 2019 by Andrew Walsh
PDF File SOL-SGS-TN-0009-MetadataStandard-2.4.pdf 02 Sep, 2019 by Andrew Walsh
PDF File SOL-SGS-TN-0009-MetadataStandard-2.3.pdf 21 Aug, 2019 by dgalan
PDF File SOL-SGS-TN-0009-MetadataStandard-2.2.pdf 21 Aug, 2019 by dgalan
PDF File SOL-SGS-TN-0009-MetadataStandard-2.1.pdf 21 Aug, 2019 by dgalan
PDF File SOL-SGS-TN-0009-MetadataStandard-2.0.pdf 21 Aug, 2019 by dgalan
PDF File SOL-SGS-TN-0009-MetadataStandard-1.0.pdf 21 Aug, 2019 by dgalan

Document Source

  File Modified
Microsoft Word Document SOL-SGS-TN-0009-MetadataStandard.docx 02 Dec, 2022 by Helen Middleton

5 Comments

  1. Anik De Groof

    Proposed updates for the TN, to be folded into version 2.5:

    • make the FITS keyword TDIMn in FITS binary extension tables Optional (description says so the M-type is specified as mandatory for solar orbiter FITS)
    • update the EUI example filenames on p14 with the EUI DPDD: 
      • "solo_LL02_eui-fsi-304_20201008T121230_V01C.fits" should be "solo_LL02_eui-fsi304-image_20201008T121230_V01C.fits"
      • "solo_L1_eui-fsi-304_20201008T121230_V01.fits"should be "solo_L1_eui-fsi304-image_20201008T121230_V01.fits"
    • update the example values for OBS_TYPE and OBS_ID so they follow the new standard

    1. Helen Middleton

      EUI example filenames updated from eui-fsi-304 to eui-fsi304.

      BINTABLE TDIMn made optional (P → O).

      For OBS_TYPE and OBS_ID I'll need to check with you.

      1. Helen Middleton

        Example given on Teams put into document (thanks!):

        SOOPNAME= 'L_SMALL_MRES_MCAD_Connection-Mosaic' / name of the SOOP Campaign that
        SOOPTYPE= 'LS4     '           / campaign ID(s) that the data belong to         
        OBS_MODE= 'EUV_CH  '           / observation mode                               
        OBS_TYPE= 'mACv    '           / encoded version of OBS_MODE                    
        OBS_ID  = 'SEUI_060A_LS4_111_mACv_111' / unique ID of the individual observation

  2. Anik De Groof

    Clarification to be added in next version (2.5) - thanks to E. Kraaikamp (EUI):

    The MetadataStandard says that this is a "Mandatory keyword that contains the start time of data acquisition in onboard time units (double-precision, floating-valued)."

    The fact it is a double-precision floating-valued number in onboard-time units means that we can have a time like "637551003.4117279", where the sub-seconds part is created from the fine part of the CUC time. And as this is cuc fine is a counter from 0-65535, you get create this OBT_BEG by doing:
    cuc_coarse + cuc_fine/65536.

    The value 637551003.4117279 translates back to a coarse of 637551003 and a fine of round(0.4117279* 65536) = round(26982.9996544) = 26983. I have tested the conversion from float to coarse + fine and back for many years in the future, and that all works out fine, so rounding errors are not a problem for the fine resolution of the time.

    The value you can then feed to the spice time conversion routine is "637551003:26983". Directly passing OBT_BEG of 637551003.4117279 to the spice conversion software does not result in an error, but it treats it as if the fractional part rolls over several seconds, so the 637551003.4117279 becomes 637551003 + 4117279 / 65536 = 637551003 + 62.8246917724609375 = 637551065.8246917724609375. A date 62 and a bit seconds further in the future. So this is an easy mistake to be made.

    It may have been better to not store OBT_BEG as a floating point, but as a string instead with a semi-colon to remove confusion.. "637551003:26983", but as this may upset the pipeline for many instrument teams, we will not update this unless there is a consensus on changing this. (will be discussed at next LLWG)

    1. Helen Middleton

      The storage (value type) for the OBT has been changed from LONG integer to FLOAT to be able to store both the coarse and fine parts of the OBT, and this is now reflected in the relevant table (Table 3-2). 

      Not sure what CUC means, so for now, I've explained this as best as I can on p24, and you'll need to decide if any further details are needed.