Документ взят из кэша поисковой машины. Адрес оригинального документа : http://www.naic.edu/~cima/cima_problems.html
Дата изменения: Thu Mar 1 19:02:25 2012
Дата индексирования: Mon Oct 1 22:43:46 2012
Кодировка:
Поисковые слова: annular solar eclipse

CIMA Common Problems

This is a compilation of some common problems when observing with CIMA

I loaded my config file, but when i went to apply it, the data had changed'
I got a 'received duplicate AGC-datablock' warning - what is that?
I got a 'counts don't match between chip 0 and chip N' warning - what is that?
I got an 'overflow detected' warning with 'next.total' and 'tcount' - what is that?
I got a 'the correlator has failed to start' error from a WAPP - what is that?

You can return to the main CIMA page by clicking here.

I loaded my config file, but when i went to apply it, the data had changed'

This can occur when you use the load config button (as opposed to the load and apply button). Pushing the load config button pops up all the windows that need to be configured onto the screen. With the new mock configuration windows the screen gets pretty cluttered. If you then close one of these windows to get at a window in the background, then you have lost the setup information for the closed window.
An example would be:

load config file for mock spectrometer observation (but do not apply)
close the mock config windows so you can get at the receiver/iflo window
apply the receiver if/lo window
click backend button to get the mock config window back. It now has the default config info, not the info from your config file.

So the sequence should be:

load and apply config file
or: load config file, accept each window in the correct order(receiver iflo then backend) before closing any of the windows

I got a 'received duplicate AGC-datablock' warning - what is that?

This is a harmless message that most observers will see from time to time, since the problem typically occurs a number of times per day. What has happened is that the computer that broadcasts the telescope positions hasn't updated the actual position of the telescope but sends out the same data as it did the previous second. The problem only persists for one second and it happens with a modulo 899 second periodicity - that is, there is a probability every 899 second that the bug occur, but the bug only occurs on some cycles. Note that since the problem is in the broadcast of the telescope positions, all backends are affected.

The message, however, is coming from WAPPDATA which is the computer that merges the output from the four WAPPs into a single CIMAFITS-file when the WAPPs are run in spectral line mode. To have the telescope information ready to be filled in into the FITS-header, WAPPDATA has a program running that continuously reads the parameters that are broadcast and stores them for the FITS-writer. This program is running continuously and will send a warning message to CIMA whenever it sees a duplication of the telescope data regardless of whether You are using the WAPPs or not. If You happen to be taking data with the WAPPs in spectral line mode at the same time as this happens You will also get an interpolation or extrapolation warning from the CIMAFITS-writer when it tries to estimate the missing telescope parameters.

I got a 'counts don't match between chip 0 and chip N' warning - what is that?

This is a problem that can affect the WAPPs when they are running in spectral line mode. Whether it is a real problem or not depends on the circumstances. The WAPPs are comparing the number of samples accumulated in each of the 16 chips on each correlator board with chip 0 on that board. Any discrepancy is reported since that could indicate a problem. The two numbers in the message is the sample count in the two chips compared. If they are just a few units from each other, then data is OK. However, if the discrepancy is 100s or 1000s or more, then You can expect the data to be crap. If it is only one specific chip being reported, than that is a good indication that there is physical problem with that chip. If there is a number of different chips being reported, then the real problem is not on the correlator board but somewhere else in the hardware and the chip count is just a manifestation of that other problem.

It happens occasionally that one or several WAPPs suddenly report a large number of serious chip count errors for a second or two, and then continue taking data without any problem. In this case data is certainly crap for that second or two. Since several WAPPs are typically involved in this instances, they must be due to some external transient disturbance, possibly involving transients on the power lines.

There is never any point in stopping observations and restarting the WAPPs in case of chip count errors, since the cause is not with the WAPP software. The only reason to stop is if one WAPP is producing horrible chip count errors and You don't want to use it any longer.

I got an 'overflow detected' warning with 'next.total' and 'tcount' - what is that?

This is a problem that can affect the WAPPs when they are running in pulsar mode. What has happened is that the WAPP computer has not been able to keep up with the data rate from the correlator board(s). The message is sent when the WAPP sees that the sequence number of next dump from the correlator board ('next.total') is larger than what it expected ('tcount'). The output from the WAPP will thus have a time glitch in it, which due to the lack of meta data in the WAPP pulsar file format is invisible - Your only knowledge about such glitches is to look for this message in the CIMA logs! Furthermore, the WAPP will compensate for the lost observing time by extending the observation to make sure that the file produced has just the size You expect (which to me doesn't make any sense). This feature may cause further problems, if the WAPP experiences several glitches during an observation that add up to more than 15 seconds of compensation time, since CIMA allows 15 seconds overhead to start and stop an observation. If the WAPP has not finished within this time limit, CIMA will assume that the WAPP has failed, command it to stop and abort whatever CIMA was doing due to the failure.

I got a 'the correlator has failed to start' error from a WAPP - what is that?

It occasionally happens that a WAPP fails to get the correlator started when used in spectral line mode. The WAPP will discover this after a few seconds when it doesn't receive any data from the correlator board(s), and then sends the 'correlator has failed to start' message to CIMA. The reason why this happens is not known, it may be a timing/interrupt conflict in the driver. The problem does not require any special action (like a restart of the WAPPs) since the same WAPP will work perfectly immediately afterwards.

In the older versions of CIMA (version 2.2 and earlier) this always forces CIMA to abort the ongoing observations, which is exactly what some observers want but is highly undesirable for other projects (especially commensal ALFA projects) when it is much more important to keep the observation going. The newer versions of CIMA (version 2.3 and later) therefore provides the observer with a preference setting to specify how CIMA should behave when this happens. If the 'Keep observations going if a WAPP fails' preference is set to 'Yes', then CIMA will keep the observation going even if one or several WAPPs fail (as long as at least one WAPP remains functional) - the failed WAPP will be left idle for the rest of the failed scan and then automatically reenabled after that.