The following observing and processing polices will be applied to Cycle and DDT observations and pipelines. If you have any questions, please contact the Science Data Centre Operations group through the SDC-helpdesk which is hosted at https://support.astron.nl/sdchelpdesk
1) For snapshot observations, the total observing time that should be requested in the proposal should include the overhead time needed by the system to switch pointing. E.g. for an observing block made of 3 min on a calibrator and 10 min on the target repeated 8 times, the total observing time to be requested should be (3+1+10+1)*8 min = 120 min rather than 104 min.
2) In case of unavailable or malfunctioning stations, an observation will be performed or will be considered successful when:
A. it requests only the Superterp stations and no more than 1 station is missing
B. it requests only the Core Stations and no more than 4 stations are missing
C. it requests only the Dutch stations (CS+RS) and no more than 4 stations are missing
D. it requests Dutch (CS+RS) and international stations and no more than 4 Dutch and/or 2 international stations are missing
Note that in HBA_DUAL mode, HBA0 and HBA1 fields *do not* count as separate stations in this policy, i.e. if CS007HBA0 and CS0007HBA1 are unavailable, they together count as one station.
In all other cases, the observing run will proceed as planned and the final data will be subject to the acceptance criteria described in the following points. Note: if specific stations are necessary to achieve the scientific goals of a project, this should be explicitly mentioned in the proposal (proposal section 'Other Scheduling Constraints Requirement'). In such a case, observations for the project will not be performed unless the needed stations are available.
3) In the case of malfunctioning stations or CEP nodes, an observation will be considered failed if more than 5% of the data are missing on disk. Processing will be considered failed if more than 5% of the resulting processed data are missing with respect to the raw visibilities. In other cases, observations may be considered failed on a case-by-case basis, in coordination with the PI or their representatives, and according to the science goals of the relevant proposal.
4) From the moment the data are made available to the users at the LTA they will have four weeks available to check the quality of their data and report problems to ASTRON (via https://support.astron.nl/sdchelpdesk). After this time window has passed, no requests for re-observation will be considered.
5) In the case that an observation (whether priority A or B) is considered failed, it may be repeated only once if the observing schedule allows it. If the repeated observation is unsuccessful, no further repeats are possible. In this case, a new proposal will need to be submitted for the following semester(s). Failed processing pipelines may also be repeated only once. If this repeat also fails for the same data, the raw data may be made available to the PI or representatives through the LTA.
6) An observation is repeated only if considered failed. In this case, the original data are not processed and will not be ingested.
7) Postponement of observations to the following Cycle:
8) In the case of regularly-timed observations, composed of blocks of multiple sub-runs to be performed on a regular basis, SDC Operations will try to repeat a failed sub-run only if the schedule allows it. If this is not possible or if the same sub-run fails, observations will resume with the next regular sub-run.
9) Observations interrupted by a trigger are planned again in the schedule as soon as the opportunity arises and still based on scientific ranking. The interruption is not considered a failure and the new scheduled run will not be targeted as a repetition. Note: if any of the data collected before the interruption can be used by the PI, these would be made available to the PI and only the remainder of the observing run would be re-scheduled.
10) The only raw data inspection available to users prior to data reduction is via the inspection plots which are created automatically immediately after the associated observation has finished.
11) Users are not permitted to decide the data reduction strategy on the basis of inspection of the raw visibilities once an observation has taken place. The full data reduction strategy, including the list of any sources to be demixed must be communicated to the SDC Operations (via https://support.astron.nl/sdchelpdesk) in good time prior to the observation taking place. Users who might not be familiar with a given field can simulate the target visibilities and the influence of the A-team sources in them by following the procedure described in the LOFAR Imaging Cookbook.
12) Once observing or processing are completed, the raw (if requested in the proposal) or processed data will be made available to the PI or their representatives through the LTA. In case the PI has been awarded access to CEP3 for further data processing for the default period of 8 weeks, he/she will have to independently upload the data from the LTA into CEP3.
13) Data retrieval from the LTA into the CEP3 system is not supported by ASTRON.
1) For snapshot observations, the total observing time that should be requested in the proposal should include the overhead time needed by the system to switch pointing. E.g. for an observing block made of 3 min on a calibrator and 10 min on the target repeated 8 times, the total observing tiem to be requested should be (3+1+10+1)*8 min = 120 min rather than 104 min.
2) In case of unavailable or malfunctioning stations, an observation will be performed or will be cosidered successful when:
A. it requests only the Superterp stations and no more than 1 station is missing
B. it requests only the Core Stations and no more than 4 stations are missing
C. it requests only the Dutch stations (CR+RS) and no more than 4 stations are missing
D. it requests Dutch (CS+RS) and international stations and no more than 4 Dutch and/or 2 international stations are missing
Note that in HBA_DUAL mode, HBA0 and HBA1 fields *do not* count as separate stations in this policy, i.e. if CS007HBA0 and CS0007HBA1 are unavailable, they together count as one station.
In all other cases, the observing run will proceed as planned and the final data will be subject to the acceptance criteria described in the following points. Note: if specific stations are necessary to achieve the scientific goals of a project, this should be explicitly mentioned in the proposal (proposal section 'Other Scheduling Constraints Requirement'). In such a case, observations for the project will not be performed unless the needed stations are available.
3) A planned observation will not be performed only if more that 5% of the stations requested in the proposal are not available. In all other cases, the observing run will proceed as planned and the final data will be subject to the acceptance criteria described in the following points. Note: if specific stations are necessary to achieve the scientific goals of a project, this should be explicitly mentioned in the proposal. In such a case, observations for the project will not be performed unless the needed stations are available.
4) In the case of malfunctioning stations or CEP nodes, an observation will be considered failed if:
A. Data for more than 5% of the beams are missing on disk.
B. More than 5% of the raw data are zero-padded.
C. Data from more than 5% of the subbands are missing on disk: a subband is considered missing if any of the requested Stokes parameters for that subband are missing.
D. Interference from oscillating tiles or other sources leads to failure in processing.
E. More than 5% of the processed data are missing with respect to the raw data.
In other cases, observations may be considered failed on a case-by-case basis, in coordination with the PI or their representatives, and according to the science goals of the relevant proposal.
One special case are the LOTAAS observations (LT5_004). Here it was agreed that an observation is failed/will not run if A) one superterp station is missing. B) 12 beams or more are considered failed. A beam is considered failed if it is not there or if the dataloss/zero padding is more than 2.5%. (This corresponds to a filesize on disk of less than 72360 MB, or in the inspection plots of less than 70604 MB)
5) From the moment the data are made available to the users at the LTA a period of four weeks is available to check the quality of their data and report problems to the Observatory. After this time window has passed, no requests for reobservation will be considered.
6) In the case that an observation (whether priority A or B) is considered failed, it may be repeated only once if the observing schedule allows it. If the repeated observation is unsuccessful, no further repeats are possible. In this case, a new proposal will need to be submitted for the following semester(s). Failed processing pipelines may also be repeated only once. If this repeat also fails for the same data, the raw data may be made available to the PI or representatives through the LTA.
7) An observation is repeated only if considered failed. In this case, the original data are not processed and will not be ingested.
8) Postponement of observations to the following Cycle:
9) In the case of regularly-timed observations, composed of blocks of multiple sub-runs to be performed on a regular basis, Science Operations and Support will try to repeat a failed sub-run only if the schedule allows it. If this is not possible or if the same sub-run fails, observations will resume with the next regular sub-run.
10) Observations interrupted by a trigger are planned again in the schedule as soon as the opportunity arises and still based on scientific ranking. The interruption is not considered a failure and the new scheduled run will not be targeted as a repetition. Note: if any of the data collected before the interruption can be used by the PI, these would be made available to the PI and only the remainder of the observing run would be re-scheduled.
11) The only raw data inspection available to users prior to data reduction is via the inspection web page which is created automatically immediately after the associated observation has finished.
12) Users are not permitted to decide the data reduction strategy on the basis of inspection of the raw data once an observation has taken place. The full data reduction strategy including optional pipeline parameters must be communicated to SDC Operations in good time prior to the observation taking place.
13) Once observing or processing are completed, the raw (if requested in the proposal) or processed data will be made available to the PI or their representatives through the LTA. In case the PI has been awarded access to CEP3 for further data processing for the default period of 8 weeks, he/she will have to independently upload the data from the LTA into CEP3.
14) Data retrieval from the LTA into the CEP3 system is not supported by ASTRON.
LOFAR's CEP4 cluster is the main production computing resource. It is used to record observations, perform standard processing and test production software.
Access and use of CEP4 is under the sole control of the Science Data Centre Operations (SDCO) group. Access of Users can only be granted in exceptional circumstances with the discretion of the SDCO group.
Users should conform with the access, resource allocation and data deletion policies issued by the SDCO at all times.
Observing and processing time (and hence the use of the appropriate resources of CEP4) is allocated by the LOFAR Programme Committee and the ILT director during the regular proposal evaluation stages, or under Director's Discretionary Time.
Observed data from the online correlator (COBALT) are recorded to CEP4 disks. The SDC Operations group verifies the completion of the observing runs and points the Contact person of each observation to quality diagnostic plots. As approved, processing pipelines are scheduled to run after the observations. The SDC Operations then moves the products that have been approved by the LOFAR PC and the ILT Director to the Long Term Archive and immediately removes them from CEP4.
In general, observed data will reside at the CEP4 disks after the completion of the associated pipelines only for the short interval until they are ingested to the LTA. The SDCO has the sole authority to archive and delete data from CEP4 according to the operations plan.
Users who will use the data for further analysis at other facilities, must retrieve these data from the Long Term Archive. Copy of data directly from the CEP4 cluster is prohibited.
Observing, CEP4 processing time and the use of CEP3 are allocated by the LOFAR Programme Committee and the ILT director during the regular proposal evaluation stages, or under Director's Discretionary Time. Therefore, users who need to use CEP3 to process their data should request CEP3 resources in the proposals.
Access and use of CEP3 is under the sole control of the Science Data Centre Operations (SDCO) group. Access for Users will be granted only at the discretion of the SDCO group. Users should conform to the access, resource allocation and data deletion policies issued by the SDCO at all times.
Users awarded with access to CEP3 will be able to access the cluster for a limited period of time (8 weeks by default). At the beginning of a Cycle, users can derive this timeline by checking the observing schedule, which is available here. Access timelines related to observing programs involving observations spread in time will be discussed between the PI and Science Data Centre Operations group. After the granted period on CEP3 has expired, all user's data products generated on the cluster will be automatically and promptly removed, to enable new users to have enough disk space to perform their data reduction.
Extension to the default 8-weeks period are granted only in *exceptional* circumstances and if properly justified by submitting a request through the SDC-helpdesk which is hosted at https://support.astron.nl/sdchelpdesk before the end of the granted period. Also, SDCO has started a monitoring campaign of node usage during the allocated default time. The evaluation of extension requests are also based on such statistics.
SEE ALSO: