SDP assign resources 0.3
Example
{
"eb_id": "eb-mvp01-20210623-00000",
"max_length": 100.0,
"scan_types": [{
"scan_type_id": "science",
"reference_frame": "ICRS",
"ra": "02:42:40.771",
"dec": "-00:00:47.84",
"channels": [{
"count": 744,
"start": 0,
"stride": 2,
"freq_min": 350000000.0,
"freq_max": 368000000.0,
"link_map": [
[0, 0],
[200, 1],
[744, 2],
[944, 3]
]
}, {
"count": 744,
"start": 2000,
"stride": 1,
"freq_min": 360000000.0,
"freq_max": 368000000.0,
"link_map": [
[2000, 4],
[2200, 5]
]
}]
}, {
"scan_type_id": "calibration",
"reference_frame": "ICRS",
"ra": "12:29:06.699",
"dec": "02:03:08.598",
"channels": [{
"count": 744,
"start": 0,
"stride": 2,
"freq_min": 350000000.0,
"freq_max": 368000000.0,
"link_map": [
[0, 0],
[200, 1],
[744, 2],
[944, 3]
]
}, {
"count": 744,
"start": 2000,
"stride": 1,
"freq_min": 360000000.0,
"freq_max": 368000000.0,
"link_map": [
[2000, 4],
[2200, 5]
]
}]
}],
"processing_blocks": [{
"pb_id": "pb-mvp01-20210623-00000",
"workflow": {
"kind": "realtime",
"name": "vis_receive",
"version": "0.1.0"
},
"parameters": {}
}, {
"pb_id": "pb-mvp01-20210623-00001",
"workflow": {
"kind": "realtime",
"name": "test_realtime",
"version": "0.1.0"
},
"parameters": {}
}, {
"pb_id": "pb-mvp01-20210623-00002",
"workflow": {
"kind": "batch",
"name": "ical",
"version": "0.1.0"
},
"parameters": {},
"dependencies": [{
"pb_id": "pb-mvp01-20210623-00000",
"kind": ["visibilities"]
}]
}, {
"pb_id": "pb-mvp01-20210623-00003",
"workflow": {
"kind": "batch",
"name": "dpreb",
"version": "0.1.0"
},
"parameters": {},
"dependencies": [{
"pb_id": "pb-mvp01-20210623-00002",
"kind": ["calibration"]
}]
}]
}
Used for assigning resources to an SDP subarray.
As concrete resource usage for the SDP depend strongly on the underlying processing script, this fully parameterises all processing blocks to be executed. This especially means that in contrast to most other sub-systems, SDP processing deployments might persist across scans (and scan configuration) boundaries.
type |
object |
|
properties |
||
|
type |
string |
|
type |
string |
|
Execution block ID to associate with processing |
|
type |
string |
|
|
Hint about the maximum observation length to support by the SDP. Used for ensuring that enough buffer capacity is available to capture measurements. Resources assignment might fail if we do not have enough space to guarantee that all data could be captured. |
|
type |
number |
|
|
Scan types to be supported on subarray |
|
type |
array |
|
items |
A scan configuration for SDP. Once AssignResources has been performed successfully, subsequent Configure commands can select from these scan types in order to coordinate SDP with other sub-systems participating in the observation - for instance to switch between targets, or perform special calibration scans. |
|
|
type |
array |
items |
A Processing Block is an atomic unit of data processing for the purpose of SDP’s internal scheduler. Each PB references a processing script and together with the associated execution block provides all parameters necessary to carry out scheduling - both on TM’s side for observation planning and on SDP’s side - as well as enable processing to locate all required inputs once it is in progress. PBs are used for both real-time and deferred, batch, processing. An execution block will often contain many Processing Blocks, for example for ingest, self-calibration and Data Product preparation. |
|
additionalProperties |
True |
|
Scan_type_0.3
A scan configuration for SDP. Once AssignResources has been performed successfully, subsequent Configure commands can select from these scan types in order to coordinate SDP with other sub-systems participating in the observation - for instance to switch between targets, or perform special calibration scans.
type |
object |
|
properties |
||
|
type |
string |
|
Specification of the reference frame or system for a set of pointing coordinates (see ADR-49) |
|
type |
string |
|
|
Right Ascension in degrees (see ADR-49) |
|
type |
string |
|
|
Declination in degrees (see ADR-49) |
|
type |
string |
|
|
type |
array |
items |
Informs SDP ingest about the expected channel configuration, especially which frequencies are expected to be mapped to which channel ID. Note that channel IDs are not guaranteed to be continuous, so this might involve gaps and/or strides. |
|
additionalProperties |
True |
|
Scan_channels_0.3
Informs SDP ingest about the expected channel configuration, especially which frequencies are expected to be mapped to which channel ID. Note that channel IDs are not guaranteed to be continuous, so this might involve gaps and/or strides.
type |
object |
|
properties |
||
|
Number of channels |
|
type |
integer |
|
|
First channel ID |
|
type |
integer |
|
|
Distance between subsequent channel IDs |
|
type |
integer |
|
|
Lower bound of first channel |
|
type |
number |
|
|
Upper bound of last channel |
|
type |
number |
|
|
Channel map that specifies which network link is going to get used to send channels to SDP. Intended to allow SDP to optimise network and receive node configuration. |
|
type |
array |
|
items |
||
additionalProperties |
True |
|
Processing_block_0.3
A Processing Block is an atomic unit of data processing for the purpose of SDP’s internal scheduler. Each PB references a processing script and together with the associated execution block provides all parameters necessary to carry out scheduling - both on TM’s side for observation planning and on SDP’s side - as well as enable processing to locate all required inputs once it is in progress.
PBs are used for both real-time and deferred, batch, processing. An execution block will often contain many Processing Blocks, for example for ingest, self-calibration and Data Product preparation.
type |
object |
||||
properties |
|||||
|
Unique identifier for this processing block. |
||||
type |
string |
||||
|
Workflow 0.3 |
||||
Specification of the workflow to be executed. |
|||||
type |
object |
||||
properties |
|||||
|
The kind of processing script (realtime or batch) |
||||
type |
string |
||||
|
The name of the processing script |
||||
type |
string |
||||
|
Version of the processing script. Uses semantic versioning. |
||||
type |
string |
||||
additionalProperties |
True |
||||
|
Parameters needed to execute the workflow. As these parameters will be specific to the workflow, this is left as an object to be specified by the workflow definition. |
||||
type |
object |
||||
|
A dependency between processing blocks means that one processing block requires something from the other processing block to run - typically an intermediate Data Product. This generally means that
As processing blocks might have many different outputs, the dependency “kind” can be used to specify how this dependency is meant to be interpreted (e.g. “visibilities”, “calibration”…) |
||||
type |
array |
||||
items |
Processing block dependency 0.3 |
||||
type |
object |
||||
properties |
|||||
|
type |
string |
|||
|
type |
array |
|||
items |
type |
string |
|||
additionalProperties |
True |
||||
additionalProperties |
True |
||||