Page History

...

It is possible that an observing session failsresults in bad data. This can be either due to not matching the requirements specified in the tasks or due to external circumstances (e.g. observing conditions poor). This . It means that the data can't be accepted, so the corresponding flag needs to be set. It requires the FoP to:

• • Set the corresponding SU data acceptance flag to 

    Status
    colour Red title failedfalse

    (see procedure below). Warning: This should be done using the QA workflow interface, but a manual procedure using the TMSS API is also available.
    
  • Evaluate if repeating the failed observing session described by the failed SU is within the policy for the project (i.e. check priority and if the failed session was already a repetition)
  • If possible, add more tasks to the SU; to this aim new tasks can be added in a SU by using in the "Scheduling Unit - Details" menu and then clicking on the 'paper-and-pencil' icon next to the "Task Details" section. 
  • If possible repeat the process of specification and submission by generating a copy of the SU draft; to this aim copy the failed blueprint of the SU to a (renamed) draft SU and blueprint it. In this case, make sure that the new SU does not retain any fixed timeslot from the failed copy. Also, make sure that any archived data related to the failed SU to be removed from the LTA via opening a ticket in the Helpdesk (project users) or directly cleaning up the archive (for SDCO operators).
    

In order to set a SU data explicitly to

...

• • To confirm the change, we click the 'Patch' button at the bottom of the page.
  • Now, the SU data acceptance flag will be set to

    Status
    colour Red title failedfalse

    , and any related (also pinned) data to the SU will be deleted, or have to be deleted manually if the SU was set to failed prior steps were performed before the associated cleanup task has run.
  • If data were archived, an LTA cleanup action can be requested by project users via opening a ticket in the Helpdesk or directly performed by SDCO operators.
    

...

Each of the users / roles in the workflow steps can approve or disapprove of the data quality and enter an appropriate comment. The approval state is reflected by the state of a checkbox at the bottom of the page after all of the user roles have decided on the QA state. Then, the QA assessment is finished, and the PI has an overview of the procedure. The data is unpinned / deleted or archived depending on the QA outcome. The Data Accepted columnin the blueprint listing on the TMSS project view page will indicate whether data for a given executed SU blueprint is accepted or not (false).

Please note that SDCO is still using the Jira system for handling observation reports . After the observations and subsequent processing are completed, the PI and project users will be notified to complete the QA workflow via the Jira ticket associated to the project and the requested data products will be made available through the Long Term Archive (LTA) as soon as possiblecorresponding ticket.

The Radio Observatory will not have the opportunity to check all data manually before it is exported to the LTA, although some automatic diagnostics are generated for system monitoring, and offline technical monitoring will be carried out regularly. The FoP or the expert user in charge of project support will send to the project PI a notification after each observation with detailed information on where to find the relevant plots. The project team is encouraged to analyze the data, at least preliminarily, soon after the observations, and to get in touch through the ASTRON helpdesk about any possible problems. Observations that turn out to have an issue that makes them unusable may be considered for only one re-run, as soon as the observing schedule allows.

...