adampbeardsley
commented
5 years ago Some notes from discussion at CHAMP Camp
Danny's suggestions:
- how much power is on an antenna?
- is it crossed polarized?
- what is the system temp?
- What is the RFI env like?
- total number of flags, max hold, etc
Josh:
- chi^2 per antenna
- did everything run?
Need to define:
- thresholds for cutting data
- granularity of cuts
Cumulative QM
We want to have some level of cumulative QM, where we should the general trend over the season, or nominal values from a good day.
Data should be easy enough to keep around, need to decide where it lives, etc
From IDR2.2 memo:
- Is delay filter involved?
- Images:
- Danny, Paul, Tasha to figure out how to make movies or stripes of MFS images for daily observers to look at for anomalies (not clear how to turn this into a quantitative metric)
- Noise Estimation" block
- system temp
- Reflections:
- parameters. experimental, but is probably useful to have. maybe just look at autocorrelation delay transform
- smoothcal: don't currently have metrics.
- How well does smooth matched input?
- diff of raw vs smoothed.
- sometimes it fails - how do we know?
- XRFI:
- waterfall, total flags, max holds, etc
- missed RFI?
- report to SA: Bram Otto
- RIDS system/Dave Deboer. what needs to be included?
- Abscal/redcal
- chisq, chisq per antenna
- firstcal metrics? Nick doesn't think it's worth the space in the notebook right now
- antenna metrics
- big green box?
From daily observing modes
- noise diodes data
- phase switching
MC
- overall health of array
- ambient data (weather)
Currently, the analysis team has metrics for checking that a pipeline successfully finishes, but the assessment of the quality of the obtained solutions versus time, frequency, and antenna is done manually.
I think that we need to rope in HERA_QM (@adampbeardsley) to help analysis generate a summary of the pipeline run. For example, we could have notebooks that summarize various quality metrics integrated over various axes. These could answer questions like:
I'm sure there are more questions we could ask, but we need some sort of "design review" for an IDR that we can point to for assurance that the data set passes the sniff test. The running of these summary notebooks could be something that is tacked on at the end-stage of an analysis pipeline.