Known problems with (E)VLA and VLBA archival data

This page was last updated on 2017 Feb 16 14:30 MST to keep track of known problems that affected data taken with the VLA/EVLA and/or the VLBA that appears and is remaining either in the data archive, or in the programs reading the data archive into the data reduction packages. For current problems that are affecting current data, and thus also are not fixed in the data archives and data readers, check the VLA Proposers/Observers/Data reduction page.
If you cannot find the answer, have additional concerns or want to point out a new problem, please use the NRAO Helpdesk.

Note that you may have good data that appears to have problems. Over the years bugs have been discovered and corrected in AIPS. Please make sure you have a reasonably recent version of AIPS, especially if you are dealing with data during the period of transition from VLA to EVLA to Karl G. Jansky Very Large array (VLA) and thereafter. The same holds for the CASA (formerly AIPS++) data reduction package.

Unfortunately this page remains a work in progress as new and old issues are found continuously. Of course if you know of an unlisted problem (which isn't unlikely as we've just started this page from our faded memories), suspect one, or have another question please contact the NRAO Helpdesk using your my.nrao.edu login.

Use these links to skip the introduction and jump to the list of (E)VLA or VLBA archive issues directly.


Introduction, or how to read this page

The following figure shows an example of a time line of three specific issues. The header on top shows the time line labeled in years. The first column contains an issue number that corresponds to issue numbers in the (long) listing below. To asses your data, find the appropriate (VLA or VLBA) time line below and draw a vertical line at the date of your data. Check each issue number for which your line crossses the corresponding issue line (and also the ones that start just after..). To be conservative, the lines include the whole month in which the issue appears; check the issue descriptiton for the exact dates and times.

'01 '02 '03 '04 '05 '06 '07 '08 '09 '10 '11 '12
21  
 
20  
 
19  
 

For example, if you download data from 2006, you need not to look at issue number 21, 20, nor 19. However, if your data is from 2008 you need to check issue #21 and can ignore issues #20 and #19. Similarly, if your data is from the end of 2002, you can skip issue #21 but need to study issue #19. And because issue #20 has been found just after your data was taken, it might be a good idea to check issue #20 too as is may be in your data and we don't know about it (in which case you should contact us through the NRAO Helpdesk using your my.nrao.edu login)!

Known problems are listed in reverse issue number, which over due time will become a random order of (approximate) starting date, separated for (E)VLA and VLBA issues (some may be listed under both if applicable). However, as some issues may not be related to the data, but to the data readers themselves, you may want to read the general reader (FILLM or FITLD) issues first. If your data includes EVLA antennas (as may be the case for data between 2005 and 2013), you should also check the EVLA returns page.

Now that you have your list of specific issues you have to check, you should do the following; remember that the time line is conservative in that it includes whole months, and that you also might be interested in issues that start just after your vertical data line.

If your data is from before the red "Begin" date or after the green "End" date, you should be fine for the specific issue listed. Also if you download any data after the blue "Archive fixed?" date, you should not be affected anymore by that specific issue. More exact begin and end times on the dates are given in the section describing the issue, which you can get at by clicking the link.

If your data is from between the red "Begin" and the green "End" date, and you obtained the data before the blue"Archive fixed?" date (either from an archive download, an on-line FILLM, or by any other means such as from your collaborator ...), your data may be affected! Because specific issues may only affect certain data, the "Notes" column should indicate under which circumstances the data is affected. Note that the "Archive fixed?" column is only given for the purpose of determining whether you should pay attention to the issue description below; it is not intened to give you a clue about whether we will (or even can) fix the archive or not if it says "not fixed".

The flow diagram on the right hand side of this page should help to determine how to deal with a specific issue; click on the image for a more readable version.



(E)VLA archive issues: (for VLBA see below)

  #  |    2013    |    2014    |    2015    |    2016    |    2017    |    2018    |    2019    |    2020    |    2021    |    2022    |    2023    |    2024    |
      JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND 
 ----|------------|------------|------------|------------|------------|------------|------------|------------|------------|------------|------------|------------|
1023 |            |            |            |       ==== |            |            |            |            |            |            |            |            |
1022 |            |            |          = |            |            |            |            |            |            |            |            |            |
1021 |============|============|============|============|============|============|============|============|============|============|============|============|
1020 |            |            |     =      |            |            |            |            |            |            |            |            |            |
1019 |            |    ==      |            |            |            |            |            |            |            |            |            |            |
1018 |            |   =        |            |            |            |            |            |            |            |            |            |            |
1017 |           =|===         |            |            |            |            |            |            |            |            |            |            |
1016 |           =|==          |            |            |            |            |            |            |            |            |            |            |
1015 |==========>>|            |            |            |            |            |            |            |            |            |            |            |
1014 | =          |            |            |            |            |            |            |            |            |            |            |            |


# | 2001 | 2002 | 2003 | 2004 | 2005 | 2006 | 2007 | 2008 | 2009 | 2010 | 2011 | 2012 | JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND ----|------------|------------|------------|------------|------------|------------|------------|------------|------------|------------|------------|------------| 1021 | | | | | | | | | |============|============|============| 1013 | | | | | | | | | | | | == | 1012 | | | | | | | | | | | | == | 1011 | | | | | | | | | | ==========|=======-----|---- | 1010 | | | | | | | | | | | =|= | 1009 | | | | | | | | | | | ====| | 1008 | | | | | | | | | | | = | | 1007 | | | | | | | | | | | = | | 1006 | | | | | | | | | | | = | | 1004 | | | | | | | | | | = | | | 1002 | | | | | | | | | =|============|====> | | 1003 | | | | | | | | | =|============|====> | | 1001 | | | | | | | | | ===> | | | | 019 | | | | | | | | | | ==========|====>> | | 018 | | | | | | | | | =======|= | | | 017 | | | | | | ?=|============|============|============| | | | 016 | | | | | | | | | = | | | | 015 | | | | | | | | | = | | | | 003 | | | | | | | | |=== | | | | 004 | | | | | | | | ?== | | | | | 005 | | | | | | | |= | | | | | 009 | | | | | | | = | | | | | | 006 | | | | | | | == | | | | | | 008 | | | | | | | === | | | | | | 007 | | | | | | | === | | | | | | 002 | | | | | | | == | | | | | | 014 | | | | | | | =======|============|============|==>> | | | 013 | | | | | | | =======|============|?? | | | | 011 | | | | | | ??======|============|==== | | | | | 012 | | | | | | ??======|=== | | | | | | 001 | | | | | | ??== | | | | | | | 010 |============|============|============|============|============|============|====== | | | | | |
# | 1989 | 1990 | 1991 | 1992 | 1993 | 1994 | 1995 | 1996 | 1997 | 1998 | 1999 | 2000 | JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND ----|------------|------------|------------|------------|------------|------------|------------|------------|------------|------------|------------|------------| 010 |============|============|============|============|============|============|============|============|============|============|============|============|
# | 1977 | 1978 | 1979 | 1980 | 1981 | 1982 | 1983 | 1984 | 1985 | 1986 | 1987 | 1988 | JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND ----|------------|------------|------------|------------|------------|------------|------------|------------|------------|------------|------------|------------| 010 |============|============|============|============|============|============|============|============|============|============|============|============|
General AIPS FILLM (and FILLR) issues
Check the EVLA returns page, last updated on 2017 February 16
Specific (E)VLA archive issues:
        # BeginEndArchive fixed? Issue (follow links)Notes

001 2006 Jul/Aug not fixed First EVLA antennas
002 2007 Jun 28 2007 Jul 29 fixed Wrong u,v, and w coordinates TWO separate issues
003 2009 Jan 14 2009 Mar 08 not fixed Timing error Data taken on Fri (UT)
004 2008 Mar/Apr 2008 May not fixed Online flagging
005 2008 Jan 04 2008 Jan 24 not fixed IAT clock error
006 2007 Jul 30 2007 Sep 20 2008 Apr 22 Sideband issue All line data
007 2007 Jun 28 2007 Aug 21 not fixed System Temperature Antennas 11 and 19
008 2007 Jun 29 2007 Aug 29 not fixed Pointing error Antennas 1 to 9
009 2007 Sep 14 2007 Sep 19 2007 Sep 24 Frequency increment
010 1979 Jun 2007 Jun 29 not fixed (u,v,w) error
011 2006 2008 Apr 09 not fixed Doppler tracking EVLA antennas
012 2006 2007 Mar 02 not fixed Mozaicing error EVLA antennas
013 2007 Jun 27 2008 ?? not fixed 25 MHz BW problem
014 2007 Jun 27 not fixed 12.5 MHz noise
015 2009 Mar 10 2009 Mar 19 not fixed Phase jumps EVLA antennas
016 2009 Nov 17 2009 Nov 20 not fixed Tsys/Timing error
017 2006 Dec 2009 Dec 18 not fixed Wrong Doppler calculations dynamic time (J)observe files
018 2009 Jun 17 2010 Jan 10 not fixed Wrong Tsys in Ka band 7 of the Ka antennas
019 2010 Mar 01 not yet not fixed Bad Stokes V
1001 2009 June 17 2009 fall CASA importasdm fails
1002 2009 Dec 31 not fixed Scans missed
1003 2009 Dec 31 not fixed BDFs missing
1004 2010 May 22 2010 May 25 not fixed Bad data
1006 2011 May 15 2011 May not fixed Clock problem
1007 2011 Jul 28 2011 Aug 01 not fixed No SysPower (not essential)
1008 2011 Jul 07 2011 Jul 11 not fixed Unstable IFs B,C
1009 2011 Sep 20 2011 Dec 02 not fixed CBE integration failed For Tint > 1 sec
1010 2011 Dec 23 2012 Jan 12 not fixed Weather data Opacity corrections
1011 2010 Mar 01 2012 Apr (2011 Aug) not fixed Spectral splatter spectral artifacts at high SNR
1012 2012 May 15 2012 Jun 15 2012 Jun 22 OnLine Flags too much online flagging
1013 2012 Jun 07 2012 Jul 24 not fixed BD tuning
1014 2013 Feb 05 22UT 2013 Feb 11 20UT not fixed Timing error
1015 2013 Jan 20 not fixed Incomplete data not suitable for pipelining
1016 2013 Dec 20 2014 Feb 14 not fixed Slewing flags "QUACK" data
1017 2013 Dec 12 2014 Mar 11 not fixed Requantizer 3-bit: "QUACK" data
1018 2014 Apr 09 2014 Apr 09 not fixed CMIB disregard data
1019 2014 May 29 2014 Jun 19 not fixed P band use Stokes I
1020 2015 Jun 02 2015 Jun 11 fixed CBE averaging reload from archive (see issue below)
1021 2010 Jan 01 not fixed zeroed data
1022 2015 Dec 07 not fixed timing error
1023 2016 Aug 09 2016 Nov 15 not fixed delay error

VLBA archive issues:

  #  |    2013    |    2014    |    2015    |    2016    |    2017    |    2018    |    2019    |    2020    |    2021    |    2022    |    2023    |    2024    |
      JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND 
 ----|------------|------------|------------|------------|------------|------------|------------|------------|------------|------------|------------|------------|
 506 |        ====|=           |            |            |            |            |            |            |            |            |            |            |
 

# | 2001 | 2002 | 2003 | 2004 | 2005 | 2006 | 2007 | 2008 | 2009 | 2010 | 2011 | 2012 | JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND ----|------------|------------|------------|------------|------------|------------|------------|------------|------------|------------|------------|------------| 505 | | | | | | | | | =|== | | | 504 | | | | | | | | | === | | | | 501 | | | | | | | |= | | | | | 502 | | | ===|============|======== | | | | | | | | 503 | | | ========|============|======== | | | | | | | |
# | 1989 | 1990 | 1991 | 1992 | 1993 | 1994 | 1995 | 1996 | 1997 | 1998 | 1999 | 2000 | JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND JFMAMJJASOND ----|------------|------------|------------|------------|------------|------------|------------|------------|------------|------------|------------|------------|
General AIPS FITLD issues
Specific VLBA archive issues:
        # BeginEndArchive fixed? Issue (follow links)Notes

501 2008 Jan 04 2008 Jan 18 not fixed Weather table
502 2003 Q4 2005 Aug 15 fixed 2005 Aug 15 Phased Array Sensitivity Phased array only
503 2003 May 2005 Aug 08 not fixed EOP errors
504 2009 Sep 21 2009 Nov 26 fixed 2010 Jan 03 AN file error preprocessed archive files only
505 2009 Dec 23 2010 Feb 01 not fixed Clock errors few DiFX projects
506 2013 Nov 2014 Jan not fixed sensitivity and cable swap KP
 



 
AIPS task FILLM issues:
 
Occasionally coding updates to FILLM introduced bugs.
Problem start: 1970
Problem fixed:
Archive fixed:
Workaround: Not readily available; reload data.
Last update: Monday, 09-Mar-2009 11:30:41 MDT by L.O. Sjouwerman
Please read the AIPS letter or check the AIPS AIPS patches. Alternatively search the history of the current version (CHANGE.DOC) for FILLM to see if you are affected. If so and you have an old version of AIPS, please reinstall a more recent version or if you are current, run the MidNightJob
Back
 

 
1 : EVLA antennas included in the array.
 
First few EVLA antennas in the array.
Problem start: 2006 July/August
Problem fixed:
Archive fixed:
Workaround: For problems with the first few EVLA antennas, delete the data taken with these 1-3 antennas.
Last update: Friday, 24-Apr-2009 15:45:42 MDT by L.O. Sjouwerman
As of 1 August 2006, all regular observing programs were given the EVLA antennas that had returned to operations (earlier for test programs). They are expected to give reasonable data most of the time, but the early days of the transition may have introduced bad performance or unexpected artifacts at the few EVLA antennas in the array. Probably the best and easiest solution is to delete the few visibilities observed with these antennas. Note that the EVLA antennas prior to the C array of 2006 have no antenna positions.
Back
 

 
2 : Post-MODCOMP uvw errors
 
New control software calculated u,v, and w coordinates wrongly.
Problem start: 2007 June 28
Problem fixed: 2007 July 5
Archive fixed: 2007 August 1
Workaround: Reload data from the archive or run UVFIX on the data.
Last update: Friday, 01-May-2009 15:12:51 MDT by L.O. Sjouwerman
This item relates to TWO similar issues in this time range
The MODCOMP computers that have run the VLA for many years were replaced by the EVLA monitor and control system on June 28, 2007. We have discovered that from that time until July 5, 18:20 UT, the u's v's and w's were written to the VLA data archive with the wrong sign. The data in the archive were corrected on July 10, 16:00 UT.
A problem with the online calculation of negative u's, v's, and w's has been discovered for all data taken since the VLA's MODCOMP computers were replaced by the EVLA monitor and control system on June 27, 2007. All astronomical projects observed between June 28, 2007, 09:00 UT, and August 1, 2007, 23:45 UT, are affected. (Note that this problem is separate from the uvw sign error that affected data between June 28 and July 5.)
 Projects affected:

AB1233, AB1239, AB1245, AB1246, AB1248, AB1251, AB1254, AB1256, 
AB1257, AB1278, AC856, AC874, AC879, AC888, AD562, AF452, AF456, 
AG744, AG745, AG753, AG756, AH939, AJ337, AK634, AK656, AL693, 
AL698, AM889, AM902, AM904, AM910, AN129, AR637, AR638, AR642, 
AR646, AS887, AS899, AS903, AS911, AT342, AT343, AT345, AW703, 
AY178, BB240, BC173, S8398, S8463, S8531, S8723, STUDE1, STUDE2
Back
 

 
3 : Timing error
 
EOP applied incorreclty
Problem start: 2009 January 14
Problem fixed: 2009 March 08
Archive fixed:
Workaround: (algorithm currently investigated) Make-up observations have been arranged.
Last update: Thursday, 23-Apr-2009 17:33:38 MDT by L.O. Sjouwerman
The VLA observations below were afflicted with a time error of about a second, due to improper application of the Earth Orientation Parameters. A time-correction scheme with the AIPS task CLCOR is not yet available, but may eventually become available (the archive data will not be fixed).

Affected data:

StartIATDate-Time  Code

2009-03-01  00:00  AM978     2009-02-28  23:06  AM978     2009-02-28  21:05  AB1301
2009-02-28  20:06  AR685     2009-02-28  19:36  AB1321    2009-02-28  09:37  SA598  
2009-02-28  07:38  AM975     2009-02-27  19:40  AE172     2009-02-21  21:03  ST001  
2009-02-20  17:07  AB1314    2009-02-14  17:01  AH984     2009-02-14  16:31  AB1321
2009-02-14  11:58  AW743     2009-02-14  00:04  AG807     2009-02-13  23:33  AB1321
2009-02-13  22:03  AG807     2009-02-07  22:58  AB1320    2009-02-07  12:00  AK706 
2009-02-06  23:01  AB1320    2009-01-31  13:27  AR687     2009-01-31  09:28  AM941 
2009-01-30  20:28  AR685


Back
 

 
4 : Online flagging erratic
 
Online flagging not always properly applied
Problem start: 2008 March/April
Problem fixed: yes
Archive fixed: not fixed
Workaround: Carefull inspection of data
Last update: Thursday, 23-Apr-2009 16:47:27 MDT by L.O. Sjouwerman
During one day in March 2008 and a three-day period in April 2008, online flagging was not always applied in all cases. The most common effect is that antennas did not always get flagged while slewing between scans. We recommend particular care while inspecting and editing data taken in those time intervals.
   Projects potentially affected by online flagging problems.
   Dates and times in UT.

   Project Date       begin  end     Project Date       begin  end

   AG778   March 6    05:44  07:43   AM932   March 6    07:43  08:42
   AM932   March 6    10:12  12:42   AR661   March 6    12:42  14:41
   AM932   March 6    14:41  17:11   AE165   April 15   23:32  04:32
   AS929   April 16   04:32  05:02   AS945   April 16   05:02  06:01
   AE165   April 16   06:01  11:00   AH967   April 17   08:27  15:56
   BM257   April 17   15:56  16:26   AB1285  April 18   00:25  09:23
   AH868   April 18   09:23  10:53   AR642   April 18   10:53  11:53
   AW710   April 18   11:53  12:53   AR642   April 18   12:53  13:52
   AR642   April 18   14:22  15:22   AT360   April 18   15:22  21:21

Back
 

 
5 : IAT clock error
 
A clock timing error
Problem start: 2008 January 4
Problem fixed: 2008 January 24
Archive fixed: not fixed
Workaround: Project segments have been reobserved; or disregard EVLA antennas.
Last update: Friday, 24-Apr-2009 15:38:48 MDT by L.O. Sjouwerman
An error occurred in the setting of the clock that drives the VLA antennas and the VLA correlator, affecting all astronomical data obtained between Jan 4, 02:18 IAT, and Jan 7, 18:04 IAT, and on Jan 24 (during AH927). The time error was sufficiently small (~50 ms) that the effect on VLA observations is negligible. However, the EVLA antennas, which do not use that clock, were out of sync with respect to the VLA correlator during that time interval. The effect of this out-of-sync condition is that:
- VLA-EVLA baselines have reduced sensitivity and calibration difficulties
- EVLA-EVLA baselines have very large (~100%) closure errors
For most purposes, the EVLA antennas will be unusable. The overall effect on your data will be a loss in sensitivity.
   Projects potentially affected by this:
Jan 4 - Jan 7: AD574, AH884, AH927, AK678, AL695, AR642, AR650, AS887
Jan 24:        AH927

Back
 

 
6 : Conjugated phases
 
Incorrect sideband being set for certain spectral line projects
Problem start: 2007 Jul 30
Problem fixed: 2007 Sep
Archive fixed: 2008 Apr 22
Workaround: Reload data from the archive or inspect data and use FLOPM with OPCODE'VLAE'
Last update: Thursday, 23-Apr-2009 17:20:53 MDT by L.O. Sjouwerman
For a limited time period during July-September 2007 the incorrect sideband information was occasionally being set by the VLA correlator for certain spectral line projects. The resulting effect on data is that the direction of the frequency labelling was reversed, and the phases were conjugated. A table of the dates/times affected is given below, and one or more of your observations were compromised by this problem. We are working on fixing the data in the online archive, but it will take a few weeks to complete. If you have already started processing your data there is a new AIPS task FLOPM, available in the frozen 31DEC07 version of AIPS, and in the development 31DEC08 version. Specifying OPTYPE='VLAE' will reverse the frequency labelling and conjugate the phases. The time range of data to be corrected must also be specified explicitly.
 Projects, frequencies, and IAT dates/times affected by frequency
            labelling and phase conjugation problem:

 AF456, X band:    Jul 30 from beginning  to end (C band is OK)
 AC856, L band:    Sep 09 from 17:34:15.8 to end
 AC882, 4&P bands: Sep 01 from beginning  to end
 AF440, L band:    Sep 04 from 15:34:22.5 to 15:51:21
 AK664, C band:    Sep 07 from 05:46:32.5 to end
 AM889, L band:    Aug 23 from 13:58:01.7 to end
                   Aug 26 from beginning  to 10:01:28
                   Sep 06 from 13:29:01.7 to 13:32:01 and
                          from 14:00:01.7 to end
                   Sep 12 from 11:54:51.7 to end
 AR659, L band:    Sep 20 from 04:56:11.7 to end


Back
 

 
7 : Incorrect system temperature
 
Nominal sensitivity and system temperature wrong for antennas 11 and 19
Problem start: 2007 June 28
Problem fixed: 2007 August 21
Archive fixed: not fixed
Workaround: Reload data using a patched FILLM
Last update: Thursday, 23-Apr-2009 17:36:45 MDT by L.O. Sjouwerman
For data taken between June 27 and August 21 antennas 11 and 19 had an incorrect nominal sensitivity and system temperature stored with the archival data. This can be identified by zeroes for the system temperature in plots of Tsys in the TY table using SNPLT. Unfortunately AIPS has not been calculating the weights for these antennas correctly when loading the data using FILLM.
A patch dated September 28, 2007, is available for the 31DEC06 version of AIPS that handles this correctly.
For the 31DEC07 version of AIPS, a midnight job run on September 22, 2007, or later is needed.
You will need to update your version of AIPS and reload your data to obtain the correct weights for the affected antennas. Any flagging that has already been carried out is probably fine and FG tables can be copied directly to the new dataset using TACOP.
Alternatively, if you already have fully calibrated data in a single source file, you can run WTMOD on that file with: NOISE=1; NOISE(11)=1/3; NOISE(19)=NOISE(11)
Projects that may have been affected:

    AB1233, AB1239, AB1245, AB1246, AB1248, AB1250, AB1251, AB1254
    AB1256, AB1257, AB1258, AB1278, AC843, AC856, AC874, AC879, AC881
    AC884, AC888, AC908, AC909, AD562, AD565, AF452, AF456, AG744, AG745
    AG752, AG753, AG756, AG757, AG777, AH939, AH941, AJ337, AK634, AK656
    AL693, AL696, AL698, AL703, AM889, AM902, AM904, AM910, AN129, AO219
    AO223, AR637, AR638, AR642, AR646, AS887, AS897, AS899, AS903, AS911
    AS925, AT342, AT343, AT345, AU119, AW705, AY178, S8531

Back
 

 
8 : Pointing errors
 
Pointing solutions not applied to antennas 1-9
Problem start: 2007 June 29
Problem fixed: 2007 August 29
Archive fixed: not fixed
Workaround: Not available.
Last update: Thursday, 23-Apr-2009 17:40:37 MDT by L.O. Sjouwerman
It was discovered that between the dates of June 27, 2007, and August 29, 2007 inclusive, reference pointing solutions were not being applied to antennas numbered 1 through 9. The effect on your data will be the following:
1) Pointing offsets may be different for your absolute flux calibrator from your phase calibrator and target source. Make sure you exclude antennas 1-9 when bootstrapping flux calibration using GETJY in AIPS, otherwise the absolute flux calibration will be highly uncertain.
2) The overall sensitivity may be somewhat lower than expected.
3) Extended sources may suffer from poor image fidelity if antennas with poor pointing are included.
Projects that may have been affected:

  AB1233, AB1251, AB1258, AC843, AC879, AC884, AC888, AD565, 
  AF452, AF454, AH941, AH942, AK634, AK656, AL698, AL703, AL704, 
  AM910, AO219, AR642, AS887, AS897, AT342, AT343, AY178, BC173

Back
 

 
9 : Incorrect VLA headers
 
Incorrect frequency increment for spectral line data
Problem start: 2007 September 14
Problem fixed: 2007 September 19
Archive fixed: 2007 September 24
Workaround: Reload data from the archive.
Last update: Friday, 24-Apr-2009 15:34:07 MDT by L.O. Sjouwerman
Due to an error in the EVLA online system, spectral line data taken between September 13, 2007, and September 18, 2007, had incorrect increments on the frequency axis. Rather than reporting the channel width it instead reported the total bandwidth, or in some circumstances, 50 MHz. This should be evident by running IMHEAD in AIPS.
Possibly affected:

Sept-14  AF454
Sept-15  AF454, AR659, AM909, AC879
Sept-16  AC879, AR659, AB1280
Sept-17  AC910, AM909
Sept-18  AR659
Back
 

 
10 : Pre-MODCOMP uvw errors
 
MODCOMP VLA control computers (pre-EVLA) calculated u,v, and w coordinates wrongly.
Problem start: 1979 June
Problem fixed: Not fixed
Archive fixed: Not fixed
Workaround: Run UVFIX on the data.
Last update: Friday, 01-May-2009 15:12:51 MDT by L.O. Sjouwerman
The MODCOMP computers that have run the VLA for many years were calculating the uvw's wrongly. While the uvw errors are small they are affecting long time baseline astrometry and/or astromomy attempted between data on both sides of the switch from MODCOMP to EVLA control computers on 2007 June 27. This appears as a rotation on the sky between the two epochs.
Back
 

 
11 : Phase jumps while Doppler tracking
 
Doppler tracked observations show phase jumps on EVLA antennas
Problem start: 2006
Problem fixed: 2008 April 09
Archive fixed: Not fixed
Workaround: Not available; discard EVLA data.
Last update: Friday, 24-Apr-2009 16:30:46 MDT by L.O. Sjouwerman
It seems that possibly ALL observations on the EVLA (including those done before turning off the Modcomps) for which the sky frequency of the target and calibrator are not the same (as is common for doppler-tracked observations) suffer from phase jumps meaning that the target cannot be properly calibrated.
Projects affected - any using EVLA antennas. The list below is only 
complete for projects after 2007 June 27, but observations prior to 
that date may also suffer from this even if not listed here:

Date     Project  Frequency       Antennas used

20070811 AA314    4.8284  GHz     16 VLA 9  EVLA 4  OUT
20070903 AA314    6.6666  GHz     0  VLA 10 EVLA 19 OUT
20070811 AA314    6.6667  GHz     0  VLA 9  EVLA 20 OUT
20070811 AA314    6.6667  GHz     16 VLA 9  EVLA 4  OUT
20070818 AB1250   1.6123  GHz     16 VLA 10 EVLA 3  OUT
20070927 AB1258   22.2271 GHz     15 VLA 11 EVLA 3  OUT
20071004 AB1258   22.2281 GHz     15 VLA 11 EVLA 3  OUT
20071005 AB1258   22.2319 GHz     15 VLA 11 EVLA 3  OUT
20070921 AB1258   22.2363 GHz     15 VLA 11 EVLA 3  OUT
20070824 AB1258   22.2403 GHz     16 VLA 10 EVLA 3  OUT
20070810 AB1258   6.6689  GHz     16 VLA 9  EVLA 4  OUT
20070816 AB1258   6.67    GHz     16 VLA 10 EVLA 3  OUT
20071116 AC0904   6.6668  GHz     0  VLA 12 EVLA 17 OUT
20071101 AC0904   6.6673  GHz     0  VLA 12 EVLA 17 OUT
20071031 AC0904   6.6677  GHz     0  VLA 12 EVLA 17 OUT
20070708 AC856    1.6653  GHz     15 VLA 9  EVLA 5  OUT
20070921 AC888    22.2289 GHz     15 VLA 11 EVLA 3  OUT
20070921 AC888    42.8088 GHz     15 VLA 11 EVLA 3  OUT
20070921 AC888    43.1102 GHz     15 VLA 11 EVLA 3  OUT
20080127 AC904    6.6677  GHz     0  VLA 13 EVLA 16 OUT
20080126 AC904    6.6677  GHz     13 VLA 13 EVLA 3  OUT
20070917 AC910    1.6117  GHz     15 VLA 11 EVLA 3  OUT
20070917 AC910    1.6119  GHz     15 VLA 11 EVLA 3  OUT
20070917 AC910    1.6653  GHz     15 VLA 11 EVLA 3  OUT
20071202 AF440    1.6121  GHz     14 VLA 12 EVLA 3  OUT
20070906 AF440    1.6123  GHz     15 VLA 11 EVLA 3  OUT
20071213 AF465    22.2336 GHz     14 VLA 12 EVLA 3  OUT
20070810 AH941    18.5042 GHz     0  VLA 10 EVLA 19 OUT
20070924 AI123    6.1165  GHz     15 VLA 11 EVLA 3  OUT
20071123 AK0680   22.2337 GHz     14 VLA 12 EVLA 3  OUT
20071123 AK0680   6.6671  GHz     0  VLA 12 EVLA 17 OUT
20071124 AK0680   6.667   GHz     0  VLA 12 EVLA 17 OUT
20070901 AL704    24.1424 GHz     16 VLA 10 EVLA 3  OUT
20071217 AL707    21.3013 GHz     14 VLA 12 EVLA 3  OUT
20071215 AL707    45.2868 GHz     14 VLA 12 EVLA 3  OUT
20080126 AP500    1.7214  GHz     13 VLA 13 EVLA 3  OUT
20071005 AP500    1.7215  GHz     15 VLA 11 EVLA 3  OUT
20080128 AP529    4.8348  GHz     13 VLA 13 EVLA 3  OUT
20071113 AS660    22.2342 GHz     14 VLA 12 EVLA 3  OUT
20071112 AS660    22.2346 GHz     14 VLA 12 EVLA 3  OUT
20071222 AS800    42.8255 GHz     14 VLA 11 EVLA 4  OUT
20071130 AS858    1.612   GHz     14 VLA 12 EVLA 3  OUT
20070801 AS911    1.6655  GHz     16 VLA 10 EVLA 3  OUT
20070731 AS911    1.7206  GHz     16 VLA 10 EVLA 3  OUT
20070729 AS911    1.7206  GHz     16 VLA 9  EVLA 4  OUT
20070627 AW3H2    4.8306  GHz     17 VLA 10 EVLA 2  OUT
20070627 AW3OHB   6.6699  GHz     0  VLA 10 EVLA 19 OUT
20071207 AY184    6.6679  GHz     0  VLA 12 EVLA 17 OUT
20071003 BM272    22.2334 GHz     15 VLA 11 EVLA 3  OUT
20071008 BM272    22.2341 GHz     15 VLA 11 EVLA 3  OUT
20071005 BM272    22.2353 GHz     15 VLA 11 EVLA 3  OUT

Back
 

 
12 : Mozaic mode not working for EVLA
 
Mozaic mode not working for EVLA antennas
Problem start: 2006
Problem fixed: 2007 March 2
Archive fixed: not Fixed
Workaround: Not readily available; disregard EVLA data.
Last update: Friday, 24-Apr-2009 16:42:42 MDT by L.O. Sjouwerman
Mozaic mode did not work for EVLA antennas prior to 2007 March 2
Back
 

 
13 : DC offset in 25 MHz line mode
 
DC offset in 25 MHz line mode
Problem start: 2007 June 27
Problem fixed: Fixed?
Archive fixed: Not fixed
Workaround: Not readily available. Use AIPS tasks
Last update: Friday, 24-Apr-2009 16:41:26 MDT by L.O. Sjouwerman
The correlator controller caused a DC offset in 25 MHz spectral line mode, since September 26, 2006 (Supposedly this was fixed by turning off self-test for all 25 MHz observations)
Back
 

 
14 : High noise in 12.5 MHz bandwidth mode
 
High noise in 12.5 MHz line mode
Problem start: 2007 June 27
Problem fixed: Not fixed - discouraged 12.5 MHz observing until WIDAR arrives
Archive fixed: Not fixed
Workaround: Not readily available; do not use for observations until WIDAR.
Last update: Friday, 24-Apr-2009 16:42:36 MDT by L.O. Sjouwerman
The correlator controller introduces a high noise in 12.5 MHz spectral line observations - do not use 12.5 MHz bandwidth.
Back
 

 
15 : Random phase jumps
 
Phase jumps appear on EVLA antennas
Problem start: 2009 March 10
Problem fixed: 2009 March 19
Archive fixed: Not fixed
Workaround: Not available. Affected projects were reobserved.
Last update: Monday, 27-Apr-2009 10:07:27 MDT by L.O. Sjouwerman
A kernel upgrade to our central time servers caused them to miscalculate internal clock drift. Over the course of a day their clock error became greater than the 20ms acceptable limit causing a phase jump problem on EVLA - EVLA and EVLA - VLA baselines (the EVLA antennas have phase jumps). The phase jumps generally occur on most or all EVLA antennas at the same times. The times of the jumps are random, and can occur at the few per hour rate; although about once per hour or so is more typical, and there are possibly longer periods of data that are not affected. All data between Mar 10, UT 13:00 and Mar 19, UT 09:00, is affected. Projects were reobserved.
Back
 

 
16 : Tsys/timing problem
 
A timing error has corrupted system temperature values
Problem start: 2009 November 17
Problem fixed: 2009 November 20
Archive fixed: Not fixed
Workaround: See below.
Last update: Monday, 04-Jan-2010 16:30:03 MST by L.O. Sjouwerman
From 12:00 MST on November 17, 2009, through approximately 17:00 on November 20, 2009, there was a timing error on one of the computers at the VLA site that resulted in bad values of the system temperature being passed through the online system to archival data. If you load your data using FILLM in AIPS scaling by the nominal sensitivity (the default) your data will be corrupted. You must load your data in raw correlation coefficients in FILLM by setting
        DOWEIGHT = 1
        CPARM(2) = 2048
(see the help file for FILLM for further details). The use of raw correlation coefficients makes the data more susceptible to gain variations as a function of elevation, and care should be taken to try to match the elevation for flux density bootstrapping. We apologise for this inconvenience. Please let us know if you have any further questions about your data.
  Projects affected:
   AB1323   AD613   AM991   AR700
   AC963    AF484   AP570   AS992
   AD612    AK718   AR699   CALSUR

Back
 

 
17 : Doppler tracking with *.obs files in dynamic time
 
Doppler correction was calculated for the wrong date
Problem start: 2006 ~December
Problem fixed: 2009 December 18
Archive fixed: Not fixed
Workaround: See below.
Last update: Monday, 04-Jan-2010 16:30:03 MST by L.O. Sjouwerman

Dear PI,

We have recently discovered that Doppler-tracked data observed in the VLA dynamic queue are Doppler tracked by the new EVLA online system to the LST date in the header of the submitted observe file, rather than the date of observation. If no date appears in the header the online system uses the date of observation. In extreme cases a spectral line may be shifted entirely out of the requested passband of the VLA, but at the very least lines will likely appear at the wrong velocity if processed in the normal way by AIPS. Scheduling blocks created by the OPT are not affected. You may use the online DOPSET tool at http://www.vla.nrao.edu/astro/guides/dopset/, specifying first the LST date in the observe file and then that of the observation, to find out the expected frequency shift.

For data processed by AIPS the correct Doppler tracking must be derived offline. The precise steps depend on the version of AIPS used. For AIPS versions 31DEC09 or later the fix can be done using either the multisource file or a calibrated and SPLIT single-source file. Make sure to download the frozen version of 31DEC09 or run the midnight job to obtain the latest updates *before* loading your data using FILLM. For AIPS versions 31DEC08 or earlier (or 31DEC09 versions obtained prior to the 31DEC09 code freeze) the multisource file must be used.

Multi-source file: in most cases the source (SU) table will have the requested source velocity, rest frequency, velocity type, frame definition, and velocity reference pixel already set by FILLM, it's just that the observed topocentric frequencies are not consistent with these values for the date of observation. All that needs to be done is to run CVEL, applying the bandpass calibration if this has not already been done, to resample the data onto the requested velocity axis. Note that if there are multiple frequency (FQ) IDs each FQID will have to be processed separately. If for any reason the velocity information is not in the SU table, SETJY can be used to set it prior to running CVEL.

Single-source file: use CVEL to specify the velocity parameters using APARM(1)-(6), and run to resample the data onto the new velocity axis.

If your spectral line is strong and spectrally undersampled you may see Gibbs ringing in the output spectrum following CVEL. In this case you should consider using Hanning smoothing to suppress the ringing.

Data processed by CASA will be labelled with the correct velocity, since CASA interpolates onto the requested velocity axis from the observed topocentric frequencies of date, and does not rely on the velocity information provided by the online system. The data do undergo some spectral smoothing in this process.

This Doppler tracking problem applies to EVLA antennas included in all dynamically observed projects from the beginning of 2006 December onwards. Observe files requesting Doppler tracking submitted to the dynamic queue as of December 18, 2009 have already been processed by NRAO staff to remove the LST date/time from the header.


  Projects potentially affected:
   AA320   AA329   AB1258  AB1316  AC826 
   AC888   AC904   AC910   AF459   AF460 
   AF465   AF483   AG810   AH1003  AH941
   AH991   AI123   AI128   AI135   AJ352 
   AK664   AM874   AM912   AM914   AM974 
   AM981   AR676   AS884   AS909   AS911 
   AS983   AW711   AW760   AY184   AY191 
   AY196   AZ186   BM257   BM272   BR145 
   ST002   ST003

Back
 

 
18 : System temperatures at Ka band
 
Wrong system temperature for antennas 5, 6, 7, 19, 20, 23, and 27 at Ka-band.
Problem start: 2009 June 17
Problem fixed: 2010 January 10 23:00 UT
Archive fixed: Not fixed
Workaround: See below
Last update: Thursday, 28-Jan-2010 11:40:16 MST by L.O. Sjouwerman

Between June 17, 2009, and approximately 23:00 UT on January 10, 2010, the EVLA online system had erroneous values for the temperature of the calibration noise diodes (Tcals) for antennas 5, 6, 7, 19, 20, 23, and 27 at Ka-band. When data from these antennas are loaded into AIPS or CASA they are effectively raw correlator coefficients multiplied by a constant, and are not scaled by the nominal system temperature. Changes in system temperature due to elevation or other effects such as weather cannot be fully accounted for in the subsequent data reduction.

If an observation includes one of the VLA's primary flux calibrators at the same elevation as the gain calibrator the effect of this error can be minimized by limiting the elevation range of the data used for bootstrapping the flux density of the gain calibrator. If there is no such observation then the absolute flux uncertainty in the calibration is increased, probably by 10% or more.


  Projects affected:
   AI129   AI136   AI137   AK717   AM1002  
   AP572   AR692   AR700   AR701   AS979   
   AS982   AS994   AW764

Back
 

 
19 : Bad Stokes V
 
Bad Stokes V in EVLA data
Problem start: 2010 March 01
Problem fixed: Until further notice
Archive fixed: Not possible
Workaround: Not readily available; obvious Zeeman observations on hold
Last update: Tuesday, 18-Jan-2011 13:05:08 MST by L.O. Sjouwerman
Stokes V data is unreliable due to the frequency shift algorithm. Until further notice do not use Stokes V for science (i.e. Zeeman splitting measurements)
    Projects affected - essentially every EVLA project since March 1st
    2010 until the problem was (is) fixed. In particular the following
    projects that were observed already (and thus are in the archive)
    with the intention to obtain Zeeman splitting measurements:
    AM1009, AS1011, AS1022, 10B-109, 10B-123
    

Back
 

 
1001 : CASA
 
importasdm (not really an EVLA issue)
Problem start: 2009 June 17
Problem fixed: (sometime fall)
Archive fixed: no fix needed
Workaround: Reload data.
Last update: Friday, 07-Dec-2012 14:12:37 MST by L.O. Sjouwerman

Back
 

 
1002 : Scans missed
 
Some scheduled scans were not observed
Problem start: 2009 December 31
Problem fixed: Intemittently recurring
Archive fixed: not fixed
Workaround: Not readily available.
Last update: Friday, 07-Dec-2012 14:35:11 MST by L.O. Sjouwerman
One or more scheduled scans are missing. In our experience this can mean two things: either data for some scans were not recorded to the archive, or data belonging to one scan were merged with a neighboring scan. Please inspect your data carefully to find out which of the two cases applies; if neighboring scans were inadvertently merged, flag as appropriate.
Back
 

 
1003 : BDFs missing
 
Some expected BDFs were not created
Problem start: 2009 December 31
Problem fixed: Intermittently recurring
Archive fixed: not fixed
Workaround: Not readily available.
Last update: Friday, 07-Dec-2012 14:50:10 MST by L.O. Sjouwerman
One or more scheduled scans are missing. In our experience this can mean two things: either data for some scans were not recorded to the archive, or data belonging to one scan were merged with a neighboring scan. Please inspect your data carefully to find out which of the two cases applies; if neighboring scans were inadvertently merged, flag as appropriate.
Back
 

 
1004 : Bad data
 
EVLA system problems
Problem start: 2010 May 22
Problem fixed: 2010 May 25
Archive fixed: not fixed
Workaround: Not readily available.
Last update: Friday, 07-Dec-2012 14:13:07 MST by L.O. Sjouwerman

Back
 

 
1006 : Clock problem
 
Problem with clock signals, data corrupted
Problem start: 2011 May 15
Problem fixed: 2011 May
Archive fixed: not fixed
Workaround: Not readily available.
Last update: Friday, 07-Dec-2012 14:13:28 MST by L.O. Sjouwerman

Back
 

 
1007 : No SysPower
 
System Power table missing
Problem start: 2011 July 28
Problem fixed: 2011 August 1
Archive fixed: not fixed
Workaround: Calibrate without (correlator coefficients).
Last update: Friday, 07-Dec-2012 14:13:53 MST by L.O. Sjouwerman
This period the System Power information was not included in the data, but previously it was not either and not suggested for improved calibration - it is not essential (but helps to have it).
Back
 

 
1008 : Data acquisition problems
 
Severe amplitude variations IFs B and C
Problem start: 2011 July 7 (16:52 UT)
Problem fixed: 2011 July 11 (21:46 UT)
Archive fixed: not fixed
Workaround: Apply switched power corrections
Last update: Friday, 07-Dec-2012 14:14:03 MST by L.O. Sjouwerman
Not all projects were affected but those that were had severe amplitude variability on IFs B and C and would need correction to be usable.
Back
 

 
1009 : CBE integration failed
 
Correlator only averaged for a single second every tick mark
Problem start: 2011 September 20
Problem fixed: 2011 December 3
Archive fixed: No fix possible
Workaround: Not readily available; data will have reduced sensitivity by Sqrt(Tint)
Last update: Friday, 07-Dec-2012 14:14:11 MST by L.O. Sjouwerman
The CBE (correlator back-end) averages visibilities over some time interval. With the start of wideband observations in D-array 2011 it was suggested to increase it to e.g. 3, 5 or 10 seconds (depending on your science case) to keep the output data set sizes relatively small. However, only one second of data ended up in each of the 'averaged' visibilities. The effect is that the time on source is reduced by a factor of the integration time, and thus the effective 'theoretical' RMS noise a factor Sqrt(Tint) higher than expected. Elegible projects will be offered make-up time as much as possible.
Back
 

 
1010 : Opacity corrections
 
weather station
Problem start: 2011 December 23, 19:12 UT
Problem fixed: 2012 January 12, 23:37 UT
Archive fixed: N/A
Workaround: Use seasonal model only
Last update: Friday, 07-Dec-2012 14:14:19 MST by L.O. Sjouwerman
From 23 December 2011, 19:12 UT to 12 January 2012, 23:37 UT the weather station located on the EVLA site failed to produce reliable data. This has consequences for the zenith opacities systems such as CASA and AIPS derive. During the time interval above these zenith opacities should be based on the seasonal model only instead of a weighted average of actual weather data and the seasonal model. This can be accomplished as follows:

AIPS - delete version 1 of the CL table, and create a new version 1 by running the task INDXR with BPARM(1)=0 and BPARM(10)=-1.

CASA - derive the zenith opacity by running the contributed task plotWX with seasonal_weight=1.0. For more information on plotWX see
http://casaguides.nrao.edu/index.php?title=CASA_EVLA_Scripts

Back
 

 
1011 : Spectral splatter
 
Spectral splatter and Stokes V effects
Problem start: 2010 March 01
Problem fixed: 2012 April (or 2011 August, see below)
Archive fixed: Not Fixed
Workaround: Not readily available.
Last update: Friday, 07-Dec-2012 14:14:27 MST by L.O. Sjouwerman
EVLA observations of strong lines with high spectral resolution were subject to an unanticipated spectral response ("spectral splatter") described in detail in EVLA memoranda 148, 157, and 160 (Sault 2010, 2011, 2012). This significantly complicates the analysis of observations of strong lines with high spectral resolution. Polarization studies, which rely on the detection of subtle differences between strong signals, are particularly vulnerable, with the Zeeman effect being an unfortunate example. Data taken with the WIDAR correlator before August 2011 are the most severely affected and should not be used for any spectral line polarization studies, linear or circular. Data taken between August 2011 and April 2012 may be more reliable but should be treated with considerable caution. We believe that data taken after April 2012 are free from these effects, though as with all correlators very subtle, low-level artifacts may persist for particularly challenging observations -- see the aforementioned memoranda for details.
Back
 

 
1012 : OnLine Flagging
 
Too rigorous online flags
Problem start: 2012 May 15
Problem fixed: 2012 June 15
Archive fixed: 2012 June 22, 17h UT
Workaround: Check online flags carefully or re-retrieve the archival data.
Last update: Friday, 07-Dec-2012 14:14:35 MST by L.O. Sjouwerman
During the period May 15, 2012 to June 15, 2012 there was a condition in the online system of the Karl G. Jansky Very Large Array (VLA) that in some cases caused erroneous online flags to be written into the archived dataset. Application of those flags could result in data being flagged when it should not have been. Your project has been identified as one that may have been affected by this problem. The online flags have now been corrected in the raw archive data. If you have already downloaded your data in SDM/BDF format, or as a measurementset with online flags applied (the default in the Archive Access Tool), you might want to re-retrieve them to ensure you are not flagging good data. We apologise for any inconvenience this may cause. If you have any further questions about your VLA data please contact the NRAO Helpdesk at https://help.nrao.edu .
Potentially affected data:

  11B-002    11B-027    11B-177    11B-234    12A-010    12A-013    12A-017
  12A-041    12A-048    12A-059    12A-067    12A-087    12A-089    12A-099
  12A-144    12A-149    12A-172    12A-173    12A-182    12A-183    12A-195
  12A-201    12A-234    12A-240    12A-247    12A-256    12A-274    12A-275
  12A-279    12A-285    12A-286    12A-304    12A-335    12A-339    12A-363
  12A-394    12A-395    12A-400    12A-414    12A-424    12A-466    12A-467
  12A-469    12A-471    12A-474 
Back
 

 
1013 : BD tuning
 
Tuning problem with the BD baseband
Problem start: 2012 June 7
Problem fixed: 2012 July 24
Archive fixed: Not fixed
Workaround:
Last update: Friday, 07-Dec-2012 14:14:45 MST by L.O. Sjouwerman
During the period June 7 15, 2012 to July 24, 2012 there was a condition in the online system of the Karl G. Jansky Very Large Array (VLA) that in some cases caused the BD baseband to be untuned. This unfortunately happened during the observations and therefore cannot be corrected for in the archive data. Therefore the BD data should be examined carefully and in specific cases the unuasable data be flagged. We apologise for any inconvenience this may cause. If you have any further questions about your VLA data please contact the NRAO Helpdesk at https://help.nrao.edu .
Potentially affected data:


Jul 21 08:11    2012/07/12A-319.sb10489979.eb11228111.56129.46362222222
Jul 21 11:11    2012/07/12A-319.sb10489979.eb11228112.56129.59135891204
Jul 22 10:07    2012/07/12A-319.sb10489979.eb11230336.56130.54722599537

Jul 20 02:17    2012/07/12A-479.sb11085665.eb11197287.56128.30393686343

Jul 17 01:43    2012/07/12A-275.sb10095479.eb11190292.56125.19718564815
Jul  1 02:31    2012/07/12A-275.sb10095479.eb10905468.56109.23049581019
Jun 24 02:59    2012/06/12A-275.sb10095479.eb10737382.56102.24956340278
Jun 23 03:02    2012/06/12A-275.sb10110935.eb10736956.56101.25229523148
Jun 20 21:41    2012/06/12A-275.sb10086204.eb10733741.56099.0707805787
Jun 20 19:42    2012/06/12A-275.sb10086204.eb10733740.56098.98784204861
Jun 11 22:16    2012/06/12A-275.sb10086204.eb10659226.56090.09468880787

Back
 

 
1014 : timing error
 
Array timing problem
Problem start: 2013 February 5 22:00 UT
Problem fixed: 2013 February 11 20:00 UT
Archive fixed: Not fixed
Workaround:
Last update: Tuesday, 12-Feb-2013 18:03:42 MST by L.O. Sjouwerman
An issue with communications introduced time errors of 0-4 seconds at the phase center. This effectively caused phase jumps, field rotation and antenna position errors throughout the period. The affected scheduling blocks are put back in the observing queue. We apologise for any inconvenience this may cause. If you have any further questions about your VLA data please contact the NRAO Helpdesk at https://help.nrao.edu .
Back
 

 
1015 : Incomplete data set
 
Scheduling block terminated early
Problem start: 2013 January 20
Problem fixed: (no fix possible)
Archive fixed: (check if this SB is reobserved)
Workaround: Not readily available; disregard data for pipelining.
Last update: Monday, 01-Apr-2013 15:32:04 MDT by L.O. Sjouwerman
The data set is incomplete (e.g. missing essential calibrators needed for calibration pipeline operations) because operations teminated the observing block early due to changed conditions (weather, hardware, logistics, etc). Typically such a terminated scheduling block or its replacement is observed to completion at a later date.
Back
 

 
1016 : Slewing flags
 
Incorrect flagging during slew
Problem start: 2013 December 20
Problem fixed: 2014 February 14
Archive fixed: Not fixed.
Workaround: "QUACK" your data (see below).
Last update: Thursday, 24-Apr-2014 16:40:38 MDT by L.O. Sjouwerman
The position error in the azimuth direction for one or more antenna was calculated incorrectly during slews. When the antennas are on-source there is no problem, so target data will be unaffected. However, during a slew from one source to another, if that slew is mostly in the azimuth direction, there may be data that should have been flagged but was not. This will almost never be a problem for short slews, such as are typical for cal-source-cal cycles. But for slews to bandpass/delay or flux density scale sources, which can be much longer, this may be a problem. During the period from December 20, 2013 to January 21, 2014 this problem is easy to see in your data, because only antennas 1-5 were affected. Inspection of the flags for scans following a long slew will show all other antennas flagged, but antennas 1-5 will not be flagged, if the problem is present. For the period from January 21, 2014 to February 14, 2014 it is more difficult to see the effect because all antennas were affected, but if the long slew is to a calibrator the antennas being off source will be easily seen in the calibrator data: the amplitudes will be low, and the phases noisy, but data may not be flagged. For the short slews in a cal-source-cal cycle, a simple solution is to "quack" the first 5-10 seconds of each scan. For the longer slews, the solution to the problem will depend on the details. Manual inspection of data will be necessary, along with some manual flagging. The standard VLA calibration pipeline can be downloaded and modified to do the necessary flagging and quacking. Instructions on downloading and running the pipeline can be found at https://science.nrao.edu/facilities/vla/data-processing/pipeline.
Back
 

 
1017 : Requantizer gain
 
3-bit gains inaccurate
Problem start: 2013 December 12
Problem fixed: 2014 March 11
Archive fixed: Not fixed.
Workaround: "QUACK" your data (see below).
Last update: Thursday, 24-Apr-2014 16:48:44 MDT by L.O. Sjouwerman
During the period from December 12, 2013 to March 11, 2014, there was a problem in our observing software that may affect the quality of data at the beginning of any scan that immediately follows a requantizer gain setting scan. Because we only use requantizer gain setting scans for 3-bit observing, it only affects projects that are using that hardware set-up. You are receiving this email because a project for which you are the PI had 3-bit data taken for it during this period. This email describes the problem, and potential fixes for it. On revising our recommendation for the time needed for requantizer scans from the original 90 seconds we started recommending 20 seconds, when in fact 30 seconds are needed. Any scan that immediately follows a requantizer gain set-up scan where that requantizer gain set-up scan had a duration of 20 seconds will therefore have 10 seconds of bad data at the beginning, while the requantizers were still being set. Scheduling blocks with requantizer gain scans 30 seconds or longer are not affected by this problem. Requantizer gain scans that are 20 seconds long but are followed by 10 seconds of slew time also may not be affected by this problem, but we advise observers to check their data carefully. If you determine that your data are affected by requantizer gain scans that are too short, a simple solution is to flag the first 10 seconds of any scan that follows a requantizer gain setting scan. The standard VLA calibration pipeline can be downloaded and modified to do the necessary flagging. Instructions on downloading and running the pipeline can be found at https://science.nrao.edu/facilities/vla/data-processing/pipeline.
Back
 

 
1018 : bad CMIB code
 
reference pointing or 3-bit failed
Problem start: 2014 April 9
Problem fixed: 2014 April 9
Archive fixed: Not fixed.
Workaround: No fix, disredgard data.
Last update: Friday, 25-Apr-2014 13:31:52 MDT by L.O. Sjouwerman
On April 9, 2014 a bad version of the CMIB code affected pointing and 3 bit scans. These data should be disregarded (the SBs were put back in the queue for reobservations).
Back
 

 
1019 # : P band polarization
 
P band polarization labeling incorrect
Problem start: 2014 May 29
Problem fixed: 2014 June 19
Archive fixed: NA
Workaround: Not readily available; use Stokes I only.
Last update: Friday, 19-Sep-2014 10:50:50 MDT by L.O. Sjouwerman
In the period above, the commissioning of P band mangled the P band polarization labeling. RR and LL were labeled for XX and YY, where at some point also XX and YY were reversed. The only science observing that may be affected by inconclusive polarization labeling in the archive is 14A-125 (3 observations during 2014 June 7/8).
Back
 

 
1020 # : CBE averaging reverses frequency axis
 
Frequency labeling incorrect
Problem start: 2015 June 2 23:00 UT
Problem fixed: 2015 June 11 12:20 UT
Archive fixed: 2015 August 28
Workaround: Download corrected data from the archive
Last update: Monday, 09-Nov-2015 15:29:47 MST by L.O. Sjouwerman
A bug in the software for the VLA's Correlator Back End (CBE) resulted in a subband-based reversal of the frequency axis in some VLA data. Observations carried out between 2015 June 2 23:00 UT and 2015 June 11 12:20 UT that utilized CBE time averaging (dump time > 1 sec) are affected by this issue.
This issue has now been resolved. If you use CASA, there is nothing special you need to do to reduce these data other than to obtain the corrected data from the archive after the Archive Fixed date above. For AIPS users, other than to obtain the corrected data, we note that if you use BDF2AIPS (or BDFIn) to load the SDM-BDF data, you will need to install a recent version of Obit: 1.1.516 dated 2015 August 08 or later (see https://svn.cv.nrao.edu/obit/linux_distro/). This Obit BDF2AIPS/BDFIn will load the data with the correct frequency labeling for processing, but the data may look reversed when displayed with POSSM. To avoid trouble in the data reduction path, reverse the channel order after loading into AIPS and before displaying or processing using the task FLOPM with default settings (i.e., OPCODE=' ').
Back
 

 
1021 # : zeroed visibility data
 
High fraction of zero's in visibility data
Problem start: 2010 January 1
Problem fixed:
Archive fixed:
Workaround: Process and determine if you're affected; if so reobserve
Last update: Wednesday, 23-Sep-2015 17:21:40 MDT by L.O. Sjouwerman
Since the installation of the WIDAR correlator in 2010, occassionally the correlator configuration causes pure zeroes in the visibility data. This fraction typically is low, but sometimes the fraction can be as high as over 70 percent. The actual fraction and location in the configuration (i.e. subband) determines the loss for science in either sensitivity or line detection. When we anticipate that science is impacted, we will try to indicate it with this error code, but unnoticed data sets with high fraction of pure zeroes in the data may persist.
Back
 

 
1022 # : timing error
 
High fraction of zero's in visibility data VLA experiences 0.367 second timing error
Problem start: 2015 November 18
Problem fixed: 2015 November 19
Archive fixed: no fix applied
Workaround: none
Last update: Monday, 14-Dec-2015 16:11:40 MST by Gustaaf van Moorsel
Data taken during the night of 18 to 19 November are affected by a VLA timing error of 0.367 seconds. The effect is a slow rotation of phases with time, and is mostly removed during calibration, depending on the cal-target distance. Since in all affected observations the calibrator - target distance is small (< 5 degrees) and the baselines short, data should be OK unless the science goal requires accurate astrometry.
Back
 

 
1023 # : delay error
 
Delay model error
Problem start: 2016 August 8
Problem fixed: 2016 November 15
Archive fixed: no fix applied
Workaround: See below
Last update: Thursday, 16-Feb-2017 14:31:40 MST by L.O. Sjouwerman
Data taken during the period of 9 August to 15 November 2016 are affected by an error in the atmospheric delay model used in the online software system at the VLA. Please see the web page at: https://science.nrao.edu/facilities/vla/data-processing/vla-atmospheric-delay-problem for a full description of the problem and a description of the correction for it in AIPS (31DEC17 or later) and CASA (4.7.1 or later).
Back
 


 
AIPS task FITLD issues:
 
Occasionally coding updates to FITLD introduced bugs.
Problem start: 1970
Problem fixed:
Archive fixed:
Workaround: Not readily available; reload data.
Last update: Monday, 09-Mar-2009 11:30:20 MDT by L.O. Sjouwerman
Please read the AIPS letter or check the AIPS AIPS patches. Alternatively search the history of the current version (CHANGE.DOC) for FITLD to see if you are affected. If so and you have an old version of AIPS, please reinstall a more recent version or if you are current, run the MidNightJob
Back
 

 
501 : Incorrect weather tables
 
Weather tables scrambled
Problem start: 2008 January 04
Problem fixed: 2008 January 18
Archive fixed:
Workaround: Not readily available; reload data.
Last update: Monday, 09-Mar-2009 14:26:07 MDT by L.O. Sjouwerman
The weather tables were not parsed correcly and are not usable in, e.g., APCAL.
Back
 

 
502 : Phased array sensitivity
 
Array not recognized as phased array
Problem start: 2003 Q4
Problem fixed: 2005 August 15
Archive fixed: 2005 August 15
Workaround: See below
Last update: Monday, 09-Mar-2009 15:06:47 MDT by L.O. Sjouwerman
The sensitivities for the phased VLA in the experiments below may be off from expected. Single dish VLA observations should not be affected.
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
Back
 

 
503 : Earth Orientation Parameter errors
 
Wrong EOP parameters were used in the corrlation
Problem start: 2003 May
Problem fixed: 2005 Aug 08
Archive fixed:
Workaround: Run CLCOR on the affected data.
Last update: Monday, 09-Mar-2009 14:49:33 MDT by L.O. Sjouwerman
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.
To fix the data use the new CLCOR capability, included in the 31DEC05 version of AIPS 9and later) 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.
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.
Back
 

 
504 : AN file error in preprocessed files
 
FITLD assigned the wrong sign to BY when antennas were added to AN
Problem start: 2009 September 21
Problem fixed: 2009 November 26
Archive fixed: 2010 January 03
Workaround: Inspect AN file and reverse BY coordnate if necessary.
Last update: Monday, 04-Jan-2010 16:30:04 MST by L.O. Sjouwerman
FITLD would change the sign of By in the antennas file for all antennas which did not occur in the first input IDI-format file. The sign of By is correct for all antennas that occurred in that first file. FITLD is run on preprocessed files and this error thus does not affect data loaded by a FITLD compiled (with a MNJ) outside the dates above.
Back
 

 
505 : Clock errors
 
DiFX clock glitches for individual experiments
Problem start: 2009 December 23
Problem fixed: 2010 February 1
Archive fixed: Not fixed
Workaround: Posted here.
Last update: Wednesday, 17-Feb-2010 16:14:59 MST by L.O. Sjouwerman
We have found that occasional projects are correlated on the VLBA DiFX software correlator with different clock offsets and rates for different parts of the project. The different values are generally both valid, but they come from different fits to the data comparing GPS time to local station time. The main concern is that a step in delay and fringe rate is introduced at the boundary between jobs using the two values. We are working to prevent that from happening in the future.

We have determined that projects BB261K, BB261N, BL149CD, BM308AC, BM308X, BM310A, and BM331A were subject to this issue for one or more stations. If your processing depends on having one clock offset and rate for the whole time, then you may wish to make corrections using the 'CLOC' option in CLCOR. For projects for which all sources are fringe fitted, this is probably not a problem. For phase referencing projects using clock and atmosphere solutions, it may well be a problem.

Exact instructions for correcting the projects affected in AIPS are listed here.

Back
 

 
506: sensitivity and cable swap KP
 
reduced sensitivity KP
Problem start: 2013 November 26 (symptoms mid-September)
Problem fixed: Mid-Jan 2014 (for data correlated in Socorro)
Archive fixed: Not fixed
Workaround: See potential fix below for specific cases
Last update: Saturday, 15-Feb-2014 10:14:03 MST by L.O. Sjouwerman
From mid-September through mid-November 2013, intermittent reduced sensivity and unusual bandpass shapes were observed, likely due to a poorly-seated cable in the IF path. There is unfortunately no fix for this problem. During the period from 2013 November 26 through 2014 February 5, one of the two RDBE units had its IF inputs crossed. For dual polarization projects using just the first RDBE, this shows up as crossed polarization. Such projects use the PFB personality or the DDC personality with 4 or fewer channels and only 1 or 2 IFs (not S/X or wide 6cm). Projects using two RDBEs often have the polarizations going through different RDBEs, so there is no clear signature. A dual polarization project for which the KP amplitudes are low, please check the cross-hand data to see if the amplitudes are high. If they are, this indicates a crossed polarization situation. In this case, the AIPS task SWPOL can be used to correct the data.
Back
 


Staff | Contact Us | Careers | Directories | Site Map | Help | Policies | Diversity | Search
Modified on 2017-Feb-16 by L.O. Sjouwerman