Read RIDF Files

This section explains how to read RIDF files using artemis. Currently, binary RIDF files are processed using two classes: art::TRIDFEventStore and art::TMappingProcessor.

Using art::TRIDFEventStore to Read Data

To load data from a RIDF file, use art::TRIDFEventStore. Here is an example of a steering file:

Anchor:
  - &input ridf/@NAME@@NUM@.ridf
  - &output output/@NAME@/@NUM@/hoge@NAME@@NUM@.root
  - &histout output/@NAME@/@NUM@/hoge@NAME@@NUM@.hist.root

Processor:
  - name: timer
    type: art::TTimerProcessor

  - name: ridf
    type: art::TRIDFEventStore
    parameter:
      OutputTransparency: 1
      Verbose: 1
      MaxEventNum: 100000
      SHMID: 0
      InputFiles:
        - *input

  - name: outputtree
    type: art::TOutputTreeProcessor
    parameter:
      FileName:
        - *output

The timer processor shows analysis time and is commonly included. The key section to note is the ridf block.

Key Parameters

Unspecified parameters use default values. Parameters inherited from art::TProcessor are common to all processors.

Processing with art::TRIDFEventStore

The objects processed by this processor are difficult to handle directly. It is common to set OutputTransparency to 1, meaning the objects will not be saved to a ROOT file.

To understand what is produced, you can set OutputTransparency to 0 to examine the output.

artlogin <username>
a

artemis [] add steering/hoge.yaml NAME=xxxx NUM=xxxx
artemis [] res
artemis [] sus
artemis [] fcd 0
artemis [] br

For detailed commands, refer to the Artemis Commands section.

Example output:

segdata              art::TSegmentedData
eventheader          art::TEventHeader

The eventheader is always output, while segdata is produced when OutputTransparency is set to 0. Key data is contained in segdata. Further details are covered in subsequent sections.

Using art::TMappingProcessor for Data Mapping

Raw RIDF files do not inherently indicate detector associations or processing rules. Use mapping files, as explained in the previous section, to map the data.

Example steering file:

Processor:
  - name: timer
    type: art::TTimerProcessor

  - name: ridf
    type: art::TRIDFEventStore
    parameter:
      OutputTransparency: 1
      Verbose: 1
      MaxEventNum: 100000
      SHMID: 0
      InputFiles:
        - *input

  - name: mapper
    type: art::TMappingProcessor
    parameter:
      OutputTransparency: 1
      MapConfig: mapper.conf

  - name: outputtree
    type: art::TOutputTreeProcessor
    parameter:
      FileName:
        - *output

Key Parameters

This parameter allows custom mappings, such as focusing on specific data during standard analyses. Use an alternative mapper.conf in another directory and specify its path when needed.

Processing with art::TMappingProcessor

The outputs of this processor are also hard to use directly, so OutputTransparency is typically set to 1. To examine what is produced, set it to 0 and observe the output.

artlogin <username>
a

artemis [] add steering/hoge.yaml NAME=xxxx NUM=xxxx
artemis [] res
artemis [] sus
artemis [] fcd 0
artemis [] br

Example output:

segdata              art::TSegmentedData
eventheader          art::TEventHeader
catdata              art::TCategorizedData

A new branch, catdata, is created. It categorizes data from segdata and serves as the basis for detector-specific analyses.

Workflow Diagram

flowchart LR
    A("**RIDF data files**") --> B("<u>**art::TRIDFEventStore**</u><br>input: RIDF files<br>output: segdata")
    B --> C("<u>**art::TMappingProcessor**</u><br>input: segdata<br>output: catdata")
    C --> D("**<u>Mapping Processor</u>**<br>input: catdata<br>output: hoge")
    D --> E("**<u>Other Processors</u>**<br>input: hoge<br>output: fuga")
    C --> F("**<u>Mapping Processor</u>**<br>input: catdata<br>output: foo")
    F --> G("**<u>Other Processors</u>**<br>input: foo<br>output: bar")

Both segdata and catdata are typically set to OutputTransparency: 1 and processed internally. Understanding these objects is essential for mastering subsequent analyses.