Cycle 7 solar interferometry data was observed with an improper handling of the correction of gravitational light bending on the disk of the Sun.
This issue may have two effects:
The coverage of the observation is offset from the desired coverage (by up to 50arcsec at around 1arcmin distance from the center of the Solar disk);
There are phase drifts (within each individual delay event of ~30s), which can be corrected for by using self calibration.
The ALMA delay tracking system (which involves many components throughout the array) is conducted by broadcast messages specifying all the delay values to be applied throughout the system in 30 second blocks of time, sent some seconds or more before the start time of each block. These messages are referred to as Delay Events, and are produced by a central software component called the Delay Server. The Delay Server has to do various manipulations to obtain from the source astrometry the final positions from which the delays can be computed. Astrometric manipulations in the ALMA control software make use of the SLALIB [1] library, which is standard for most observatories. One manipulation is the addition of requested position offsets to the source position. Offsets for ALMA observing can be specified in various coordinate systems, one of which is a horizon system with axes aligned with directions of constant azimuth and elevation (used mostly for various calibrations). To implement this the code was transforming from (RA,Dec) to (Az,El), applying the horizon offset, and then converting back to (RA,Dec) using inverse routines [3]. Among these routines are ones for converting from mean to apparent RA,Dec and back [2,3]. It was assumed that calling the routines [2] and [3] sequentially had no net effect when no offset was added in between. These two routines, however, both apply gravitational light bending corrections due to the mass of the Sun which affects the apparent position of distant objects observed close to the Sun. There were two problems with this, despite the routines being intended to be exact inverses of each other:
1) The routine [3] applies a mitigation to reduce the light bending correction within 920 arcseconds of the barycentre, such that the effect is zero at the centre;. The routine [2] does not apply this mitigation, so the routines are not exact inverses within 920 arcsec of the barycentre, and this causes an astrometric offset equal to the difference in their light bending correction, which is dominated by the large correction applied by [2]. The error is radial from the barycentre.
2) Within about 50 arcseconds of the barycentre the light bending correction essentially results in the barycentre position itself being returned by [2], so the input position is effectively lost. The barycentre position referred to here is determined internally by SLALIB, using a specified time, which in this case was set to the system time when the computation was made. The computation of all epochs within each 30 second Delay Event used the same SLALIB barycentre position, which means that the delay centre position became frozen, or nearly frozen, when pointing within about 50 arcseconds of the barycentre. This results in a temporally varying astrometric error, with discontinuity at the boundary between one delay event and the next.
The systematic radial error was evaluated by calling sequentially [2] and [3] for a series of points along a line through the SLALIB-defined barycentre position at a particular epoch. The result is tabulated in the attached text file and showing in the attached plots. The maximum systematic offset is 55.4 arcseconds at a distance of 58.7 arcseconds from the barycentre. At the limb it is essentially zero as the correction applied by [2] and [3] is almost equal, and outside 922 arcseconds the error is exactly zero. This systematic radial offset can be used to correct the phase/delay centre for imaging, or simply as an image shift post-imaging.
The temporal variation of the phase/delay centre error within ~100 arcsec of the barycentre is harder to correct a-priori. The final RA,Dec used by the Delay Server to compute the delay for each epoch in each Delay Event are recorded in debug logs, which can theoretically be used to create an effective observed ephemeris. However, considerable work and expert knowledge would be required to piece together the actual ephemeris from the log messages, and turn this into a correction that could be applied within the data flow in CASA. If self-calibration can be applied with integration timescale (solint=int in CASA's gaincal) then this will effectively remove the effect. As self-calibration is often used for Solar observations, it is hoped that this can mitigate the issue in the handful of science projects which observed very close to the barycentre direction.
As a mitigation of the problem for future observing cycles, starting with Cycle-8, the relevant coordinate conversion in the Delay Server is being skipped when there are no horizon position offsets to apply. Generally horizon offsets are not used for science-related interferometric scans, so this is expected to be a valid simple solution. In future a more complete solution to provide correct handling of horizon offsets for interferometric scans within the disc of the Sun may be implemented if needed.
[1] http://star-www.rl.ac.uk/star/docs/sun67.htx/sun67.html
[2] http://star-www.rl.ac.uk/star/docs/sun67.htx/sun67ss117.html
[3] http://star-www.rl.ac.uk/star/docs/sun67.htx/sun67ss6.html
