Phase cal tone extraction is currently supported in the trunk of mpifxcorr. The latest versions of difxio (trunk), vex2difx (trunk) and difx2fits (trunk) should also now support pcal extraction.
Tone extraction is fully implemented in the 2.0 version of mpifxcorr and has been validated against the VLBA station-extracted tones. Phases agree to much better than one degree. Work is ongoing to validate these features. Further work is also required to ensure that 'PC' tables generated in this way work correctly with PCCOR in AIPS. This work is expected to be completed in time for DiFX-2.0.1. Until this time phase cal extraction is to be considered an experimental feature.
N.B. Although the pcal extraction code is in the tagged 2.0.0 version of mpifxcorr, the sign convention has changed. You must use the trunk version of mpifxcorr (along with the trunk version of difxio, vex2difx, and difx2fits) for pcal extraction!
This will be done automatically provided that pcal extraction is set up in the vex file (see below). All phase cal tones will be extracted in mpifxcorr with the same integration time as the visibilities unless explicitely overridden with phaseCalInt set to zero for each antenna in the .v2d file
difx2fits will write out the tones specified in the vex file to the FITS-IDI file.
difx2fits will then produce a 'PC' table based on the DiFX-extracted tones. If the VLBA station 'pcal' file is present the cable cal. values will be taken from this file. Care should be taken to ensure that running pccor produces sensible results
Phase cal tones are extracted in DiFX straight after the samples are unpacked to floats. See pcal.cpp for the algorithm and note that the “Implicit” or “Trivial” class will be chosen in all but pathological cases (see pcalImplicitAlgorithm . The baseband data are written into the pcal extraction buffer one FFT block at a time. Because a rough delay has already been calculated to align the FFT blocks, the data are derotated by working out the number of samples since the last second tick and calculating the position of the first sample within the pcal buffer based on this. The pcal phase and amplitude is calculated for each tone for each subintegration. These results are then accumulated at the FXManager. An amplitude correction is applied and the results are written out at the same time as the visibilities.
The phase values are written to ascii files identical to the pcal file expected by difx2fits (see the NRAO-DiFX-1.1 manual) except that the tones themselves are recorded in complex notation rather than phase and amplitude. There is one file per antenna and they are written into the .difx/ directory. The name of each file is “PCAL_” followed by the name of the antenna in upper case.
A few important points to note:
The tone interval is specified in the $IF block.
The tones to be extracted in each sub band are specified in the $PHASE_CAL_DETECT block. They are in order of priority and can be specified counting from DC (positive integers) or the band edge (negative integers). Different antennas and different baseband channels may link to different pcal setups.
See vex documentation for further information
Phase cal extraction in mpifxcorr is controlled by the value of phaseCalInt, set according to the tone interval in the $IF block in the vex file and overrideable in the antenna section of the v2d file (see vex2difx).
All specified extracted pcals are written out by mpifxcorr. This reflects the fact that extracting more tones does not significantly increase the computational effort, and extracting all pcals will probably become the norm in the foreseeable future.
The pcal integration time is currently the same as the visibility integration time. In a future version of DiFX this may be changed so that the pcal integration time can be larger than the visibility integration time for high time resolution experiments.
vex2difx stores the tones to extract (as specified in the vex file) in the input file frequency table in the format described here). These are the only tones written out by difx2fits.
The maximum number of tones extracted per band is specified in the header. It is therefore implicit which tones belong to which band (IF). The frequency of each tone is specified separately for each record.
See FITS documentation section 12 for further information.
Items in bold must be complete in time for 2.0/2.0.x tagging. Other items can be deferred to a later release.
Would be good to double-check that everything works
According to the documentation for pccor, where there is more than two tones extracted per IF only the outer two are used. This may be undesirable as these tones are located near the edge of the bandpass. It is unclear if AIPS will average up the pcal tones over a sensible interval if values are given at high time resolution. Presumably the derived delays are averaged up to the CL interval by CLCAL. Testing with a visibility and pcal integration time of 4s the results appear to be reasonable