Some Comments on the Flagging Tool

1.1 Data Selection

1. Can selection be done on the basis of data description indices or
   are these for internal use only ? I am particularly concerned about
   the relationship between calibration descriptors, data descriptors,
   and / or spectral window / polarization descriptors because currently
   the pipeline heuristics groups uses information in the gain tables to
   flag and these relationships are a bit unclear.

2. Given that the setdata / setspectral method parameters are optional
   and effectively default to "all", the main reasons for separating
   the two are: 1) use cases which require fixing the parameters of one
   method while altering the other, 2) interface consistency across tools.
   1 may not be important for flagging(?), but may be in other tools
   such as display? All other things being equal it would be very nice
   if the data selection could be uniform across tools.

3. What values are spwNames likely to take?

4. One thing that would be quite useful with respect to data selection is
   to be able to either: 1) get some sort of status return from the selection,
   for example the number of measurement set rows selected which may be
   0 for an empty selection, or 2) a different version of the method which
   does this. I am sure there are efficiency issues here, especially if all
   setdata actually does is set up iterators, but at present there seems to
   be no clean way to check the result of the selection until some other
   processing step is taken and an error generated.

1.2 Manual Flagging

1. fieldNames do not seem to be include in the setmanualflags parameter set.
   Does setfield mean set fieldId or fieldName.

2. I like the option of retaining separate methods and don't see any
   reason why they cannot accumulate like setmanualflags.

3. What is the main i/o loop through the data? Is it field and spectral
   window (or data description) as it was in autoflag ?

1.3 Algorithms

1. Some of the ALMA pipeline heuristics algorithms should be included. This
   may be required for efficiency reasons if nothing else. Which ones are TBD?

2. What is the main i/o loop through the data? Is it field and spectral
   window (or data description) as it was in autoflag ? It would
   be very useful if these i/o loops could be designed in such a
   way that new algorithms could share the i/o loops. Don't know
   how feasible this is ...

1.4 Flagging Summaries / Statistics

1. Percentage of data flagged by field would also be useful. For example
I might like to know if any antennas have been completely flagged in the
flux calibrator.

2. The results also need to go to a useful structure (like image statistics).
It looks like 1.4.3 provides useful related but not identical functionality.

3. It would be useful to be able to select flags by a flagging code
at some point, e.g. separate on-line from processing flags etc.

4. As a function of time or a time range like parameter ?

1.4.2 Queries

1. These would be very useful but fieldname should also be a query

2. If these results are lists it looks like it would be easy to
parse them inside software which could be quite useful.

-- JosephMcMullin - 03 Jan 2007
Topic revision: r1 - 2007-01-03, JosephMcMullin
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding NRAO Public Wiki? Send feedback