This page was last updated on
2023 May 09 10:41 MDT
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.
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 2023 May 09 | ||||||
Specific (E)VLA archive issues: | ||||||
# | Begin | End | Archive 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 |
General AIPS FITLD issues | ||||||
Specific VLBA archive issues: | ||||||
# | Begin | End | Archive 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 | |
507 | 2020 Feb | 2023 Apr | not fixed | 7ghz flux density scale | ||
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.
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
| |
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: Thursday, 25-May-2017 07:48:22 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://library.nrao.edu/vlbat.shtml 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 | |
507 : 7 GHz Flux Density Scale | |
---|---|
Incorrect gain values for 6-8Ghz portion of C-band. NL & PT incorrect focus settings. | |
Problem start: 2020 February 11 | |
Problem fixed: 2023 April 05 | |
Archive fixed: Not fixed | |
Workaround: Corrected gain values available at link below. PT and NL sensitivity loss not recoverable. | |
Last update: Tuesday, 09-May-2023 10:51:27 MDT by A. Sowinski | |
Gain values for the 6-8 GHz portion of C-band were not being
attached to FITS-IDI files. Provided gains for 4-6 GHz were
still accurate. This page will be updated with the date
when the FITS-IDI files have the correct gain attached.
Additionally, from 2020Feb11 to 2023Apr05, PT and NL had
incorrect subreflector focus settings which caused further
deviation from provided gain values as well as a loss of
sensitivity. More detail and instructions for correcting
calibrated flux densities are listed here.
| |
Back | |