| 2 | 46 Aug 2006 | AGBT06B_020_09 | O'Neil | O'Neil | The antenna was in an error state, due to truck #4 being turned off. Both thte scan coordinator and the astrid & GBTstatus "GBT status" windows correctly reflected this error state foe me, but the CLEO message window did not, even though the error did appear for the telescope operator. -Main.KarenONeil | The inability of the message system to reliably assert alerts is of serious concern for us. JoeBrandt has one fix for such problems, but a true resolution will require a more concerted effort. MarkClark |
| 5 | 2006 | Pointing | Balser | Balser | Although the observing process has significantly improved over the last year or two there remains some nagging problems that seem to plague pointing runs more than standard astronomy. Here I list these problems as a summary of observing problems during pointing runs in 2006. These are by no means show stoppers but it would be very nice if they were fixed.
1. During most of the year the archivist did not work for the weather station data. This is essential for most PTCS runs. Furthermore, I think the weather should be archived with all projects (commissioning and astronomy). Yes, one can always go the the logs but the whole point of the archivist system is to allow the user to archive the data they want. It was a good idea and it is very useful! It would be even more useful if it were robust. (Thanks Joe for fixing the weather archivist before my last run. It seemed to work fine!)
2. While the validate process in astrid is extremely useful it sometimes performs evil acts. I am sure I do not understand exactly what it does. It seems to run the scheduling block without really running the scheduling block, except that it does run some things. In having to be more creative with PTCS commissioning we required code that probably was not within the scope of astrid and this has caused some problems.
I will only give one example to illustrate my point. When trying to perform an all sky pointing run it was necessary to save information about the current direction of the (Az,El) grid. To do this Amy suggested we just save this information to a file and read it back in. This seems to work okay but when you save the scheduling block to the database, and hence validate, it runs the code and thus changes the file.
I wonder if one can validate without really running the code since this can (1) cause some very subtle problems; and (2) it takes quite some time to validate large loops.
3. We still get the message that no corrections are detected when doing pointing. During pointing runs this, of course, happens more frequently. I know people have worked on this problem but it just seems to me that it should be easy to pass two numbers from one piece of software to another.
4. During every pointing run we continuue to get the message that the GO FITS file is malformed. I am told by the operators that they see this problem far more often during pointing runs. Is this because we generate more scans? I don't know.
Dana
| wrt#1: There are several problems with the Archivist. Several of the problems result in a core dump, however the problems seen with the weather station are less obvious. Bottom line here is that time is needed to fix the archivist, as a scheduled activity. JoeBrandt wrt#2: Indeed the validator needs to be enhanced to prevent users from doing unintended things during validation. There are a whole host of items also surrounding validation. We need to figure out how to get enhancements to the validator on the schedule. In the meantime, there is an easy work-around to avoid this problem. Simply create your own custom ScanType and place the offending code within the Execute method. I'd be more than willing to help you with this. AmyShelton Okay, this is something that one might want to do in the future. DanaBalser wrt#3: I have a good idea of what could be done to alleviate this problem. We need to free up resources and get time to fix it. AmyShelton wrt#4: I haven't heard about this before. Can you tell me the project id and session so I can look at the log. Or (even better) can you send me the log? AmyShelton I don't have the log but the project id's were TPTCSPNT_060817, TPTCSPNT_60817, and TPTCSPNT_060818. DanaBalser Thanks for the additional info. When I write my original response I assumed that the error message was displayed in the observing log. But now that I reread your entry, it sounds like the error was in the GFM log. Is that the case? I'll rerun your projects offline with GFM and inspect the logs. I'm guessing that they will probably reduce fine after the fact and that there was some sort of NFS slowness which prevented GFM from "seeing" the GO FITS file in time for the data reduction. This can usually be determined while observing by openning up a separate GFM session and reselecting the failed scans. If this is what happened, this could be prevented by moving to data streams rather than relying on the reading of FITS files for real-time data reduction. AmyShelton |