| No | Date | Project Code | Observer | Support Scientist | Description & Scheduling Blocks | Response |
|---|
| 1 | 2005-11-10 | AGBT05C_049_29 | Minter | Minter | At the start of scan 7 I had an error come up that said that the scan coordinator had lost the RPC connection to LO1 on vortex. This error lasted 10 seconds. However, this was when the scan coordinator was activating to run scan 7. As a result, the LO1 never went into activating or running for the scan.
For my observations this is not a problem. However, it easily could be for a large fraction of the observers. | This is a known issue with the LO1.
On long scans (1 hour in this case) the LO1 coordinator requires more compute time than is allowed for the network connection. The workaround is to perform shorter duration scans. |
| 2 | 2005-11-16 | AGBT05C_031_13 | Kepley | O'Neil | the observer ran AutoPeak? four times. the data coming into the DCR looks fine, frm the CLEO sampler plotting window, but GFM could not reduce the data - KarenONeil | This is due to the fact that the data in the DCR FITS file is all zeros. AmyShelton |
| 3 | 2005-11-17 | AGBT05C_014_09 | Chandler | O'Neil | When bringing up the CLEO messages window, the error comes up: Cannot write to log file (or something to that effect). The messages windo does seem to display the messages fine. - KarenONeil | A file permission problem associated with the recent release. It is now fixed. |
| 4 | 2005-11-17 | AGBT05C_034 | Kameno | O'Neil | When running the peak and focus scans (using Peak and Focus, not AutoPeakFocus?), we found the DCR data to be extremely ratty. After a few minutes I realized that this was due to incorrect blanking with the LO1. We switched the LO1 to "topo" mode and ran the rest of the evening like that, with little data lost. I do not know what is to blame for this as:
(1) we ran at first using the command Configure("Continuum with Rcvr18_22") This has vframe="topo", yet the LO1 was in the LSRK frame. For some reason I had to add in an extra Configure command to re-set the vframe to topo.
(2)The blanking for the LO1 was on. Shouldn't GFM see that, or does the DCR not blank? As I had assumed the GFM screen would know about blanking, I was worried the spetral line data would also be screwed up. This may have been a naive thought on my part - I'm not sure. | It's not a config tool problem and the system was working as specified and designed.
This is the scenario:
The config tool is run and sets up the restframe to "Local".
But the user defines the catalog with the veldef set to 'vrad-lsr' for several sources. This results in turtle changing the restframe in the LO1 manager for procedures that use the sources in the Catalog definition.
|
| 5 | 2005-11-18 | AGBT05C_043 | Kanekar | O'Neil | When the operator (Dave) switched receivers we lost all contact with the Antenna manager. Joe Brandt was called and got tings up and running. See the operator log for more information. -Main.KarenONeil | I believe this is due to a bug in the messageMux. It is under investigation. |
| 6 | 2005-11-27 | AGBT05C_034_03 | Kameno | Maddalena | This is more details on bug report (4) above. I saw the same behavior in the DCR sampler values and FITS files, though the data reduced via GFM looked great. See the last column of this table for where you can find a copy of the scripts plus a screen dump of the CLEO sampler strip charts.
I agree that the script looks correct. Karen's changes seem to make two independent requests to "Configure" to turn off Doppler tracking before the PEAK. Yet, the LO1A Fits files show that the frame was still LSR. It's as if Config_tool ignored the request to change frames. Since the 'tolerance' was 1 Hz, and LO Blanking was 'on', the DCR's data would have these 'drop-outs' every second or so during an OTF observation. ~rmaddale/dcr_27Nov05.ps and 5C34_03_ConfigProblem.txt | It's not a config tool problem and the system was working as specified and designed.
This is the scenario:
The config tool is run and sets up the restframe to "Local".
But the user defines the catalog with the veldef set to 'vrad-lsr' for several sources. This results in turtle changing the restframe in the LO1 manager for procedures that use the sources in the Catalog definition.
The script (5C34_03_ConfigProblem.txt) confirms this:
Catalog("""
veldef = vrad-lsr
coordmode=J2000
head=name ra dec velocity
NGC1052 02:41:04.7985 -08:15:20.751 1459.1
N1052CT 02:41:04.7985 -08:15:20.751 0.0
3C48 01:37:41.2994 +33:09:35.134 0.0
MIRA 02:19:20.7927 -02:58:39.513 1459.1
""")
|