Figure 1: Diagram shows the three phases of the science project administration workflow (project preparation, project execution and project closure) along with the main steps. Actors and their responsibilities are indicated with the symbols. See table below for details.
Acronyms: SDCO - Science Data Center and Operations; TO - Telescope Operators; PC - Program Committee; SU - Scheduling Units; QA - Quality Assurance; TMSS - Telescope Manager System Specification; MoM - Management of Measurements
Process steps | SDCO | General user | User shared support mode |
Contact author is notified via Jira about the project preparation | SDCO will open a ticket in Jira to be used as the communication channel for the science project between the contact author and SDCO | The science project contact author will be responsible for providing any additional / missing info requested for the preparation of the observing campaign as well as for the acceptance of the delivered data. See here for instructions on how to use Jira. | |
User specification (via the proposal in NorthStar) is converted / imported into TMSS | SDCO will rely on the info gathered from the proposal as well as from the feedback given by the PC and technical teams | The expert user(s) will rely on the info gathered from the proposal as well as from the feedback given by the PC and technical teams | |
Check if any changes are needed to the proposed scheduling set; when ready the project status in TMSS is set to active | SDCO collect info for later reporting.
SDCO applies changes when needed if matching the allocated resources. SDCO/TO Change the status in TMSS |
The contact author will validate the specification in TMSS (follow the instructions in the section below) of the observing campaign and contact SDCO via the Jira ticket. | The expert user(s) will validate the specification in TMSS for the observing campaign and contact SDCO via the Jira ticket
SDCO/TO Change the status in TMSS |
The set of SU is approved for (dynamic) scheduling. | TO/SDCO Change of status in TMSS | TO/User Change the status in TMSS |
|
SU performed successfully & User accept data |
|
Contact author receives notification (email / Jira) and as soon as possible provide feedback (please find here some instructions on how to assess the data quality) |
|
SU successful & User does not accept data |
|
Contact author receives notification (email / Jira) and as soon as possible provides feedback. Note that rejection of data must happen within 4 weeks from the data delivery in the Long Term Archive (LTA) in order to apply for a repetition. |
|
SU failed |
|
Contact author receives notification (email / Jira). Note that in some cases the science team may find the data acceptable and in such cases should contact ASAP via Jira SDCO. |
|
Closure of the project: prio A all SU performed & successful | SDCO closes the Jira ticket and the changes the status in TMSS into finished and report | ||
Closure of the project: prio A part of SU performed successful | SDCO closes the Jira ticket and the changes the status in TMSS into suspended and report. | ||
Closure of the project: prio B part of SU leftover. | SDCO closes the Jira ticket and the changes the status in TMSS into finished and report. |
For the Shared-Support workflow as well as documentation for the day to day duties of the Shared-Support user, please see below.
Please consult the TMSS User Manual on how to specify the proposed observation by setting up the appropriate Scheduling Units and associated processing tasks for a given Project.
Data quality assessments for completed observations are performed to ensure the observations are acceptable within the LOFAR data policy. Before assessing the observations, ensure the observation cannot be considered failed (the criteria for a failed observation is outlined in the LOFAR data policy). If this is the case, the following assessment can be skipped and the procedure for failed observations described below should be followed.
The data quality assessment is done using a variety of tools that help assess the data at various stages along the data flow from the station. Most of the diagnostic tools are found on the inspection plot page of the observation here. To check the observations select the SAS ID of the observation for which you wish to inspect. A page will open, containing the following diagnostic information:
In case of a failed observation (the criteria for a failed observation is outlined in the LOFAR data policy), the expert-user must mark the failure on the google schedule, notify the SDCO team and report the failure:
After checking the observations using the steps above, the Data Quality Report needs to be written.
SEE ALSO: