| No | Date | Project Code | Observer | Support Scientist | Description & Scheduling Blocks | Response |
|---|
| 1 | 2005-08-28 | TPTCSOOF_050828 | Balser | Balser | GFM always plots R1 for the polarization and beam in the plots, regardless of what is being selected. The comments below the plot get the right answer but they should both be correct. This was important since we were trying to figure out what channel was bad in Q-band and got confused over what was being plotted. I think this is know but I did not see it on any list and discovered it again during our observing. | I'll try and recreate this offline. AmyShelton |
| 2 | 2005-09-22 | AGBT05B-002 | Taylor | O'Neil | After we had spent about 5 minutes going to target source, we went to the autopeakfocus which chose a source about 360 degrees in azimuth away. (Target source was at -89 degrees on CCW wrap), the elevation chose was within a degree. Abort done from astrid and a manual target chosen and resubmitted. | Mark and I (Karen) knew this could be a problem with AutoPeak?/Focus, but we did not know how often the problem would occur. As far as I am aware, this is the first time the wrap issue has come up with the Autopeak/focus routines. - KarenONeil |
| 3 | 2005-10-15 | AGBT05C_002 | Kavars | Maddalena | Observing at 340 MHz and Auto Peak selected a source that was about 1 Jy. The confusion limit at 340 MHz is 0.5 Jy so the peak could never have been sucessful. Probably a good rule is to set the minimum flux to be 10x the confusion limit. Another reason to use a high minimum flux at 340 MHz is the constant RFI in this band. Auto Peak already knows the confusion since it reports the value when it selected the source. Thus, it wouldn't be hard to set the minimum flux accordingly. | The confusion levels used in the auto procedures are determined by Jim Condon as described in his calfind program. This is a change in requirements and will require an MR. MarkClark |
| 4 | 2005-10-15 | AGBT05C_002 | Kavars | Maddalena | Auto Peak picked offsets of 130 arcmin for a pointing at 340 MHz. Since the beam is 35 arcmin, this is muct too small. GFM complains that the offsets are to small. The 130 arcmin is apparently what the PTCS recomends for observing at 1400 MHz.
The PTCS has not made any recomendations for pointing offsets for the PF receivers. A better offset would be at least 10x the beam width, about 350 arcmin for 340 MHz observing. This is the minimum ratio recomended by the PTCS for Gregorian receivers.
A useful Auto Peak rule for the PF receivers would be something of the order: Offset in arcmin = 123000/Frequency in MHz. | The current parameters are a compromise (perhaps not optimal) between accuracy and efficiency. This is a change in requirements and will require an MR. MarkClark |
| 5 | 2005-10-22 | AGBT05C_049_07 | Minter | Minter | Dain Kavars and I combined to find a new feature in astrid. Dain had hit pause in his astrid session to end his program. He then went to file and exit to get out of astrid without unpausing. When I started my astrid, astrid was still in a paused state. I had to hit pause in my astrid to get his scheduling block to pop up an abort in my astrid session so that my scheduling block would run. This left my astrid with the pause button being red so that it was always confusing as to whether or not I was really paused. | Needs to be scheduled. AmyShelton |
| 6 | 2005-10-22 | T_24Oct05 | Robishaw | O'Neil | Tim put a for loop in his astrid script. the result was it took 5 minutes for the script to validate and 5 minutes to save (he hit validate and then save). While I realize this falls into the astrid "bad practices" realm, I suspect that many observers are going to be bit by this. | I'm not sure what to say about this. I understand that you are reporting long validation times, but what problem exactly should be fixed? Make validates faster? Remove manual validation? AmyShelton I think the problem here are the additions of general python coding in Astrid scripts. During validation the script is run and only those portions dealing with Astrid per se are simulated, other commands, e.g., reading/writing files, looping, or -- most recently -- sleeps are actually run causing unexpected results or delays. It is not clear how, or even should, such "extracuricular activities" should be handled during validation. MarkClark |
| 7 | 05 Mar 2006 | AGBT06A_018_02 | McMullin? | Balser | gbtstatus
Some suggestions:
1. Is it possible to add the GBT state? I notice the GBT status is listed twice.
2. There are too many significant digits in some cases. E.g., DC Focus Y (mm). I would use two significant digits (x.xx) for focus parameters in mm and pointing parameters in arcsec.
3. The IF info on the second page is nice. The BackendIF? is a bit cryptic though. Is this the sky frequency at the center of the band determined from the IF manager?\ If so, I would use skyFreq or something.
| MelindaMello may want to comment on some of this when she gets back from vacation. I would recommend placing these requests at the Observing Issues meeting. If they are well-received, we can schedule them for implementation. AmyShelton |
| 8 | 2 May 2006 | AGBT06A_061_01 | Zwaan | Balser | We were not able to configure the telescope because the deltafreq was
defaulted to 0 during an AutoPeakFocus
(which ran fine), while the spectral line configuration had two spectral windows but nothing was specified for deltafreq. Therefore, two dimensions were required but only one was specified. The scheduling block validated okay.
Discussion with MelindaMello and MarkClark suggested several solutions:
1. Remove the line that sets deltafreq in AutoPeakFocus. This would cause problems going the other direction (line to continuum for example).
2. Encourage the users to always specify deltafreq in the config file. This makes it harder to use fewer lines to specify configuration that are slightly different.
3. Zero out the default for deltafreq in AutoPeakFocus.
4. Zero out all the defaults for AutoPeakFocus.
Main.KarenONeil later mentioned that it might be good to have a general purpose reset for these parameters. DanaBalser | Description covers the issue well, just need a decision. MarkClark |
| 9 | 9 May 2006 | TPTCSPNT_060509 | Balser | Balser | We were running an all-sky pointing run at X-band and were archiving lots of samplers. It appears that the weather data (1,2, and 3) were not written. This has now happened twice (see TPTCSPNT_060323). The ScanLog.fits file claims that it is writing weather data and there is a directory created but no data. Many other samplers (e.g., ServoMonitor) seem to write the data out okay.
I do not see any problem with the scheduling block located at:
/home/groups/ptcs/obs/turtle/PointingRun.sb
Main.DanaBalser | This problem has been reproduced on the simulator, and we are working on a resolution. JoeBrandt |
| 10 | 23 May 2006 | AGBT06A_018_09 | Balser | Balser | During a Peak observation (actually AutoPeakFocus2?) there were problems with Astrid reducing the Peak data. When the first Peak scan (Az forward direction) finished the antenna moved onto the next scan (Az backward direction). But GFM did not reduce the first scan. The previous plots remained in the plotting window even though the left frame indicated the correct scan numbers as they updated. Kevin Gum was running astrid in monitor only mode and on his GFM session everything looked fine. After the second Peak scan, still nothing. I then got the LPCs did not update popup and then do you want to abort popup. I aborted and tried again with the same result.
I exited astrid and when I returned everything seemed to be okay. The scan numbers were 10-11 and 12-13.
Something similar happend a day earlier with AGBT06A_018_08. Although astrid hung after the second scan in the Peak and we had to reboot turtle to get going again.
I think this problem has happened in the past.
DanaBalser | I talked with Dana about this. In order to figure out more information, he is going to run astrid with the -v option which might uncover some hidden traceback to aid debugging. AmyShelton |
| 11 | 05 July 2006 | T_RCO342_060705 | Balser | Balser | I got the same problem as in number 43 but did not run astrid -v! Sorry.
I wonder if there is something in my setup that makes this happen more often for me? Dana | I doubt that it is you, Dana. I just think that you do more peaks and focuses than most observers. We have been having trouble with GFM loosing its Grail connection. I'm starting to suspect this as the culprit. Next time, try restarting Grail and bring up a fresh Astrid session. If this works, then I'll suspect the GFM/Grail connectivity even more. AmyShelton |
| 12 | 05 July 2006 | T_RCO342_060705 | Balser | Balser | The online sdfits did not update to the new project until the operator restarted the data capture. Do we understand why this happens? It seems to happen enough to be inconvenient, although the fix is easy. Dana | This should probably be in the General Obsreports, not under Astrid(?). It seems that the online sdfits filler stopped filling scans the previous day, halfway through project AGBT02A_053_05. Unfortunately, the log files do not contain any useful info, and the process did not actually die: otherwise a message would have appeared and this might have been caught. If the online filler gets stuck without actually killing the process, there is no way to know its not working unless someone tries to use it (typically in online mode in GBTIDL). Do we need to improve the status monitoring of the online filler? Dana's right, the fix is pretty easy - just restart it. From my perspective, the failure rate for the online filler is very low, but Dana says it happens enough to be inconvenient. I imagine we could work on the online filler to make it more robust, but not sure if the returns are worth our effort. Another issue for the Observing Issues Group?
Main.PaulMarganian |
| 13 | 17 July 2006 | AGBT06B_006 | Gottlieb | Ghigo | It continues to confuse observers that the beam designation in the Scan Types is "1", "2", etc, but in the config tool it is "B1", "B2", etc. We need to have a consistent beam designation that is the same in both places. | I agree. Turtle matches the antenna and accepts: 1, 2, 3, 4, MR12, MR34, and C. The config_tool accepts: B1, B2, B3, B4, B12, B34, B1234. Do we go with majority rules, i.e. two are one way already? AmyShelton |
| 14 | 4 August 2006 | GBT06B_012_04 | Kevin A. Douglas | ? | > > > I'm helping observe GBT06B_012 presently, and I wanted to let you know
> about a rather minor bug I may have discovered in AstrID?. We had some
> sources named 40E1, 40E2, 40E3, etc in our sources catalogue file.
> AstrID?
> was able to tell me it would slew to those sources, but when the
> DataDisplay? widget is displayed, it converts these strings to numbers,
> ie.
> 40E1 = 400.0, 40E2 = 4000.0 etc. It must be using " E " as " x10^ " !
> The new name gets written to the output data file - eg. when I do a
> summary with GBTIDL I get 400.0 instead of 40E2.
| This seems to be coming from a bug in FQL.
rst.getField(0)
where rst is a result set returned by FQL for the OBJECT "40E1" returns:
400.0
The entry in the GO fits file looks like this:
OBJECT = '40E1 ' / Manager parameter source
Main.PaulMarganian |
| 15 | 6 Aug 2006 | AGBT06B_020_09 | O'Neil | O'Neil | GFM did not display any of my pointing or focus scans, even after i tried re-running the AutoPeakFocus?. No error message was given, except to state "no corrections detected, terminate SB?". I tried saying no to that and waiting, but still nothing happened.
On the telescope operator's screen, the gfm showed everything correctly, as did the offline gfm I ran.
Telescope corrections for the pointing and focus were entered by hand.
Similarly, the online gfm did not report any of my spectral line scans. Again the offline (not attached to astrid) version did fine, even when in "online monitor only" mode.
Finally, I tried taking astrid off line and then online again, and the 3rd or 4th try it finally started picking up the new (spectral line) scans.
Main.KarenONeil | We had this type problem at least one time before. We tried many things, including rebooting titania, but the problem -- as here -- seem to fix itself. I hate to suggest it, but if this occurs again and is as persistent as described here, it might be interesting to restart Grail on wind. MarkClark |
| 16 | 11 Aug 2006 | AGBT06B_034 | VanGorkom? | Ghigo | GFM running under astrid failed to display any spectra. The error messages displayed in the GFM tab were:
Exception in thread Thread-2:
Traceback (most recent call last):
File "/home/gbt7/llama/lib/python2.4/threading.py", line 442, in __bootstrap
self.run()
File "/home/gbt7/llama/lib/python2.4/threading.py", line 422, in run
self.__target(*self.__args, **self.__kwargs)
File "/home/sparrow/6.4/app/turtle/ServerInterface.py", line 49, in __call__
self.listen()
File "/home/gbt7/llama/lib/python2.4/site-packages/Pyro/EventService/Clients.p
y", line 51, in listen
self.getDaemon().requestLoop(lambda s=self: not s.abortListen)
File "/home/gbt7/llama/lib/python2.4/site-packages/Pyro/protocol.py", line 911
, in requestLoop
self.handleRequests(timeout,others,callback)
File "/home/gbt7/llama/lib/python2.4/site-packages/Pyro/protocol.py", line 917
, in handleRequests
self._handleRequest_Threaded(timeout,others,callback)
File "/home/gbt7/llama/lib/python2.4/site-packages/Pyro/protocol.py", line 982
, in _handleRequest_Threaded
ins,outs,exs = select.select(socklist,[],[],timeout)
error: (4, 'Interrupted system call')
| The inter-python-process communication module Pyro still does not seem to be completely robust which this stack trace may be indicative. We may consider advancing to version 3.5 in the next release. We are currently using 3.4. MarkClark |
| 17 | 13 Aug 2006 | BK127D | | FrankGhigo | VLBI project BK127D was observed with the GBT at ~1420 MHz.
There were problems with Astrid failing to advance to the next source
(see the operators logs for details)
-- this happened on 2 occasions:
13:44 to 14:00 UT
and 16:21 to 16:26 UT
In the first occasion, the telescope tracked J0409+12, but
did not move back and forth to J04135.
In the second, the telescope remained on J04135 and did
not move to J0409+12.
Otherwise everything seemed to go smoothly.
Tapes EVNT0206 and OVLB0107 are being shipped
to Socorro today.
Tsys was 20 - 22 K.
Phase cals looked good with amplitudes of ~ 4.5%.
The weather was partly cloudy and warm. | Apparently, we are still losing state changes and I cannot check the cause in
the log because turtle was restarted. In an attempt to see what is happening, I am going to ask the operators to trace the output and attempt to call me before restarting turtle. MarkClark |
| 18 | 17 Aug 2006 | T_FG060817 | Ghigo | Ghigo | The spectral line beta apparantly is active only when you are looking at it.
If you go to "observation Management" for a while and then back to "Data Display" it is still showing the spectrum from the scan that you were looking at previously. You have to wait a few minutes for it to update with the most recent scan.
Is this a feature? It really ought to be updating the display behind the scenes so that the latest spectrum can be seen immediatly when you clich the data display tab.
| You are right, this is indeed a feature. GFM adopted the policy if no one is watching, no use straining yourself. Reducing and displaying the data is a bit of a load, but it may a cost that should be absorbed to provide the observer with a more responsive systems. An intermediate solution might be to immediately start processing the last integration when the Data Display tab is selected. This is a heavy on requirements and low on implementation item. MarkClark |
| 19 | 29 Aug 2006 | ABF088_01 | Ghigo | Ghigo | Running astrid on Naiad, the peak scans were not displayed and the pointing corrections were not sent to the telescope. But on the operators astrid session, the peak scans were displayed.
Eventually we just used the astrid running
on the operators machine and abandoned Naiad. | We see this periodically. I think that it would be good to have a GFM daemon which produces the pointing and focus corrections and remove that responsibility from the GFM application. AmyShelton |
| 20 | 12 Sept 2006 | AGBT06B-042 | Kanekar | Ghigo | After an observing block was saved to the database, the block did not show up in the run tab. The user had to exit out of Astrid and start up again before the blocks showed up in the run tab. | Was the observer in "offline" mode? If so, then they won't show up automatically. If this wasn't the case, then it most likely was a problem with the Pyro communication - the mechanism used by the client/server for communication with the other. If this was the case, exiting out of astrid was probably overkill - going offline and then back online probably would have done the trick. AmyShelton |
| 21 | 18 Oct 2006 | AGBT06C_028_01 | Wootten | Balser | Problems getting astrid going. These problems have ocurred before but maybe there is some additional information here.
1. Started up astrid in offline mode.
2. Worked on editing and saving a couple of scheduling blocks.
3. Switched from offline to online mode. Note that Donna S. had astrid going in monitor only mode.
4. Executed scheduling block. Nothing happens in our astrid session, although in Donna's astrid session everything looks good. That is, we are configuring and slewing to source.
5. Donna aborts. We exit astrid and then start astrid again. This time when we execute the scheduling block everything seems okay at first. That is, we see text in the log that looks good, we are configurating and slewing to source.
6. After a peak the GFM display in our session shows nothing. Again, Donna's session seems okay. She can see the data and everything looks good. We abort. (Note that Donna had to abort for us the first time since the abort button was blanked out. But the second time the abort button was active.)
7. This time we take astrid offline. I think that Donna may also have taken control and then released control. We then go online. We execute the block and everything looks good after that.
Talking with Donna and later Barry S. they say that they have tried going offline and then online and that this seems to work most of the time to cure this problem. | Looks like some kind of start-up problem where Pyro events are not being picked up. We are working on some changes broadly related to the hang-up problem which might have an effect on these type of symptoms, hopefully for the better. Good report, very helpful. MarkClark |
| 22 | 29 Nov 2006 | T_ZPEC_29NOV06 | Harris | O'Neil | GFM correctly processed the point and focus scans run at the beginning of the night, and even updatred the pointing and focus. But no message appeared to state that the pointing and focus was updated, as if the observer's gfm session was not the "online" session, even though they certainly were online for the purposes of running turtle. | We are testing a version Dec 1 that we hope will fix this problem. MarkClark |
| 23 | 29 Nov 2006 | T_ZPEC_29NOV06 | Harris | ONeil | This is not a problem, but a request. I just don't know wehre to send requests these days. When observing, we were told by Dave Rose that the project names need to always be in capitol letters. It seems to me that if this is the case, astrid should simply capitolize any [roject id given to it. | Since user's cannot specify their own project name, we should just make sure that if/when we enter projects into the Observation Management database that they are in capital letters. AmyShelton |
| 24 | 10 Jan 2007 | AGBT06C_026_02 | Dickinson | Minter | The continuum display in Data Display does not remember settings from one scan until the next. So the observers always have to reselect to see the data from both beams and both polarizations. | |
| 25 | 23 Jan 2007 | AGBT05C_027_01 | Mangum | Balser | When using Ka-band in total power mode with the Specgtrometer it appears that (1) both beams must be selected during configuration to get both polarizations for any given beam; and (2) the labels in GBTIDL and aips++ are not correct. See scan 17, for example, where the spectral line should only appear in the first beam. | The IFManager is simulating the Ka incorrectly, specifically, the simulation of the hybrid switches by a simulated transfer switches is inadequate. This is a harbinger of future receivers so the requirements for any changes need to be considered carefully. |
| 26 | 5 Feb 2007 | AGBT06C_035_24 | JimBraatz | JimBraatz | I've been having a lot of trouble tonight with gfm losing contact
with the telescope. After a few scans, gfm stops responding to new
scans. We restarted grail and that seemed to resolve the problem each
time, but that grows old quickly. The previous observer, running from
titania, did not have this trouble. So I've switched from ariel to
titania for a while, and so far so good. Is it possible this problem
could be isolated to ariel? | According to Wolfgang Baudler, titania and ariel are identical machines, both with respect to hardware and software. This problem is extremely difficult to troubleshoot after the fact. The best course of action if this occurs again is to leave Grail as it is, switch the problem Astrid/GFM session to online but monitoring only, move operations to titania, and give me a call. This will give me a chance to troubleshoot the problem. If this is not practical and Grail must be restarted, then make sure the operator also restarts turtle and online sdfits after Grail has been restarted. RamonCreager |
| 27 | 24 Feb 2007 | AGBT05C_017_01 | Balser | Balser | The observing frequencies displayed on the gbtstatus screen were incorrect (any scan number) for these Ka-band observations. The rest frequency was correct but the observing frequency and backend IF frequencies were wrong. They were set somewhere near 50 GHz and should have been near 32 GHz within the Ka-band receiver. The correct frequencies were listed by GBTIDL and the spectral line test sources had lines in the correct place so I think I was configured correctly and the gbtstatus display was wrong. Is this just a problem with Ka-band given the mm-converter, etc?
Main.DanaBalser | Yes. This is a known issue for the frequencies reported for the Ka band receiver. I will happily implement the Ka band frequency calculations in gbtstatus when it is assigned. MelindaMello |
| 28 | 2007/09/28 | TPTCSPNT | PTCS | F. Ghigo | Starting to observe with astrid after a rather difficult changeover from version 7.6 back to 7.5, I found that gfm was often not displaying the plots from peak and focus scans and was not calculating the LPCs. Meanwhile, the operators session of astrid was displaying the plots ok. After restarting turtle, grail, datacapture, things were not completely back to normal until I gave up control and then took control again in astrid. All of which suggests that when your session of astrid says it is in control, it may not completely be in control.
Also I wonder, in cases when the system complains that the LPCs are not being updated, is this because they are not being sent or received, or is it because the session of GFM is not computing them?
or can both things happen sometimes? | Mark is looking into the LPC update issue. AmyShelton |
| 29 | 2007/10/02 | AGBT07A_029 | Tom Troland | F. Ghigo | The users got the following error message from astrid when trying to load a catalog with the Catalog command:
------------------------------------
[10:37:42] Error in catalog: line 1 "/users/trobisha/obs/astrid/catalog/OH_zeeman_cat_OCT-07.py", Bad input:
Catalog specification "/users/trobisha/obs/astrid/catalog/OH_zeeman_cat_OCT-07.py" could not be interpreted as a system catalog
name, a path to a user catalog, or lastly as the the catalog contents.
---------------------------
What had happened is that they gave the wrong path to their catalog file. But the message said there was an error in line 1, so they tried to figure out what was wrong with
"coordmode=B1950"
Of courther there was nothing wrong with the contents of the file.
Surely astrid can check forthe existence of a file and tell the user clearly if the file cannot be found.
The vague statement that the problem might be one of 3 or 4 possible things is not very helpful. | Mark is currently investigating this. AmyShelton |
| 30 | 2007/12/19 | T_7C43_02 | Robert Rood | Dana Balser | An old problem: During a Peak (starting with scan 17) astrid does not reduce the data and claims a bad GO fits file. Yet Dave R. on his astrid session has no problem. When I exit astrid and return everything is okay. | |
5A38-PF-1642-03-turtle.py 
5C049-825MHz.sb 
astrid-weird-char.jpg 
astrid-config-message.txt 
What do the columns mean?