Background: DSS
Observations on the GBT are scheduled using the Dynamic Scheduling System (DSS). GBT observations are heavily affected by weather, among other factors. So, in order to maximize efficiency, GBT observations are scheduled only 24-48 hours in advance. The schedule consists of a series of Periods: contiguous blocks of time that a given set of Receivers are being used to observe a portion of a given Proposal. The public schedule can be viewed here.
The DSS is currently the sole source of information for the GBT Data Sender.
Note that while each scheduled Period DSS is linked to an explicit set of Receivers, observers are not technically constrained to that set: they can observe using any available Receiver.
To learn more about the DSS, see the wiki
The GBO ODS Exporter
The relevant component of the DSS is a web application named nell, which is written in Python using the Django web framework. The Exporter is implemented as a Django management command, ods_export.py . It runs via a cron job, once every 5 minutes. The flow is quite simple:
- Check NRAO ODS to see if there is already data for the next-scheduled Period. If so, bail out
- Inspect the next-scheduled Period for the relevant values
- Send values to ODS API via HTTP POST
DSS Information
For a given looktime defined as now + 30 minutes, we first identify the observing period (look_period) and receiver (period_rx) which correspond to that time.
look_period = Period.objects.filter(start__gte=self.looktime).order_by("start").first()
period_rx = Period_Receiver.objects.filter(period=self.look_period.id).first()Site Data
The following information is sent as a JSON object to be a site_data entry in the OSS database.
| Key | Type | Value |
|---|---|---|
obs_id | string | look_period.session.name |
site_id | string | "gbt" |
site_lat_deg | float | 38.433129 |
site_lon_deg | float | -79.839839 |
site_el_m | float | 824.0 |
src_id | string | look_period.session.target.source |
src_ra_j2000_deg | float | look_period.session.target.vertical |
src_dec_j2000_deg | float | look_period.session.target.horizontal |
src_radius_deg | float | 0.0 |
trk_rate_ra_deg_per_sec | float | 0.0 |
trk_rate_dec_deg_per_sec | float | 0.0 |
freq_lower_hz | float | period_rx.receiver.freq_low * 1E9 |
freq_upper_hz | float | period_rx.receiver.freq_hi * 1E9 |
src_start_utc | timestamp | look_period.start |
src_end_utc | timestamp | look_period.start + look_period.duration |
status | string | look_period.state.name |
notes | string | look_period.session.observing_type.type |
Limitations
The current version of the GBO Data Sender has a few severe limitations.
The primary limitation is inherent to the current design: the DSS lacks the level of granularity needed to accurately reflect GBT position at a given time. There is only one location provided for a Period, but Periods can be many hours long, and the GBT is not actually restricted to any positional offset from this location value.
There are a few other limitations that could be resolved with slight modifications to the current script:
- The Period derivation has the potential to skip over a Period in the case where the next-scheduled Period is less than 30 minutes away when the Exporter runs
- The Exporter selects an arbitrary Receiver for the next-scheduled Period; it does not consider all Receivers