Contents

Configuration

Configuration

Configuration of a target, mission, instrument, and data product types is done through 3 types of files:

  • Configuration file (psa_geo/psa_config.json),

  • Addendum SPICE kernel files, IK or DSK (psa_geo/data/addendum),

  • Python module containing Instrument Product classes (psa_geo/geogen/product.py).

The following figure illustrates an example of the relationship between these files and underlying information.

../_images/configuration_files.png

Target

Configuration file

Configuring for a specific digital shape model and/or body-fixed reference frame requires the addition of a target JSON object in the configuration file.

Applicable targets (eg: ‘SOLAR WIND’) can be added to applicable_targets member in the configuration file.

Addendum kernels

DSK files specified within the configuration file must be added into the addendum directory.

Additional synonyms and reference name for a target can be specified within an addendum IK file for a given mission. The reference name is used to form the basename of GEOGEN output files. Example for Rosetta (chury_rosetta_osinac_rdr_ell_split.json):

\begindata

    NAIF_BODY_NAME += ( '67P/CHURYUMOV-GERASIMENKO 1 (1969 R1)' )
    NAIF_BODY_CODE += ( 1000012 )

    NAIF_BODY_NAME += ( '67P/CHURYUMOV-GERASIMENKO 1969 R1' )
    NAIF_BODY_CODE += ( 1000012 )

    NAIF_BODY_NAME += ( 'CHURY' )
    NAIF_BODY_CODE += ( 1000012 )

\begintext

Mission

Configuration file

Configuring for a mission requires the addition of a mission JSON object in the list of missions in the configuration file. It must include the following information:

Spacecraft NAIF body name

The list of allowed spacecraft NAIF body names is defined by the PDS_NAIF_MAPPING dictionary.

Note

There is currently a one-to-one relation between a mission and a spacecraft/instrument host. This can be a limitation for mission with multiple instrument hosts (eg: BepiColombo or Rosetta).

Primary target name

A primary target name is used instead of an input SPICE-unknown target name, when defined as applicable (see Target Assignment).

Note

Only one primary target per mission can currently be defined. This can be a limitation for missions with multiple targets (eg: JUICE or BepiColombo during cruise phase). A workaround can be use the --forced-target option, or implement a way to detect the nearest target in a list of multiple primary targets.

SPICE kernels paths

At least the ESA’s mission SPICE Kernels Dataset must be available to enable computation (addendum IK file path is required to define instruments detectors).

PDS version

Either PDS3 or PDS4.

List of instruments

At least one instrument must be defined.

Instrument

Configuration file

Configuring for an instrument requires the addition of an instrument JSON object in the list of instruments for a given mission in the configuration file. It must include the following information:

Instrument ID

PDS instrument identifier matching input PLF instrument_id property values.

List of product types

At least one data product type must be defined.

Addendum IK file

It also requires to define the detector type and related parameters in an addendum IK file: either IN-SITU (default), POINT, LINE, FRAME. Additional keywords can be defined so as to overwrite or set specific detector information, like for example a detector FOV or iFOV. All instruments geometry model parameters can be defined in a single mission-related IK file (eg: mex_addendum.ti). See Addendum IK File for detailed specifications.

Example for MEX_OMEGA_SWIR_C detector (NAIF code -41421), which is associated to EDR data products:

\begindata

    INS-41421_GG_DETECTOR_TYPE    = 'LINE'
    INS-41421_GG_DETECTOR_MODES   = ( 16,   32,   64,  128  )
    INS-41421_GG_AOV_ROT_VECTOR   = ( 0.000  1.000  0.000 )
    INS-41421_GG_AOV_ANGLES       = ( 1.0, 2.1,  4.2,  8.5  )
    INS-41421_GG_AOV_ANGLE_UNITS  = 'DEGREES'

\begintext

Product type

Configuration file

Configuring for an product type requires the addition of a product JSON object in the list of products for a given mission in the configuration file. It must include the following information:

Type

Data product type matching input PLF product_type property values. If no product type is available for an instrument PDS data product (eg: HRSC on Mars Express), an arbitrary product type can be chosen (eg: EDR or RDR).

Python Intrument Product class name

Naming scheme recommendation is <INSTRHOST_INSTR[_TYPE]>.

Required product properties

Additional PLF product properties required by the Instrument Product class to derive the detector and observational information. Common PDS3/PDS4 data product required properties are defined in the configuration file (see req_product_prop).

No properties are required for IN-SITU detectors if --force-detector option is used.

Example for OMEGA EDR data products:

{
  "id": "OMEGA",
  "products": [
    {
      "type": "EDR",
      "py_class": "MEX_OMEGA_EDR",
      "req_props": [
        {
          "name": "core_items",
          "path": "QUBE/CORE_ITEMS"
        }
      ]
    }
  ]
}

The most minimalist configuration for an instrument, that is then considered to be IN-SITU, is for example for AMIE on SMART-1 the following; however requiring the use the --force-detector option to enable computation (pointing-independent only):

{
  "id": "AMIE",
  "products": [
    {
      "type": "EDR",
      "py_class": "",
      "req_props": []
    }
  ]
}

Instrument Product class

It also requires to write a Python Instrument Product class that derives the following detector and observational information from PLF product properties:

  • Associated detector NAIF body name (mandatory).

  • Detector mode, for LINE detectors that are mode-dependent (eg: OMEGA on Mars Express).

  • Sub-frame FOV reference and cross axis ratios, for FRAME detectors with sub-framing behaviour (eg: CASSIS on TGO).

  • Number of data records (optional, default is T_STEPS_MAX)

No Intrument Product class is required for IN-SITU detectors if --force-detector option is used.

Additional observational information can be set within an Instrument Product class if needed, eg: time_offset.

Example for OMEGA EDR data products:

class MEX_OMEGA_EDR(Product):
    """Product class for MEX/OMEGA EDR data products.

    - ``detector_name`` is always set to 'MEX_OMEGA_SWIR_C'.
    - ``detector_mode`` is set to the first element of the data cube dimension, given by the ``core_items`` property value.
    - ``n_data_records`` is set to the third element of the data cube dimension, given by the ``core_items`` property value.
    """
    def __init__(self, props_dict, config, silent=False):
        super().__init__(props_dict, config, silent=silent)

        if self.valid:
            self.detector_name = 'MEX_OMEGA_SWIR_C'
            self.detector_mode = int(self.core_items[1:-1].split(',')[0])
            self.n_data_records = int(self.core_items[1:-1].split(',')[2])

See more examples Instrument Product classes of classes implemented for Mars Express, Rosetta, and Trace Gas Orbiter data products.

previous

Tasks and Workflow

next

Training JupyterHub