Each group should maintain their own list of IOCs in (a) separate file(s). The filename should start with the group's short name (e.g. rf.sources, llrf.sources). A group might maintain more than 1 file. In this case all files should start with the groups short name followed by an underscore and then the rest of the name. The suffix should always be .sources (e.g. llrf.sources, llrf_group1.sources, ...).

Sources files might contain comments like /* my comment */ which are not interpreted.

The JSON structure is defined as follows:

{
    "sources": [{
        /* IOC using default port 9999 */
        "stream": "tcp://sf-ioc-xyz.psi.ch:9999"
    }, {
        /* IOC using non default port 20000 */
        "stream": "tcp://sf-ioc-abc.psi.ch:20000"
    }]
}

Explanation

sources: List of all IOCs/sources defined in this file.
stream: The IOC/source to be recorded (tcp://<hostname>:<port> - the default bsread port is 9999).

Data Policies

Policies files are JSON formatted text files defining the data reduction scheme to be applied to data points and are stored in the policies folder. Matching policies to data points is done using regular expressions applied to channel names (see: Pattern, more precisely using Matcher.find()) whereas longer match groups are considered superior to shorter match groups (i.e., pattern 'TRFCB-XY.' matches channel name 'TRFCB-XYZ' better than pattern 'TRFCB.'). In case several files define the same pattern, the one defined in the first file (given by the natural ordering of the file system) will be used.

The default data policy is defined in default.policies and is applied to every data point unless there is a data policy providing a superior match. Currently, the default retention time is one day.

Each group should maintain their own list of data policies in (a) separate file(s). The filename should start with the groups short name (e.g. rf.policies, llrf.policies). A group might maintain more than 1 file. In this case all files should start with the groups short name followed by an underscore and then the rest of the name. The suffix should always be .policies (e.g. llrf.policies, llrf_group1.policies, ...).

Policies files might contain comments like /* my comment */ which are not interpreted.

The JSON structure is defined as follows:

{
    "policies": [{
        "channel": "^SINDG01.*",
        "data_reduction": {
            "default": [{
                "ttl": "P1D",
                "modulo": 1
            }],
            "scalar": [{
                "ttl": "P2D",
                "modulo": 1
            }, {
                "ttl": "P7D",
                "modulo": 100
            }]
        }
    }]
}

Explanation

policies: List of all data policies defined in this file.
channel: The regular expression applied to channel names. Longer match groups are considered superior to shorter match groups (i.e., Pattern '^SINDG01.AMPLT$' matches channel name 'SINDG01-RCIR-PUP10:SIG-AMPLT' better than Pattern '^SINDG01.'). It is also possible to define a channel specific policy using the exact channel name.
data_reduction: The data reduction applied to the channels matching the above regular expression. This section can contain objects default (this reduction scheme is applied to all data points unless a more specific is defined), scalar (this reduction scheme is applied to scalar data points overwriting the default scheme), waveform (this reduction scheme is applied to waveform data points overwriting the default scheme), and image (this reduction scheme is applied to image data points overwriting the default scheme).
ttl: The time-to-live of the data point (after that time the data point will be deleted). The ttl is defined as a ISO-8601 duration (e.g., PT6H for 6 hours, P2D for 2 days etc.). Using a ttl of -1 will disable recording of channels matching the above pattern. The resolution is in seconds and thus the minimal ttl is 1 second.
modulo: Defines the x-th data point (based on the pulse-id) the ttl should be applied to (e.g., modulo 1: the ttl is applied to every data point, modulo 10: the ttl is applied to ever 10th data point, modulo 100: the ttl is applied to ever 100th data point). It is always the maximum ttl applied (pulse-id 1000 matches modulo 1 and 100 and thus "P7D" would be applied).
offset: (default: 0) Can be used to define an offset in the pulse-id match (e.g. modulo: 10, offset: 0 matches pulse-ids 0,10,20... whereas modulo: 10, offset: 2 matches pulse-ids 2,12,22...

Examples

Example 1

Group XYZ defines there default data policy for SINDG01 to be 2 days.

{
   "channel":"^SINDG01.*",
   "data_reduction":{
      "default":[
         {
            "ttl":"P2D",
            "modulo":1
         }
      ]
   }
}

All data points (scalar, waveform, image) of channels starting with SINDG01 (^ defines 'start with' in regex) have a ttl of 2 days.

Example 2

Lets assume group XYZ wants to track a problem in SINDG01 and therefore they want to keep waveforms for 3 days giving them time to analyze the problem.

{
   "channel":"^SINDG01.*",
   "data_reduction":{
      "waveform":[
         {
            "ttl":"P3D",
            "modulo":1
         }
      ],
      "default":[
         {
            "ttl":"P2D",
            "modulo":1
         }
      ]
   }
}

All waveform data points of channels starting with SINDG01 have a ttl of 3 days. All other data points (scalar, image) have a ttl of 2 days.

Example 3

Lets assume group XYZ was not able to track down the problem using data worth of 3 days. Therefore they decide to extend the time horizon to 10 days but realize there is not enough storage space available. However, they are confident to find the problem with every 100th data point.

{
   "channel":"^SINDG01.*",
   "data_reduction":{
      "waveform":[
         {
            "ttl":"P2D",
            "modulo":1
         },
         {
            "ttl":"P10D",
            "modulo":100
         }
      ],
      "default":[
         {
            "ttl":"P2D",
            "modulo":1
         }
      ]
   }
}

The default ttl of waveform data points of channels starting with SINDG01 is 2 days and every 100th of these data points has a ttl of 10 days. All other data points (scalar, image) have a ttl of 2 days.

Example 4

Lets assume group XYZ could solve the problem and (as exemplary DAQ users) decide to release the additional storage space for other DAQ users. However, they still want to track every 1000th scalar data point of channels starting with SINDG01 and having AMPL in their name for 10 days (as they provide enough information to verify that the problem did not re-appear).

{
   "channel":"^SINDG01.*",
   "data_reduction":{
      "default":[
         {
            "ttl":"P2D",
            "modulo":1
         }
      ]
   }
}

{
   "channel":"^SINDG01.*AMPL.*",
   "data_reduction":{
      "scalar":[
         {
            "ttl":"P2D",
            "modulo":1
         },
         {
            "ttl":"P10D",
            "modulo":1000
         }
      ],
      "default":[
         {
            "ttl":"P2D",
            "modulo":1
         }
      ]
   }
}

The default ttl for data points of channels starting with SINDG01 is 2 days. All scalar data points staring with SINDG01 and having AMPL in their name have a ttl of 2 days and ever 1000th of these data points has a ttl of 10 days.