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 absolute phases near the bottom of the baseband agree very closely with those extracted at the VLBA stations only once they have been inverted (i.e. each phase in degrees multiplied by -1). As of commit 2927-2929, this flip is done in the sprintf statement in visibility.cpp as the phase is written to the output file.
• There is a linearly increasing error on the phases across the baseband (compared with VLBA values) corresponding to a delay of ~ 0.03 microseconds. However this is constant across all antennas and baseband channels and so will not affect the final calculated delays

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).

• A positive integers is the interval in MHz between the extracted tones (e.g. 4 will extract 8004MHz 8008MHz etc.)
• Zero means no phase cal extraction
• Negative integers are reserved for future use

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.

1. Test DiFX performance (CPU load running with and without phase cal extraction switched on)
2. Test against MarkIV correlator-extracted phase cal tones

1. Fix channel indices in pcal output files
2. Fix pcal tone amplitudes
3. Modify pcal.cpp to follow DiFX coding conventions:
   1. Use alert.h streams (cverbose etc.)
   2. Test error code of every IPP call
4. tweak pcal file output
   1. Write out frequencies as integers as we only allow integer MHz in any case
   2. Change pcal ascii output to complex notation?? (this follows the FITS-IDI convention and is required for time-averaging anyway)
5. Ensure that tones in the Nyquist channels are not written out under any circumstances (leaving tone numbering the same as the vex file definition)
   1. ensure that tone numbering in configuration.cpp reflects this
6. Merge into trunk
7. Remove un-necessary guff from ascii output files (and switch to a binary format?)
8. Swap the sign of the imaginary component (at the moment this is done in difx2fits)
9. Average pcals over a minimum of 1s in time for very high time-resolution correlations

1. Read the pcal interval from the $IF block in the vex file
2. Read which pcal tones to write out to the output file in each channel from vex file $FREQ block (and links to phase_cal_detect therein)
3. Properly handle out-of-order and negative tone indices in the vex file

1. warn if pcal tone extraction is used with any incompatible mode
   1. LO offsets
   2. Zooming and band matching?
      1. This is not incompatible and should work -WFB
2. Add support for as many modes as possible

1. allow cable cal values from pcal file and pcal values from DiFX
2. implement time-averaging of pcals
3. populate pcal rate in fits file

Would be good to double-check that everything works

1. with pulsar binning
2. in observations which switch frequency setups
3. with band matching
4. correlating unmatched bands
5. setups which test the other two pcal classes:
   1. Trivial (pcal offset is zero)
   2. Shifting

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