You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

The overall goal of the VLA QA criteria is to create a 'fast' vs. 'slow' lane dichotomy. In this scenario, fast could go through to accept and archive without needed to look at specific stages, while slow lane would go through the standard, in-depth weblog review that has typically accompianied the 'SRDP treatment' of VLA EBs. Precise QA scoring is not necessarily required, but could be helpful, in general anything that triggers slow lane should make the score drop below 0.5.

  1. hifv_importdata
    1. Include a plot of the API data during the observation
      1. if API or wind missing or out of spec, trigger slow lane
    2. Check for missing scans
      1. always look at
    3. If flux.csv is used, always triggers slow lane
  2. hifv_hanning
    1. simple QA, it either worked or didn't; automatic score of 0 if hanning smooth didn't work for some reason
  3. hifv_flagdata
    1. if a flag template use, always triggers low land
    2. look for endtime = 0 in flag.xml (can pipeline do this?)
      1. look for '1858/' in online flags - trigger slow lane
    3. clipping > 1% with spectral line windows
    4. clipping > 5% with only continuum windows
    5. total flagging >30% 
  4. hifv_setjy
    1. QA score of zero if no flux calibrator intent or non-standard flux calibrator
  • No labels