News for VLBA/HSA/VLBI Proposers and Observers
July 31, 2023 — J.D. Linford
VLBA Proposal Submission Tool (PST) bug for PFB mode proposals
NRAO staff have been made aware of a bug in the Proposal Submission Tool (PST) affecting VLBA proposals that request PFB mode observations in the Resources section. The PST will not validate PFB proposals if any other warnings or errors are present. Proposers who wish to use the PFB mode should attempt to address any other warnings or errors first, and the PFB error may disappear.
If proposers are unable to clear the PFB error, they may use the DDC mode in the Resources section, and explain that they intend to use PFB in the Technical Justification.
May 18, 2023 — E. Momjian
Mauna Kea Antenna Panels Damaged due to Ice Storm (update)
The damaged panels of the primary reflector of the Mauna Kea Antenna have been replaced.
February 9, 2023 — E. Momjian
Kitt Peak Antenna Back in Service (update)
The Kitt Peak VLBA station is back in service as of February 2, 2023, after the shut down due to the Contreras Fire in Arizona. For more details, please see the NRAO Newsletter article.
January 10, 2023 — E. Momjian
Mauna Kea Antenna Panels Damaged due to Ice Storm
An ice storm in December 2022 caused noticeable damage to some of the panels of the primary reflector of the Mauna Kea Antenna due to large chunks of ice falling from the apex onto the panels. We anticipate that this damage will degrade the sensitivity of this antenna in observations that utilize the highest frequency bands. The effort to quantify the impact of this on science observations is underway. This will be followed by fixing the damaged panels in the coming few months.
June 21, 2022 — E. Momjian
Kitt Peak Antenna Temporarily Shut Down due to the Contreras Fire in Arizona
Fast-spreading wildfire southwest of Tucson, AZ, reached the Kitt Peak National Observatory property early Friday, June 17, 2022. While the VLBA antenna and the station building at the site are both undamaged, they currently remain without power or networking. Operations will resume as soon as all the safety assessments are concluded, power and networking are restored, and the safe return of the staff to the site is ensured. The NRAO is extremely appreciative of the efforts of all the firefighters.
October 15, 2021 — J. D. Linford
UT1-UTC Observations Now Every Other Day
Beginning in October 2021, the US Naval Observatory (USNO) UT1-UTC observations will occur every other day. The observations will continue to be 1.5 hours long and use the Mauna Kea and Hancock stations. See the Daily UT1-UTC page for more information, including tips on how to create schedules that minimize the risk of being preempted by these daily observations.
April 19, 2021 — J. D. Linford
Upcoming Changes to the Daily UT1-UTC Observations
Beginning in May 2021 and lasting through August 2021, the US Naval Observatory (USNO) will use only the Mauna Kea and Hancock stations for the daily UT1-UTC observation. The observations will be 1.5 hours long. See the Daily UT1-UTC page for more information, including tips on how to create schedules that minimize the risk of being preempted by these daily observations.
April 9, 2021 — J. D. Linford
VLBA Flux Density Scale at 2cm
VLBA staff are investigating an apparent systematic discrepancy in the flux density scale between PFB and DDC modes. The discrepancy was seen in a test observation at 2cm, with DDC observations giving ~12% lower flux density than PFB. It is currently unclear if other bands are affected. For more details, see the April 8, 2021 NRAO eNews article.
March 8, 2021 — J. D. Linford
VLBA Fringe-Finder Webpage Relocated
The VLBA Fringe-Finders Survey webpage has been moved to:
http://www.vlba.nrao.edu/astro/fringe_finder_survey/ffs.html
Please update your bookmarks.
November 1, 2020 — J. D. Linford
Daily UT1-UTC Observations Now Using 3 Antennas
The US Naval Observatory (USNO) now uses 3 antennas for the daily UT1-UTC observation. These observations will use the Mauna Kea and Saint Croix stations, along with one of the interrior antennas (usually Pie Town). See the Daily UT1-UTC page for more information, including tips on how to create schedules that minimize the risk of being preempted by these daily observations.
August 24, 2020 — J. D. Linford
Upcoming Changes to Daily UT1-UTC Observations
The US Naval Observatory (USNO) will add the Saint Croix station to the antennas used for the daily UT1-UTC observation beginning in November 2020. This will mean that 3 antennas (usually Pie Town, Mauna Kea, and Saint Croix) will be unavailable for science observations for 1--2 hours each day. See the Daily UT1-UTC page for more information, including tips on how to create schedules that minimize the risk of being preempted by these daily observations.
August 1, 2019 — J. Blanchard
Saint Croix major maintence completed
Hurricane repair work at Saint Croix has been completed and the antenna has returned to normal operations.
July 9, 2019 — W. F. Brisken
Saint Croix antenna downtime for major maintence (update)
Metalwork repair on the Saint Croix antenna is complete and the first coat of new paint has been applied. Remaining work includes completing the second coat of paint, reinstalling external cables, and recommissioning the antenna. VLBA staff are expecting return to service by approximately August 9, 2019.
April 5, 2019 — W. F. Brisken
Saint Croix antenna downtime for major maintence (update)
The Saint Croix VLBA antenna will be going offline on April 22 for the work noted below. Exact date of return-to-service is not yet known but the duration of the downtime is expected to be approximately 3.5 months.
December 19, 2018 — W. F. Brisken
Saint Croix antenna downtime for major maintence
The VLBA antenna on the island of Saint Croix was hit by a pair of hurricanes in September, 2017. After 6 months, primarily in restoring electrical power and internet services to the island, the antenna was returned to service. The VLBA received disaster relief funding to restore the VLBA antenna and site to pre-hurricane conditions. Some of this work has begun and has not impacted observing. The major upcoming effort will be corrosion mitigation and painting of the 25m antenna. This will require significant non-observing down-time. Exact dates are not yet known, but this work could begin by mid March, 2019 and will likely last 4.5 months. Please revisit this page for updates.
September 28, 2018 — W. F. Brisken
Unstable phase on the GBT
For a period of at least three years the GBT was operating with a local oscillator that had its phase reset at the start of each observing scan, even if the tuning did not change, with potentially serious effect on VLBI
data. There is no evidence or reason to believe that delay jumps happen in conjunction with the phase jumps. It is believed this problem began when GBT's LO synthesizers were replaced in June 2014 and continued through approximately Sep 20, 2017. This problem would have affected most phase-referenced VLBI observations made with the GBT in this period. Usually this is done for weak sources where self calibration is not possible, or in the case of astrometry where relative offset between a calibrator and a target source is the desired measurement. In these cases the GBT data would have produced data of no value to the experiments. In cases where in-beam calibration was employed (where a suitably bright source within the primary beam of the GBT is simultaneously observed, but separately correlated, is used to calibrate the weaker target), the GBT data are likely still usable, however users of such data will need to be careful not to determine calibration across scan boundaries. In cases where the GBT was affected, baselines not including the GBT would still be valid. In cases where self calibration was used on the target or where group delays are the primary observable, the GBT data would be usable. If the observations were made with pulse-cal enabled, the pulse-cal data distributed within the FITS file (PC table) might be usable to correct for the phase jumps. Please see documentation for the PCCOR task in AIPS.
September 28, 2018
RDBE Delay and Phase Jumps: Update
A pair of VLBA memos has been released providing more explanation of the delay jumps and some additional advise to users. The following two memos are available:
September 16, 2016 — J. D. Romney
RDBE Delay and Phase Jumps
Delay and phase jumps have been detected in observations made using both the DDC and PFB personalities of the RDBE. These occur only quite infrequently (as far as we are aware, at least), and characteristics of the jumps vary substantially, so it has not been possible to describe all the effects in detail, nor to recommend countermeasures beyond careful analysis of observational delays. General descriptions of the most common effects are sketched below.
1> Delay jumps upon resumption of an observation following interruption for short USNO operations at PT, MK, and possibly other stations: Any restart of an observation may require a reload of the appropriate FPGA firmware, and a resynchronization of the internal timekeeping may occur. A general rule for these cases is that return to delay and phase cannot be guaranteed on a schedule resumption, and comparison of delays at the affected stations before and after the interruption is necessary. Notification of the interruption has been included in the VLBA operators' logs for a long time, and was augmented recently to advise such a check.
2> DDC delay jumps: Such jumps have been seen sporadically for the last ~2 years, and have been the focus of a major investigation, and of numerous attempted corrections in the DDC firmware, all without complete success to this point. In some but not all cases, such jumps occur (if at all) on the second use of any given setup in the observation schedule, and do not recur subsequently within the same schedule. This effect, and the overall low rate of occurrence, both limit efficient analysis. Some test schemes have been developed to gather more data than available previously (at the cost of substantial observing time). Tests suggest a basic jump quantum that is inversely proportional to the channel bandwidth: 256ns / BW[MHz] for 2<=BW<=16; jumps of this type are not known to occur for BW=1 nor BW>=32. Some cases have been seen with small-integer multiples of that jump quantum. A major rewrite of the DDC FPGA firmware is currently under way, aimed both at preventing such jumps, and at facilitating tests to verify error-free performance.
3> PFB phase jumps: These have been rare enough to be thought not to occur any more, but at least one event was seen recently. The jump occurred only in the phase-cal results at one station, and was not seen in the actual interferometer phases.
September 10, 2015
RDBE_based VLBA Gains
VLBA pointing and gain measurements in the past in the past have been made based on power levels detected by the legacy Baseband Converters (BBCs). Since February 2014, power levels have also been measured in the new RDBE broadband system. The analysis which produces the gain values given in the vlba_gains.key has been run in parallel with both data sets. Until late August 2015, the vlba_gains.key derived from the BBCs was the one placed on the ftp site and used as the sources of the values distributed with exported data sets in the gain table. On September 2, 2015 we switched to using the gains derived from the RDBE data in the vlba_gains.key file. More information is presented in the VLBA Scientific Memo #37.
December 31, 2011
VLBA flag problems (Nov 10 to Dec 22)
During the second week of November, upgrades were made at Pie Town in support of the upgraded C-band receiver. These changes have transferred monitor and control of some antenna electronics from the "legacy" station computer to the modern system which is based on EVLA software. This new system is working well, however the legacy system, which is still responsible for generating flags for the station, was perpetually flagging data based on monitor points that no longer exist. The Hancock antenna C-band system was upgraded in December with the same issue beginning with observations made on Dec 10.
Data observed after Nov 10 and correlated before Dec 7 will have a single erroneous flag for Pie Town encompassing the entire observation. Data observed between Dec 7 and Dec 22 won't have any flags for Pie Town or Hancock. Data observed after Dec 22 should be back to normal.
VLBA operations staff have regenerated flag data for the Nov 10 through Dec 22 period. Users wishing to restore proper flags can follow the instructions to download cal.vlba.gz and then follow instructions in the AIPS Cookbook. The section titled Automatic formatting of VLBA and VLBA-like log files will explain how to use VLOG and UVFLG to load flags from the downloaded file. You may want to make a backup (with TASAV) of the original FL table before deleting it (with EXTD) just in case you want to go back to the original flags.
Questions regarding the flagging problem and its corrections should be directed at the NRAO helpdesk.
August 29, 2011
Hancock VLBA station temporarily shut down by hurricane Irene
The Hancock VLBA station was put into shutdown mode in the morning of August 27 in anticipation of high winds, heavy rains and power loss due to hurricane Irene. Commercial power was lost at approximately 3 am Sunday morning and has not yet been restored. The site techs were able to reach the station on Monday, August 29 and determined that there is no obvious damage to the antenna or structures. Numerous trees are down around the site and on the roads and power lines have been downed by fallen trees. It may take several days before power is restored, however, backup generators for critical systems (maser, cryogenics, etc.) are working so we anticipate a smooth return to operations once power is restored.
August 8, 2011
Error found in EOP corrections in AIPS
Versions of the AIPS task CLCOR released between Sept. 21, 2009 and Aug. 4, 2011 used the wrong sign on the station Y coordinate when calculating Earth Orientation Parameter (EOP) corrections. The main adverse impact will be on phase referencing projects for which sufficiently large EOP corrections were made that the difference in the relative correction between calibrator and target is significant. Check the Details of the CLCOR/EOP Error page for more details.
July 6, 2011
Los Alamos antenna back in operation
In the evening of July 6, 2011 the danger posed by the Las Conchas fire had subsided sufficiently that the Los Alamos VLBA antenna was put back in operation. It has been taking part in VLBA observations since.
July 2, 2011
Las Conchas Fire near Los Alamos
The Las Conchas Fire that started on June 26, 2011, came within a few miles of the LA VLBA antenna. The LA station is out of danger, but the fire continues to burn and is not yet contained. The Los Alamos National Laboratory remains closed. NRAO therefore has no access to the antenna at this time, and LA cannot currently be included in VLBA observations.
June 21, 2010
VLBA Pie Town azimuth track fixed
The Pie Town VLBA antenna was restored to full service on June 17, 2010, after antenna mechanics were able to effect a repair to the split in the rail. The damaged rail section was regrouted and the split rail was welded. It is believed that the split in the rail was caused by a poor quality weld of the rail to the mounting plate during the construction of PT. It appears that this weld cracked during cooling and then slowly propagated up the rail until the failure occurred.
June 1, 2010
VLBA Pie Town antenna down for repair of azimuth track
During a routine inspection of the Pie Town VLBA azimuth track on May 25, 2010, a split in the rail and grouting near bolt 20 was discovered. Until a repair is completed, the PT antenna will be unavailable for observing. Several options for the repair are under consideration, but PT will be out of service until at least July 1, 2010.
December 7, 2009
AIPS bugs
With the advent of new correlators for the EVLA, VLBA and ALMA, a number of changes have been happening in AIPS lately. In the process, some bugs were introduced, and have been fixed. This message describes one change in particular that users should be aware of and a few bugs that might have caught VLBI users.
CHANGE OF TERRESTRIAL REFERENCE FRAME
The change is a move to a right-handed coordinate system for stations. The puts AIPS in agreement with the ITRF rather than an ancient left-handed system (left over from MarkII days?) and is therefore the right thing to do. But it does introduce compatibility issues during the transition. In practice, the change means that the sign of BY in the AN table is reversed. This change was made in the 31DEC09 version of AIPS on Sept. 20. If the 31DEC09 (or 31DEC10) version of AIPS sees an AN table of the old type, identified by knowing the approximately correct coordinates of many stations, it converts the table to the new convention so backward compatibility is good. The problem comes when a data set with the ITRF convention is read by an older version of AIPS, be it 31DEC08 or earlier, or even a 31DEC09 version that has not had a midnight job run since Sept. 20. The older versions will not recognize that the coordinates are different and any task that needs station elevations or positions will get them wrong. This includes UVFIX, any plotting routines doing elevation or parallactic angle on an axis, CLCOR (any operations that need to know the antenna location or pointing direction), UVFLG elevation flagging, CALIB elevation cutoff for gain normalization, TECOR, ANTAB with opacity corrections, DELZN, PCAL, LPCAL, CVEL and probably others. In other words, it will almost certainly affect your processing.
Users can get into trouble during the transition in a couple of ways. If they use both new and old versions of AIPS in their processing, the recent version will convert the AN table, but the old version won't know about it. So, for now, it is best not to mix versions. The processed FITS files in the VLBA archive are produced using the latest AIPS. Therefore, files made since around Sept 20 will have the new antenna convention. If those are downloaded and processed in an older AIPS, there will be problems. A procedure, ANFIX8 is now available from a midnight job for 31DEC08 or from the 31DEC08 patch info on the web that will convert back to the frame needed by the 31DEC08 AIPS. Alternatively, one can download the individual job files and run the procedures (VLBALOAD, VLBAFIX) to read and combine them. By now, the 31DEC09 version has become "NEW" and is the latest stable version while 31DEC10 is "TST". If one stays with those two, there should not be a problem.
ANTENNA COORDINATE BUG IN FITLD
There was a bug in the implementation of the above change that caused the old convention to be used for any station that did not appear in the first correlator job file. This will affect observations for which some station, typically Mauna Kea, starts late. The processed archive files (but not the FITS IDI files for each job) are subject to this bug. Users should check their AN tables carefully to see if a fix is needed. For example, all VLBA antennas should have the same sign of BY. A procedure to fix affected data (ANCHECK) will be available with the midnight job after Dec 1. Processed files in the archive are subject to this bug. They will be fixed eventually, but meanwhile be careful with such files. If you schedule calibrators on all antennas at the start of your run, you may not be subject to the problem. This bug affects AIPS 31DEC09 with midnight jobs run between Sept. 20 and Nov. 26. Processed archive files made during this date range are suspect.
POLARIZATION CALIBRATION BUG
The application of polarization calibration (DOPOL=1) was entirely broken in 31DEC09 AIPS versions updated between Sept. 20 and Nov. 17. The data are modified, but not correctly. Any application of polarization calibration done with an affected AIPS should be redone after running a midnight job. Note that the derivation of the D terms is probably ok if your antenna coordinates are ok.
POLARIZATION EVPA CORRECTION BUG
The POLR option in CLCOR, used to adjust the absolute polarization position angle, was broken between Sept. 20 and Nov 26 in the 31DEC09 AIPS. The CL table is corrected properly, but the AN table may not be. The task made an error in determining the number of IFs in the table and might only modify some, but not all IFs. This leads to IF-dependent errors in adjusting the angle when the polarization rotation is applied. The fix is to update AIPS and re-apply the rotations with CLCOR. This requires zeroing the angle in the AN table or deleting the AN table and copying an unmodified one, that hopefully you saved early in your processing, in its place. Then rerun the polarization calibration.
AIPS MAINTENANCE
Note that, even if you are using an older AIPS, it is useful to occasionally run a midnight job or be sure you get any recent patches. These patches correct bugs that have been found that are believed to potentially cause significant problems for user's data. For example, recent patches for 31DEC08 AIPS have corrected errors in the use of the ICHANSEL adverb in BPASS and in the frequency put in the AN table by FITLD when rearranging the frequency order from correlator FITS IDI files. We apologize for any disruption caused by these issues.
September 2008 - February 2009
GBT Position Error
When the VLBA database was updated to a recent geodetic solution (2008a) in Sept. 2008, an error was introduced for the GBT. The trigger was a change of name of the GBT from "GBT" to "GBT-VLBA" that was not noticed when the new coordinates were loaded from the geodesy files to the VLBA database. This resulted in there being 2 entries for the GBT. The axis offsets were not updated at the same time so the new station got an offset of 0.0 meters when it should have been about 8.9cm. Correlator jobs created between then and when the problem was caught in January 2009 had the incorrect axis offset. During that same period, the VEX files created by SCHED also had a zero axis offset, so if those positions were used for correlation elsewhere, the same error would occur.
Note that the new GBT position and rates installed in September 2008 result in a change in the position for the GBT used in correlation by about 3cm. The change is within the error estimates for the GBT position, which is not nearly as well determined as those for the VLBA antennas.
Astronomic observers, particularly those doing parallax observations, should consider whether these offsets are an issue for them. If so, corrections should be made. Task CLCOR in AIPS is capable of making the necessary corrections.
March 19, 2008 - April 24 2008
EOP Error
The Earth Orientation Parameters (EOP) used on the VLBA correlator are normally updated daily from a Goddard site. There was a period between about March 19 and April 24 when this automated process was not working and that fact was not noticed. Observations whose correlator job scripts were made during that period were likely to have been correlated using rather long look-ahead values of EOP, rather than measured values. Job scripts are prepared after the observation and usually shortly before correlation. From past experience, we know that using predicted EOP can adversely affect phase referencing projects. Affected users will be notified directly. Any users who care about relative phase between sources should run the EOP correction routines. In AIPS this is done with the procedure VLBAEOPS (loaded with VLBAUTIL) or with CLCOR, the main task called by VLBAEOPS. In practice, all users who care about phases, usually for phase referencing, should make this correction a normal part of their processing in order to have the best possible EOP values.
2008
Pulse Cal Table Issue
If you do not use the Pulse Cal data when processing data from the VLBA correlator you can ignore this. The pulse calibration is normally done with the procedure VLBAPCOR (loaded with VLBAUTIL). It is also invoked for continuum observations in VLBAPIPE. The task that does the job is PCCOR.
A significant number of cases have been found where a few entries in the PC, or Pulse Cal, table provided with distribution data files from the VLBA correlator are assigned to the wrong antenna. Such data can be spotted by plotting (SNPLT) the pulse cal phases for each antenna. If there are sudden jumps on some antenna, there is likely to be incorrectly assigned data. That data will probably have a pattern of phases over channels that matches some other station's normal data. The cure is to get rid of the original PC table, download the cal file (which has a name like bw523cal.vlba.gz) from NRAO, run VLOG, and run PCLOD to load a new PC table. Data acquired through that path has not shown the problem. To find your cal files, go to http://www.vlba.nrao.edu/astro/VOBS/astronomy/ and search for the data on your observation by going to the right month, then the obs code.
It is unlikely that this problem will be fixed for data files from the hardware VLBA correlator. The software correlator under development will likely use a different data path, more like the cal file, for such monitor data and should not be subject to the problem.
July 30, 2007
OV Pointing Offset at 60 degrees
Between July 31, 2007 and August 30, 2007, there was an incorrect elevation pointing offset value installed in the antenna control unit at the VLBA antenna at Owens Valley. That value caused a pointing offset of about 10' at 60 degrees elevation. The adjacent values at 55 and 65 degrees were correct. The pointing offset used is interpolated to the elevation of the observation. The FWHM of the beam is about 1.9' at 22 GHz and scales with wavelength, so this pointing offset sent the antenna completely off source at the higher frequencies.
Severely affected data will need to be flagged. The AIPS task UVFLG can flag an elevation range using APARM(1) and APARM(2).
June 26, 2007
Problems with Calibration File Transfer at the VLBA Correlator
In recent months, some problems have been identified with the calibration transfer data distributed with VLBA correlator data. All of these problems affect only small amounts of data, and they do not affect the actual correlation results. Final processing results can, however, be adversely affected through the application of flagging and calibration. The issues are:
1. Occasionally the correlator job generation program creates spurious flags for the FG table with the reason "System idle". This is generally at the start of a job script and relates to the bookkeeping of what flags are set. It can cause major portions of a good scan to be flagged. That could be handled by deleting such flags, except while that flag is set, no data are being passed to the calibration tables so the data cannot be calibrated properly. The problem occurs sufficiently infrequently that not all projects are affected.
The cure, if excessive data are affected, is to use the old data path for calibration using VLOG, UVFLG, ANTAB, and PCLOD after deleting the FG, GA, TY, and PC tables. The amount of affected data can be determined by looking at the FG table for the reason "System idle" or simply by running something like VPLOT with the flags on and off (FLAGVER=-1) and looking for suspicious data loss with them on. Remember that flags are on when FLAGVER=0.
2. It is possible for the calibration transfer system to mis-label data in the pulse cal (PC) table when a station that is in other correlator jobs for the project are not in one of the jobs. This can happen especially with MK and SC which cannot see sources for the full time that others are observing. What has been seen is that the data for the station that is missing is not simply thrown away, but rather is ascribed to another station. A plot of the pulse cal data with SNPLT or a listing of the data will show twice as many calibration points as should be there, and alternate rows will have different patterns of relative phases between IFs or polarizations. Inspection of the patterns will show that half the rows belong to the missing station. Running the pulse cal calibration (PCCOR) on such data would create badly calibrated data. Again, the workaround involves using VLOG and PCLOD. Or the offending points could be edited from the PC table.
3. The time associated with pulse cal data points needs some adjustments from the values in the monitor data base. Data in the cal file (VLOG input) has all known adjustments applied. But from calibration transfer, there can be a 10s offset for truncated integrations - typically integrations less than 2 minutes long. Since the pulse cal values generally change slowly within a scan, this will have very little affect on the data in practice and likely can be ignored. It is possible, but very unlikely, that it will also cause a point to appear to be after the scan in which it was measured, which could cause it not to be used in calibration.
All of these issues potentially affect data from the start of the use of calibration transfer around late 1998, although the flag bug may be more prevalent since the use of Mark5 began. It is not clear when they will be fixed as the detailed causes are not yet fully understood and the people involved have higher priority work to do on the EVLA.
June 13, 2006
VLBA Source Catalog Error for Declinations from 0 to -1 degrees
The VLBA correlator data base and the SCHED source catalog, which is a reflection of that data base, have been subject to the -00deg problem since about August 2004. Some of the sources with declinations between 0 and -1 degree declination have had positions in the data base that are positive in declination. These are sources read from the geodetic solutions we have obtained from Goddard. In a type of software bug all to familiar to astronomers, the sign of the declination was lost when the geodetic results were read. Data correlated with such positions will not have fringes. Thanks to Matt Lister for finding the problem. The data base has been corrected. A corrected SCHED catalog (sources.vlba) has been placed on the distribution ftp site (ftp.aoc.nrao.edu in pub/sched). A mini-release of SCHED will be made soon with the new catalog and a few bug fixes. It will be called release 6.04.2 and will not be announced other than by this email. A search of VLBA correlator job scripts indicates that there were 15 projects in 2005 and 2006 affected by this problem. The PI's are being informed. The sources affected are listed in the attachment for anyone wanting to compare with sources they have observed. We appologize for this error.
Here, in SCHED catalog format, are the sources affected by the negative zero software bug. Here they have their correct declination, but the sign was positive in uncorrected catalogs.
*** SchedSrcs_060601.lis 2006-06-01 09:55:28.483002000 -0600
SOURCE='J0016-0015','0013-005','J0016-00'
! RA=00:16:11.0885580 DEC= -00:15:12.445270 RAERR= 0.210 DECERR= 0.320 CALCODE='V'
REMARKS='VLBA Calib Survey - GSFC sols. - created L.Petrov 2005f_astro' /
SOURCE='J0057-0024'
! RA=00:57:17.0021940 DEC= -00:24:33.177140 RAERR= 0.820 DECERR= 1.550 CALCODE='V'
REMARKS='VLBA Calib Survey - GSFC sols. - created L.Petrov 2005f_astro' /
SOURCE='J0108-0037','0105-008'
! RA=01:08:26.8426270 DEC= -00:37:24.164930 RAERR= 0.880 DECERR= 1.130 CALCODE='V'
REMARKS='VLBA Calib Survey - GSFC sols. - created L.Petrov 2005f_astro' /
SOURCE='J0125-0005','0122-003','J0125-00'
! RA=01:25:28.8438280 DEC= -00:05:55.931940 RAERR= 0.230 DECERR= 0.370 CALCODE='V'
REMARKS='VLBA Calib Survey - GSFC sols. - created L.Petrov 2005f_astro' /
SOURCE='J0208-0047','0205-010'
! RA=02:08:26.3458970 DEC= -00:47:44.293300 RAERR= 0.270 DECERR= 0.470 CALCODE='V'
REMARKS='VLBA Calib Survey - GSFC sols. - created L.Petrov 2005f_astro' /
SOURCE='J0259-0019','0256-005'
! RA=02:59:28.5161470 DEC= -00:19:59.974870 RAERR= 0.230 DECERR= 0.400 CALCODE='V'
REMARKS='VLBA Calib Survey - GSFC sols. - created L.Petrov 2005f_astro' /
SOURCE='J0318-0029'
! RA=03:18:14.4273150 DEC= -00:29:48.932630 RAERR= 3.140 DECERR= 2.660 CALCODE='V'
REMARKS='VLBA Calib Survey - GSFC sols. - created L.Petrov 2005f_astro' /
SOURCE='J0442-0017','0440-003','J0442-00','NRAO190'
! RA=04:42:38.6607420 DEC= -00:17:43.420440 RAERR= 0.200 DECERR= 0.310 CALCODE='V'
REMARKS='VLBA Calib Survey - GSFC sols. - created L.Petrov 2005f_astro' /
SOURCE='J0449-0057'
! RA=04:49:42.9059490 DEC= -00:57:22.352580 RAERR= 0.460 DECERR= 0.920 CALCODE='V'
REMARKS='VLBA Calib Survey - GSFC sols. - created L.Petrov 2005f_astro' /
SOURCE='J0513-0032'
! RA=05:13:02.6040120 DEC= -00:32:25.257940 RAERR= 16.840 DECERR= 7.260 CALCODE='V'
REMARKS='VLBA Calib Survey - GSFC sols. - created L.Petrov 2005f_astro' /
SOURCE='J0558-0055'
! RA=05:58:44.3914940 DEC= -00:55:06.929300 RAERR= 2.020 DECERR= 3.210 CALCODE='V'
REMARKS='VLBA Calib Survey - GSFC sols. - created L.Petrov 2005f_astro' /
SOURCE='J0600-0005'
! RA=06:00:03.5032380 DEC= -00:05:59.029430 RAERR= 16.850 DECERR= 7.280 CALCODE='V'
REMARKS='VLBA Calib Survey - GSFC sols. - created L.Petrov 2005f_astro' /
SOURCE='J0606-0024'
! RA=06:06:57.4437780 DEC= -00:24:57.455460 RAERR= 6.100 DECERR= 15.960 CALCODE='V'
REMARKS='VLBA Calib Survey - GSFC sols. - created L.Petrov 2005f_astro' /
SOURCE='J0703-0051'
! RA=07:03:19.0866190 DEC= -00:51:03.158050 RAERR= 0.230 DECERR= 0.380 CALCODE='V'
REMARKS='VLBA Calib Survey - GSFC sols. - created L.Petrov 2005f_astro' /
SOURCE='J0725-0054','0723-008','J0725-00'
! RA=07:25:50.6399620 DEC= -00:54:56.544330 RAERR= 0.210 DECERR= 0.320 CALCODE='V'
REMARKS='VLBA Calib Survey - GSFC sols. - created L.Petrov 2005f_astro' /
SOURCE='J0745-0044','0743-006','J0745-00'
! RA=07:45:54.0823240 DEC= -00:44:17.540040 RAERR= 0.200 DECERR= 0.320 CALCODE='V'
REMARKS='VLBA Calib Survey - GSFC sols. - created L.Petrov 2005f_astro' /
SOURCE='J1024-0052','1021-006','J1024-00'
! RA=10:24:29.5866730 DEC= -00:52:55.496700 RAERR= 0.250 DECERR= 0.400 CALCODE='V'
REMARKS='VLBA Calib Survey - GSFC sols. - created L.Petrov 2005f_astro' /
SOURCE='J1148-0046'
! RA=11:48:07.1918220 DEC= -00:46:45.674030 RAERR= 2.490 DECERR= 4.930 CALCODE='V'
REMARKS='VLBA Calib Survey - GSFC sols. - created L.Petrov 2005f_astro' /
SOURCE='J1150-0023','1148-001','J1150-00'
! RA=11:50:43.8707490 DEC= -00:23:54.205380 RAERR= 0.220 DECERR= 0.340 CALCODE='V'
REMARKS='VLBA Calib Survey - GSFC sols. - created L.Petrov 2005f_astro' /
SOURCE='J1217-0029','1215-002'
! RA=12:17:58.7290410 DEC= -00:29:46.299490 RAERR= 1.200 DECERR= 2.430 CALCODE='V'
REMARKS='VLBA Calib Survey - GSFC sols. - created L.Petrov 2005f_astro' /
SOURCE='J1319-0049'
! RA=13:19:38.7661780 DEC= -00:49:39.938880 RAERR= 0.340 DECERR= 0.780 CALCODE='V'
REMARKS='VLBA Calib Survey - GSFC sols. - created L.Petrov 2005f_astro' /
SOURCE='J1404-0013','J1401-000'
! RA=14:04:12.1239620 DEC= -00:13:25.091000 RAERR= 0.270 DECERR= 0.470 CALCODE='V'
REMARKS='VLBA Calib Survey - GSFC sols. - created L.Petrov 2005f_astro' /
SOURCE='J1449-0045'
! RA=14:49:16.5903170 DEC= -00:45:19.229450 RAERR= 0.670 DECERR= 1.130 CALCODE='V'
REMARKS='VLBA Calib Survey - GSFC sols. - created L.Petrov 2005f_astro' /
SOURCE='J1557-0001','1555+001','J1557-00'
! RA=15:57:51.4339710 DEC= -00:01:50.413680 RAERR= 0.200 DECERR= 0.300 CALCODE='V'
REMARKS='VLBA Calib Survey - GSFC sols. - created L.Petrov 2005f_astro' /
SOURCE='J1628-0041'
! RA=16:28:48.4677110 DEC= -00:41:39.704440 RAERR= 1.000 DECERR= 1.750 CALCODE='V'
REMARKS='VLBA Calib Survey - GSFC sols. - created L.Petrov 2005f_astro' /
SOURCE='J1632-003A'
! RA=16:32:57.6813640 DEC= -00:33:21.076790 RAERR= 0.920 DECERR= 2.560 CALCODE='V'
REMARKS='VLBA Calib Survey - GSFC sols. - created L.Petrov 2005f_astro' /
SOURCE='J1640-0011'
! RA=16:40:10.5861940 DEC= -00:11:47.544210 RAERR= 0.640 DECERR= 1.080 CALCODE='V'
REMARKS='VLBA Calib Survey - GSFC sols. - created L.Petrov 2005f_astro' /
SOURCE='J2156-0037','2153-008'
! RA=21:56:14.7579180 DEC= -00:37:04.594520 RAERR= 0.240 DECERR= 0.420 CALCODE='V'
REMARKS='VLBA Calib Survey - GSFC sols. - created L.Petrov 2005f_astro' /
SOURCE='J2340-0053'
! RA=23:40:23.6701220 DEC= -00:53:26.998510 RAERR= 2.940 DECERR= 3.630 CALCODE='V'
REMARKS='VLBA Calib Survey - GSFC sols. - created L.Petrov 2005f_astro' /
SOURCE='J2354-0019','2351-006'
! RA=23:54:09.1759120 DEC= -00:19:47.955750 RAERR= 0.310 DECERR= 0.560 CALCODE='V'
REMARKS='VLBA Calib Survey - GSFC sols. - created L.Petrov 2005f_astro' /
February 13, 2006
EOP Update
We recommend that all VLBA users update the predicted or first-look Earth Orientation Parameters used by the VLBA correlator to the final values available from USNO. This is done in AIPS with the task CLCOR, _or_ with the procedure VLBAEOPS, which invokes CLCOR.
The recent leap second unearthed a bug in CLCOR, now fixed. Users should update their installation of AIPS with the midnight job. Help is available at: http://www.aoc.nrao.edu/aips/#MNJ or by email to daip@nrao.edu.
The bug was that CLCOR, run on data observed after 1 Jan2006, effectively used the wrong value for the leap second. The symptom is that the "USNO" and "Used by Correlator" values, as reported by CLCOR at execution, differed by 1 second. They should differ by a few milliseconds at most. CLCOR run on data prior to 01 Jan2006 works correctly when TAI-UTC is 32 seconds; it is now 33.
August 10 & October 6, 2005
VLBA Correlator EOP Errors
Message sent 2005 October 6
Previously it was announced that the VLBA correlator had been using predicted values for Earth Orientation Parameters (EOP) for approximately the last 2 years. The Earth rotation and pole position are not easily predicted, even over only 2 weeks, so these values are significantly worse than the Rapid Service values that are normally used. This can adversely affect projects that depend on an accurate correlator model, such as phase referencing.
With this email, we announce that the ability to fix EOP is now available in the AIPS task CLCOR and that there is a new VLBA Test Memo Number 69 that explains how to fix data, presents details of what happened, shows how the poor EOP affects data, and gives results of test observations.
To use the new CLCOR capability, use the 31DEC05 version of AIPS and be sure that it has been updated (midnight job) since 2005 September 30. To read the VLBA Test Memo, go to http://www.vlba.nrao.edu/memos/test/ and click on the type (ps, pdf, html) of file you would like to read for Memo 69.
Note that before this problem began, and since it was fixed, occasional job scripts have used poor EOP values, usually because they were prepared before the Rapid Service values were loaded into the data base. See the Memo 69 for instructions on how to check the EOP used for specific projects.
This is the message sent on the VLBI exploder on Aug. 10, 2005.
A significant issue has been found with the Earth Orientation Parameters (EOP) used in VLBA correlator job scripts since May 2003. The problem adversely affects projects that depend on an accurate correlator model. Such projects include any that use phase referencing or that try to solve for the atmosphere using sources scattered around the sky. Projects that depend primarily on self calibration on the target source or that use the total delays from the correlator are not affected.
A bug was found in the correlator job generator that caused it to use predicted values of EOP rather than measured rapid service values. The magnitude of the errors, mostly in UT1-UTC, is roughly equivalent to having source position errors of typically about 10 mas before June 2004 and about 20 mas since then. The worst cases were about 4 times these values. The effect on phase referenced observations depends on details of the offsets and geometry. The phase error on a source depends on position on the sky and on time. To first order, corrections based on calibrator observations will fix the phases on a target. But, as with any other geometry error, the residual error on the target after calibration will be approximately the calibrator phase error reduced by the calibrator to target separation in radians (typically well under 0.1). This phase residual can shift measured positions. But it not completely equivalent to a position shift so it can also degrade phase reference image dynamic range and, in extreme cases, can prevent detection of the target.
A more detailed description of the problem will be published eventually in a VLBA Test Memo which will be available at http://www.vlba.nrao.edu/memos/test/.
The job generator was fixed on August 8, 2005. There is currently no AIPS program that can correct the affected data sets. But soon the capability will be added as an option in CLCOR. Note that even without this bug, VLBA correlation is based on rapid service EOP values from close to the date of observation, not on the finals that are only available much later. Users wanting high accuracy may wish to make corrections for any observations.
Thank you to Mark Reid for calling to our attention that we were using EOP values with significant errors. For further information, contact the Socorro VLBA staff.
August 26, 2005
VLBA Phased Array Observations - Calibration Problems
Sent to the VLBI email list on 15 August 2005
Dear PI, You may or may not have noticed that the sensitivities for the phased VLA in your recent experiment (see below) may be off from expected. Note that single dish VLA observations should not be affected. This message is to inform you how to recognize the possible phased VLA calibration problem and how to solve for it. We sincerely apologize for the inconvenience.
Probably affected experiments, in alphabetical order: bb190, bb191, bb191b, bb196, bb204, bb209a, bd103, bf083, bf084a, bf084b, bg141, bg150, bg155, bh128, bj054, bk114b, bk114e, bl121, bm223a, bm223b, bn032, br088c, br092a, br092b, br092c, br092d, br102a, br102b, br102c, bu030a, bu030b, bu030c, bw076, bw080, bw084, gb049a, gb049b, gb049c, gb053, gd017a, gd017b, gd018, gg049a, gm048c, gm055a, gm059a, gt005, ty001
Probably unaffected: bk110, bk114a, bk114c, bk114d, bk119, bn031, bt075, tf029a (as they probably need to run ANTAB to get the VLA TY values included)
To recognize whether you are affected, look in your data's TY-table:
Figure out the antenna number for the VLA using PRTAN or TYPE ANTNUM('Y') Then check if for antenna Y, the phased VLA and for the phased VLA only, the 8th and 10th (TANT 1, TANT 2, assuming you have both polarizations) columns are set to -1.0 (or any other negative value, which will be true only if you run ANTAB). Note that if there are no TANT values in the TY table for the antenna number corresponding with the VLA, you need to run ANTAB anyway and you will not encounter this problem. Use for example
AIPS> default prtab; docrt 1; inext 'ty'; box 4 8 10
AIPS> indisk i; getname j; go prtab (and many returns until you get to the antenna number for the VLA)
If the columns are filled with a negative value, you should have nothing to worry about. If they are labeled 'INDE' for the phased VLA, please read on.
Since late-2003 we have included the gain curve and Tsys values for the VLA in most VLBA distribution tapes in order to make it more convenient for our users; i.e. not to have to run ANTAB anymore and have the VLA behave just as a VLBA antenna as much as possible. However, for the phased VLA, the FITLD/VLBALOAD program did not recognize whether the VLA was used in single dish or in phased array mode. This means that for the phased VLA, the Tsys/Tant values were not properly converted into proper SN table gain values in APCAL/VLBACALA, unless you used ANTAB to (re)load the VLA Tsys values. To get a proper Tsys value, APCAL/VLBACALA uses the TANT columns of the TY table to see if it is supposed to extract the source flux from the SU table in order to convert the given Tsys/Tant in the TY table, and store the appropriate gain solutions in the newly generated SN table.
To solve for the problem, unfortunately you probably have to recalibrate your data from the start. If you haven't started loading the data from the distribution tape(s) yet, you may want to fetch todays (15 Aug 2005) new FITLD version using the midnight job (MNJ). If you got your data using the archive ftp method, let me know and in a day or two there will be a new file for you to download. Or you can still load the data into AIPS using the old FITLD and/or archive file and follow the fix below.
If you have your data on disk inside AIPS, the easiest fix is as follows:
- delete (maybe after a TASAV) all SN and CL tables except for CL#1
- find the antenna number for Y (eg with task PRTAN)
- use TABED, with: default tabed; indisk i; getname j inext 'TY'; optype 'repl'; keyvalue=-1,0; outdisk=indisk aparm=8,0,0,2,4,[antenna number of phased VLA]; go tabed
- and once more for a second polarization with: aparm(1)=10; go tabed
- rerun VLBACALA or ACCOR/APCAL, etc
Again, we apologize for the extra work. Thanks to Josh Winn for pointing out this problem/feature/bug. Please contact me if you have any further questions regarding this problem.
Note added after sending this message to the VLBI email list: If you relied on self cal on either the target, or a nearby calibrator, and did not include the VLA in the list of antennas used for the flux scale, you should be ok without any recalibration.
