CASA Modification Request 12C108, November 2007
Gaincal is the main calibration/self calibration task and will be heavily used. Some additional capabilities are suggested:
Three additions should be considered in the near future.
Are GSPLINE solution-types really needed? Is so, there need to be several improvements: a) The solutions must be plotable to compare with the normal G solutions. b) The solutions can have large edge effects (near the beginning or end of the time period). c) It needs the flexibility of the G or T options (ap, a, p solutions). d) It is unclear how GSPLINE behaves in low SNR situations and must be tested and compared with G solutions.
At present a G-solution cannot be made for more than one spectral window at a time. This is a serious lack. For example, when dealing with weak calibrator sources (a certainty for many ALMA observations) in the presence of large phase changes, all relevant data over all spectral windows should be used in a coherent manner to obtain the best calibration. The phase 'offset' between spectral windows and perhaps solving for delay instead of phase are considerations of this type of solution.
The Fring-fit solution, fringecal, must be made into an antenna-based program. There is some overlap with the multi-spectral window solution if group delays are also determined. This is the software piece missing from casa for its use with VLBI data.
Because the data for each spectral window is in a separate row in the casa ms, it is somewhat inconvenient to use some or all of the spectral windows in order to obtain one temporal solutions, especially for the phase.
5. Deployment Checklist
6. Test Plan
6.1 Internal Testing
6.3 Integration/Regression Tests
6.4 Testing for Scientific Validity
: I acknowledge that my request is fully contained in this MR, and if the CASA development group delivers exactly what I specified, I will be happy.
: I acknowledge that I have validated the completed code according to the acceptance tests, and I am happy with the results.
|| - - - - -
|| - - - - -
| Approved by Scientific Sponsor
|| - - - - -
| Accepted/Delivered by Sponsor
|| - - - - -
%X% if MR is not complete (will display )
%Y% if MR iscomplete (will display )
- 30 Oct 2007
- 06 Nov 2007
1. GSPLINE plotting is already available.
2. GSPLINE already supports a,p,ap modes (amp-only, phase-only, and amp/phase). What is needed is a "TSPLINE" option to enable a polarization-independent (non-dispersive troposphere) mode that combines RR and LL for the solve. This should be easy to do.
3. I interpret the multi-spw solving mode to be the main concern in this request. This is also the most substantial bit work to be done here (see item 5 below).
4. I think the generalized fringecal work should be described in a separate MR, and defered to a later release. Full fringe-fitting will be a separate task from gaincal, and a much more involved effort. The delay-solve/apply mode in gaincal will be much simpler than traditional fringe-fitting and will be an early application of the multi-spw mode of gaincal.
5. Re spws in separate MS rows: Actually, this really isn't a problem, and there are a variety of good reasons to avoid making spw an axis in the data array (not least variation in the number of spws with time, and maintaining robust timestamps for data with spw-dependent flagging, etc.). The data selection and iteration mechanisms make it possible to traverse the dataset in an effective way for this purpose (the multiple spws need not even be approximately co-located in the physical dataset, in fact); the data handling in the solver merely needs some improvements to permit digesting multiple chunks of data which differ in spw. Note that this generic approach also naturally supports combining multiple fields into a single solution. Really, the more important question here is how such solutions should be labeled according to spw (or field) in the cal table. E.g., should the common solution be duplicated for each spw (field) from which it was determined, should the spw (field) label for such solutions assume a special value that is not specific (e.g., spw=-1), should array indices be possble, or should the solution adopt a spw (field) index from one (e.g., the first one, or most highly weighted one) of the input spws (fields)? The first option, while likely fool-proof in downstream processing, is undesirable since it will tend to bloat the cal tables. I tend to favor the last option (along with use of spwmap) as it is simpler than the array id option and yet provides a more useful means of identifying and distinguishing solutions than dropping spw (field) info labelling altogether. On the other hand, the array id option amounts to packaging the nominal spwmap in the caltable
- 09 Jan 2008