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