...
- DA is notified by email when there is a new image dataset to review. The Operations Manager will assign for review (for now). The data are in /lustre/naasc/web/almapipe/pipeline/vaprodnaasc-prod/image-qa. Note: operations manager will still need to check the processing area for stalled or failed jobs. The initiator of any such jobs can be found in spool/<jobid>/metadata.json for contact by Helpdesk email if needed.
- login as almapipe (ssh almapipe@localhost or almapipe@<your desktop>, use the ssh key), set the appropriate environment (type activate_profile naasc-prod on the command line).
- QA: in the pilot, only channel widths and ranges can be set, so QA should be focused on those, along with general QA issues (note that firefox (to browse the weblog), casa and casaviewer are not in the default path for almapipe, they live in /opt/local/bin, so need to be invoked as e.g. /opt/local/bin/firefox, /opt/local/bin/casaviewer):
- Was the restoration of the calibration successful?
- Is the continuum subtraction satisfactory (hif_findcont task)? If not, DA should
pick a new continuum range by editing cont.dat and removing findcont from the PPR, then rerun (step34 below), orconsult with an SRDP Scientist if it is not clear how best to do thisDoes the rms noise in a line-free cube channel match the theoretical estimate from the hif_makeimages step in the pipeline (to within 10% above the theoretical estimate for bands 3-6, 15% for bands 7-8 and 20% for bands 9-10; but is no more than 20% better than the estimate)? If outside these ranges, DA should perform a limited investigation: - Check the original QA2 report in AQUA to see if any problems were reported there.
- In cases of dynamic range limits, is the dynamic range >200 (50 for 7m data)? If so the product may be marked as a QA pass, but the DA should note in the QA report that the user should attempt self-calibration.
- If there is bad target data, the DA should flag the bad data and rerun the PPR using the pipeline rerun script supplied by SSA.
- Are there artifacts in the image suggesting that target flagging is needed? If so, flag the data and rerun the PPR using the pipeline rerun script supplied by SSA (see Step 3 below).
- Does the cube as made cover seem to likely to have covered the region of interest requested by the PI (in the PPR)? If large parts of the cube are blank, and/or a line is cut off at the edge of the cube the DA should consult with a scientist.
- Is the synthesized beam highly elliptical? (Axial ratio > 3:1). If so, check that this is not due to heavy flagging of the target. If flagging is the cause (and not the observing HA and Dec), consult with a scientist as to whether or not the job should fail QA.
- Is the synthesized beam sufficiently well-sampled (>3 pixels across the minor axis)? If not, DA should rerun with a smaller pixel scale (and image size in pixels adjusted to image the same area) using the pipeline rerun script supplied by SSA.
- Check that the continuum images look sensible, compare theoretical to achieved RMS and note in the QA report (step 47) if any are dynamic range limited.
- If the user has requested a non-default angular resolution, then the imageprecheck task (stage 3 in the weblog) will indicate the approximate requested beam size and the last two lines of the table in the stage 3 weblog will report the taper used (if any) and the expected beamsize of the product (the task itself may show a fail until the score heuristics are updated, this can be ignored). The achieved beam size in the final product should be checked against the values in imageprecheck (it need not be exactly the same, but should be within ~20%).
- If the image failed QA, briefly give a reason.
- Note any target flagging (on the level of antennas/spw).
- Note any change to the continuum range(s).
- Add any other comments (e.g. if the image is dynamic range limited and self calibration is recommended).