Moellenbrock JIVE Visit (2019 Oct 11,14-16)
George visited JIVE after ADASS for ~4 days to discuss various issues in person with Mark, Des, and Ilse, and to overcome some of the inertia that had built up on items needing attention from George in the code. We also discussed some longer-term development topics. In addition to making some progress on specific issues (discussed below), we agreed that in-person discussion on at least an ~annual basis is a good idea and we should be sure to do it again next year at some point.
- Corr-dep flags (CAS-695). I expected to work on this, but ended up prioritizing discussions of other items, and exploring frequency meta-info issues. Action: (George) This remains a high-priority item for 5.7/6.1
- Solution frequency meta-info issues. Solutions from fringefit need unambiguous access to the fiducial frequency meta-info both when solving (to scale nominal solution units to delay and delay-rate units) and when applying (to calculate phase(t,f) from delay and delay-rate values). Current code is ambiguous about this, but essentially is (correctly) using the frequency meta-info stored in the cal table for the apply-side calculation (although older code that tried to calculate this on-the-fly has not yet been removed). A nominal calculation is performed on the solve side to provide the frequency value for the cal table, but is not readily accessible to the solve code itself. Action: (George: CAS-12735) I will streamline the frequency meta-info management in general, namely "refFreq_" --> "solnFreq_", as this is relevant to more than just fringefit (recent work on KJones revealed similar issues). Some associated improvements to internal semantics will also be made so code is clearer about whether various meta-info is describing the in-focus data (in solve and apply contexts) or the current solution values (e.g., see CAS-12553). Also, deprecated code to be cleaned out (e.g., KrefFreq_ and older mechanisms for local calculations of it).
- spwmap bug (CAS-12591). Ouch, spwmap is indeed being applied twice in CTPatchedInterp! Conventional use of this at ALMA/EVLA is avoiding catastrophe since usually the 2nd application is spwmap'd to itself. This breaks down when sharing caltables among MSs, which is the use case where this emerged at JIVE. Action: (George) Apply Mark's fix (from CAS-12591), and determine if this is also a problem in the cal library version of cal apply (CLPatchPanel); also generalization of the gaincal task unit test to exercise a broader range of non-trivial spwmap cases.
- GAINCURVE (CAS-8546). George and Mark discussed how to proceed; see comment (16/Oct/19) on CAS-8546 for details/actions.
- Conversion of AIPS CC list to CASA component list. Des provided his ad hoc python scripts to George. Action: (George) Explore converting scripts to a proper CASA task (discuss w/ Golap, as needed).
- Solved-for term selection in fringefit. In addition to selecting for/against the dispersive term, it should be possible to select for/against delay and rate terms, but not phase. Not sure we converged on a decision here (Des?).
- EOP. Current experimental emulation calculation by Mark creates a (time-dep) fringefit-style cal table. Agreed that a mechanism like antpos corrections or fixvis may be worth considering (i.e., an OTF calculation from stored parameters), but may be difficult to support vis-a-vis details associated with use of CALC by correlator (e.g., what subtle parts of the calculation need to be reproduced?). Mark's experiments with the calculation so far do not match existing implementations in AIPS. Action: (Mark) Discuss details with Brisken & Deller, then consider how to proceed.
- PCALs. Des (and Marti-Vidal) has ad hoc python scripts that derive a fringe-fit style cal table from PC table info. May need some additional attention w.r.t. ambiguity resolution. Urgency minimal in Europe (cf VLBA). Action: Need to poll VLBA to assess relative importance and desirable features before committing significant additional effort.
- Polarization Calibration. Discussed desirability of instrumental polarization solving support when calibrators are resolved, but also acknowledged interesting questions about sufficient sampling. Although making Ivan Marti-Vidal's ~ad hoc polsolve python script generally available to CASA users would be nice, it is important to be sure that it meshes well with the standard polarization formalism so as not to create a difficult user support burden on CASA (e.g., a novice users says: "I used polsolve and I don't understand why it doesn't seem to be working... Help!"). Action: (George) Discuss with Marti-Vidal a proper migration of his 'polsovle' python application into CASA's mainline polarization treatment.
- Overlapping solutions, orphaned integrations that don't completely fill a solution interval. Only briefly discussed; need some sort of circular buffer on the SolveDataBuffer time-axis within SDBList....