| No | Date | Time | Project Code | Observer | Support Scientist | Instrument | Bug, Etc. | Priority | Time Lost | Status | Description | Response | Scripts |
|---|
| 1 | 2005-06-08 | 17:30 | GBT05B_011_011 | Minter | Minter | Analog Filters/Rack | Problem | Urgent | 00:10 | Closed | When I first brought up astrid (at the end of maintenance/beginning of observing) I was not allowed to "make updates to the telescope". Everything with the gateway was set properly. I had the operator "take control" in astrid and then go back to monitor only mode in his astrid. I then could get control but astrid did not run my script once it went into the run queue. A stop/restart of turtle fixed this. | Moved to AstridReports (item #41). AmyShelton | |
| 2 | 2005-06-08 | | GBT05B_011_011 | Minter | Minter | Analog Filters/Rack | Problem | Urgent | 00:10 | Closed | When astrid tried to run the configuration part of the observing script I got lots and lots of Grail errors (sorry I forgot to save them in the heat of the moment). A restart of Grail and turtle allowed things to run. | Moved to AstridReports (item #42). AmyShelton | |
| 3 | 2005-06-08 | | GBT05B_011_011 | Minter | Minter | Spigot | Problem | Urgent | 00:10 | Closed | The "auto-leveler" code used in the new spigot software was left running by the previous spigot observer (from some 12 hours before) which caused the converter rack attenuation levels to change. The operator had to kill this program before observations could happen. | ScottRansom made changes to the auto-leveler script so that it dies when the user is not in the Gateway. This should prevent this from happening again. AmyShelton | |
| 4 | 2005-06-08 | | GBT05B_011_11 | Minter | Minter | Antenna/Antenna Manager | Problem | Urgent | | Closed | The antenna state is "Error" but there is no error message that can be found - even after restarting the cleo message screen. Seems to be benign. | This is a known problem with the message system. An item has been added to the CCC list to schedule investigation into the problem. | |
| 5 | 2005-06-08 | | GBT05B_011_011 | Minter | Minter | Spectral Processor | Problem | Urgent | | Closed | The spectral processor is set to "Not Balance" however I still get error messages saying that the spectral processor could not balance (lookily it was not trying to as I desired). | Added to CCC's Spectral Processor Root Cause Analysis/Refactoring | |
| 6 | 2005-06-08 | | GBT05B_011_011 | Minter | Minter | Analog Filters/Rack | Problem | Urgent | | Closed | While one observing script was running, I submitted another to the run queue. When the first script ended the second script disappeared from the run queue but it never executed! | Moved to AstridReports (item #43). AmyShelton | |
| 7 | 2005-06-09 | 17:30 | TSCHOOL_RJM | Maddalena | Maddalena | GO_LITE | Problem | Important | 1:30 | Closed | The writeup in the operator's log isn't detailed enough concerning a 'bug' with GO's Ephemerides. GO would not send to the Scan Cordinator or Antenna the userTransformTables, userTransformEnable, or Primary Segments when using a moving source such as the Moon. I also tried to use an Asteroid.tbl file to specify positions but that too didn't seem to set anything in the Scan Coordinator or Antenna. Joe was called in and was as puzzled as I. We checked with Frank aand Toney and both thought there wasn't a human error involved. While poking around, the problem mysteriously disappeared and we are at a loss as to what started the problem or made it go away. Ouch! | Checked antenna and messages logs, but did not see an obvious problem. Jim has agreed to test this mode during regression testing to verify the mode works as expected. | |
| 8 | 2005-06-11 | 07:20 | AGBT05A_042_025 | O'Neil | O'Neil | Spectrometer | Problem | Other | 0:05 | Closed | The spectrometer started up in its usual funny state (scan #22). I had to hit reset parameters to fix the problem. | Known issue. AmyShelton | |
| 9 | 2005-06-16 | 21:30 | AGBT05B_016_02 | Barvainis | Ghigo | Config_tool | Problem | Important | 0 | Submitted | When running the config_tool, we get an error message, "Write permission error: could not write configuration file".
But the configuration seems to have been ok. | Could you please supply me (mmello@nrao.edu) with the following information: the user name, the directory where astrid/turtle/config tool was run from and if you were running in real telescope or sim mode.
| |
| 10 | 2005-06-16 | 22:00 | AGBT05B_016_02 | Barvainis | Ghigo | Spectrometer | Problem | Urgent | 10 | On Hold | Spectrometer balancing failed on sampler J3. Even though the Converter rack attenuators were in the middle of their range, the balancing consistently resulted in a duty cycle ratio of 1.1 or 1.2 instead of 0.8. I could make the duty cycle ratio correct by adjusting the attenuator in CM10 by one db. FrankGhigo
I found the same problem and used the same fix. There's no error message saying anything like a balance not being successful so, if it weren't for Frank's previous complaint, we'd have lost a good amount of time trying to find the problem. Thanks, Frank --- RonMaddalena | New problem. The first question is
whether it is reproducible. Is it
dependent on a specific configuration.
A script would be useful as well as
the attenuator settings. The data
file would contain a good deal of
this information. I am passing this
on to the CCC for deposition. This item requires a some effort and needs to be addressed during cycle planning. MarkClark | |
| 11 | 2005-06-19 | | Multiple | Multiple | Maddalena | Internet/RPC | Problem | Urgent | | Closed | Our version of graphics software can no longer be displayed on some remote computers via X windows. Some X applications that are native to Linux (e.g., xclock) are OK but almost all of our home-built GUI applications (GO, CLEO, BCPM screens, maybe Astrid?) fail when users try to bring them up remotely. According to the remote user, the error message states that there's an X-protocol security problem.
It's Linux version related since obsrevers can bring up our applications on older versions of Linux. Either the remote, new versions of Linux are finding our appications using something insecure or our network is refusing to serve some flavors of remote Linux.
This is the third obsrever who I've helped that has helped this problem so I suspect it's widespread. | This is a somewhat known issue, but not one we can easily resolve. I have seen this issue with Fedora 3 and 4. (RedHat? enterprise 4 is essentially Fedora-3.)
THIS IS A CLIENT (read remote user) issue.
The remote user needs to specify the -Y option to ssh when logging-in. (e.g ssh -X -Y ssh.gb.nrao.edu)
| |
| 12 | 2005-06-19 | 11:00 | AGBT05B044 | McLaughlin?/JAcoby | Maddalena | Antenna/Antenna Manager | Problem | Important | 2:00 | Submitted | We lost Weather 2 but the antenna relies on it for weather information for its refraction calculations. This puts the antenna into a fault and unmovable condition. Issues we may want to address are:
Although other weather stations could fill in, there no way to select a weather station other than weather 2.
The userInputs in the Antenna Coordinator are now always feedbacks, regardless of the value of the Antenna's parameter weatherSource. This is new behavior since, in the past when weather 2 has died, we were able to specify userInput and type in weather values. Luckily, I remebered that the antenna manager would inherit values from the Antenna coordinator so I used the antenna manager & device explorer as a backdoor to change weather values.
WhenI changed the Antenna Manager values, the coordinator also picked them up. This might be by design but it's atypical for a coordinator to inherit changes made directly to its children.
Even when I 'fixed' weather values, the antenna remained in a fault condition. Yet, we were still able to command it's motions. The error message gave us the impression we wouldn't be able to control the telescope. Luckily, we thoiught of trying regfardless of the message.
For antenna control, the 3 quantities that should be distributed onto more than one weather station are pressure, temperature, and humidity (or dewpoint). On wethaer 2, we have 4 temperature sensors, 2 humidty sensors but only 1 other temperature sensor (on weather 3 which also was down), one other pressure sensor (on weather 1), and no other humidity sensor. This makes weather 2 a one-point failure for all the relevent parameters. A backup for weather station 2 should have P, T, and H values available. | | |
| 13 | 2005-06-20 | 00:00 | AGBT05B_016_05 | Barvainis | Balser | GO_LITE | Problem | Important | | Closed | Problems getting GO Tables to load. They
would load a table into GO okay. But when they tried to load the same table in again it would fail with some ambiguous message.
It seemed to be random whether or not
the table would load. Also, sometimes
they could execute a table that failed
to load and other times they could not.
I was able to repeat some of this behavior
in the GO simulator.
[I did find an error in one GO table (sdss_nite3.obs) where they were missing
the beginning of a block "block setuppeak". Although I had problems loading sdds_nite1.obs this might have been after loading sdss_nite3.obs unsucessfully.] | With the release of Astrid happening soon, this probably won't get worked on. PaulMarganian | /users/dbalser/glish/sdss_nite1.obs
/users/dbalser/glish/sdss_nite3.obs |
| 14 | 2005-06-22 | 21:45 | AGBT05B_016 | Barvainis | O'Neil | Other | Problem | Important | 00:00 | Closed | The observer reported problems with the gbtidl online filler. He stated that his data file from the night before (which I beleive would be session AGBT05B_016_07) appeared to have no data in it. He also stated that he has encountered problems with other files missing a few of the scans from the middle of his run. No time was lost for this, as he was given instructions for running the sdfits filler offline. But the problem seems urgent for the online filler. | Occassionally, scans fail to be filled by sdfits - a known issue. The project that had NO data was a result of cascading errors involving the 2 Gig file limit which we are in the process of correcting.
Users can use sdfits in regular, 'offline' mode to append missing scans to their data from /home/sdfits. Use the -scans and -append options: sdfits /home/gbtdata/project -scans=missing_scans -append -backend=my_backend /path/my_file_prefix
Where 'my_file_prefix' is from the filename my_file_prefix.raw.acs.fits, for example. PaulMarganian This 2G limit has been removed in GBTIDLv1.1. AmyShelton | |
| 15 | 2005-06-28 | 22:00 | AGBT05B_041_02 | Greve | O'Neil | Internet/RPC | Problem | Other | 00:05 | Submitted | When the observations began, I tried to look at the observer's spectrometer file, only to discover that no data had been written to the file yet (about 3-4 minutes into a 10 minute scan). I had the observer abort the scan and begin a new one. The new scan exhibited the same behavior. Amy Shelton was present and looked at the spectrometer log files and stated that the spectrometer beleived to be writing data. We then discovered that data was in fact being written, but the spectrometer was running into problems getting the data onto disk, and so the data was being written into the buffer and then slowly transferred (a la the fix made awhile ago by Joe and Mark). Ultimately, it took about 6 minutes for the 10 minutes of data to be written to disk (the observer had 2s data dumps). While we were lucky and the data did manage to get onto disk with no data loss, this could hav been a disaster. | | |
| 16 | 2005-06-28 | 22:00 | AGBT05B_041_02 | Greve | O'Neil | GO_LITE | Human Error | Other | 01:44 | Closed | The observer did not set the primary antenna epoch to be J2000 and so lost about 1:45 worth of data. The observering support person (me) mentioned this to the observer, and he said he would change it, but I did not think to actually check that he did. After i went home, the operator on duty (Kevin) noticed that the antenna wasn't moving and caught the error again. This time, the observer did make the switch | | |
| 17 | 2005-06-29 | 23:00 | AGBT05B_041_03 | Greve | O'Neil | Spectrometer | Problem | Urgent | ??:?? | Submitted | This morning it was discovered that the spectrometer did not write fits files for more than half the observer's data. I do not beleive the observer noticed this last night, as I was not notified of the problem. Consequently, it is difficult to know what went wrong. | The SDD is currently investigating the cause of this. So far, we know that the Spectrometer was indeed in the ScanCoordinator and are pretty sure that there were no fault messages from the Spectrometer. It looks like FITS files were being written sporadically. If unable to recreate this problem, we may never know what was going on. AmyShelton | |