Configuring the Script

The vis-receive script can be configured through the following Processing Block parameters, all of which can be omitted:

`vis-receive` Processing Block parameters
Name	Description	Default
`port_start`	The first port each receiver will open to listen for data.	`21000`
`channels_per_port`	Number of frequency channels that will be sent to each port.	`1`
`processes_per_node`	Number of processes to start per node, useful if CPU usage becomes a problem.	`1`
`max_ports_per_node`	Maximum number of ports to assign to a node before allocating a new one.	`null` *
`num_nodes`	Number of nodes to allocate.	`null` *
`transport_protocol`	The transport protocol the receiver should use (`"tcp"` or `"udp"`).	`"udp"`
`processors`	List of processors to start together with the receiver itself.	`{"mswriter": {}}`
`pod_settings`	Extra per-pod settings.	`[]`
`queue_connector_configuration`	Configuration passed to Queue Connectors. See SKA LMC Queue Connector Tango Device.	`{}`
`use_network_definition`	When set override the `extraMetadata` for `pod_settings` from network definition in SDP etcd.	`False`
`extra_helm_values`	Extra Helm values for the vis-receive Helm Chart. Use with care.	`{}`

* max_ports_per_node and num_nodes are mutually exclusive. If both are missing then num_nodes is defaulted to 1. * use_network_definition Note: when True this will override extraMetadata in pod_settings.

An example set of parameters can be found here.

Processors

The processors parameter is a dictionary with processor specifications. The keys in the dictionary are a simple name of the processor, while the value is a dictionary with a container-like specification as understood by the vis-receive Helm Chart.

This script comes with built-in processor definitions, which are defined as files under the [processors subdirectory](processors/):

mswriter: takes incoming visibility data and writes it into a Measurement Set.
rcal: performs gain calibration on incoming visibility data.
signal-display-metrics-all: takes incoming visibility data and calculates all available Signal Display metrics, which are then published to the SDP data queues.
signal-display-metrics-basic: takes incoming visibility data and calculates basic and fast Signal Display metrics, which are then published to the SDP data queues.
signal-display-metrics-amplitude: takes incoming visibility data and calculates Amplitude vs Frequency Signal Display metrics, which are then published to the SDP data queues.
signal-display-metrics-phase: takes incoming visibility data and calculates Phase vs Frequency Signal Display metrics, which are then published to the SDP data queues.

If a key in the processors dictionary refers to one of the built-in processor definitions, then the corresponding value is used to override the built-in definition; otherwise the value must fully define a processor.

Previously the processors parameter was a list where elements were either the (string) name of a built-in processor, or a dictionary with a full processor description. For backwards compatibility this is still supported, but deprecated. Simple names are translated to name: {} entries, while full processor descriptions are translated to description["name"]: description entries.

Examples:

Only use built-in mswriter processor, with its default settings:
```
mswriter: {}
```

Use the built-in mswriter processor, with its default settings, plus a processor called my-signal-display-metrics, which is described in full:

mswriter: {}
my-signal-display-metrics:
  name: my-signal-display-metrics
  image: artefact.skao.int/ska-sdp-qa-metric-generator
  version: 0.20.0
  command:
  - plasma-processor
  - ska_sdp_qa_metric_generator.plasma_to_metrics.SignalDisplayMetrics
  - --readiness-file
  - /tmp/processor_ready
  - --use-sdp-metadata
  - False
  - --metrics
  - all
  readinessProbe:
  - initialDelaySeconds: 5
    periodSeconds: 5
    exec:
      command:
      - cat
      - /tmp/processor_ready

Use a different version of the built-in mswriter and rcal processors:
```
mswriter:
  version: 1.2.3
rcal:
  version: 2.3.4
```

Old style processors parameter (deprecated):

- mswriter
- name: my-processor
  image: my-image

translates to

mswriter: {}
my-processor:
  name: my-processor
  image: my-image

Pod settings

The pod_settings parameter is a list of per-pod settings. This is currently needed to perform certain actions that cannot be yet automated, like pinning pods to specific nodes, or configuring access to the host’s network interfaces.

Each element in this list, if given, contains the following parameters (all are optional):

`vis-receive` `pod_settings` parameter options
Name	Description	Default
`networkMapping.name`	Name of the NetworkAttachmentDefinition used to setup the pod’ networking.	`null`
`networkMapping.namespace`	The namespace where the NetworkAttachmentDefinition is defined.	`null`
`networkMapping.deviceID`	The PCI ID of the network interface in the host machine (used with Multus).	`null`
`networkMapping.ip`	The IP to assign to the network interface.	`null`
`nodeSelector`	Dictionary used to select which node should run the pod.	`null`