| Item | Category | Requestor | Task | Details | SDD Comments |
|---|
| 5 | Observing Efficiency | BrianMason | Commissioning Support | Need to identify ways to make commissioning activities less awkward for the observer | Could be resolved by item #40. |
| 8 | Scan Types and Observing Directives | FrankGhigo | Map modification | For the map procedures the height and width arguments be specified in on Offset object rather than separately. | |
| 15 | Configuration API | KarenONeil | Review of config_tool | Review keywords and default values. Make sure that irrelevant keywords to configuration are ignored and relevant keywords are required. | |
| 14 | Scan Types and Observing Directives | FrankGhigo | Change Scan arguments | (1) Procedures' arguments should be angles rather than Locations and Offsets. (2) Would like to specify a rate in addition to specifying a distance and time. | AmyShelton to talk to FrankGhigo. |
| 20 | Usability | BrianMason | Resetting of Scan Number | When starting a new SB, it would be useful if turtle checked to see if PROJECT_SESSION exists, and if so, set the "next scan" parameter in the scan coordinator to the appropriate value; if not, set it to 1. Currently the user must ask the operator to manually re-set this to 1 every time a new turtle project starts. via the SESSION failure mode above, it's also easy to overwrite old data by starting at a too-early scan number, if you want to write data to an existing directory | We could do this on project change. Every SB is a bad idea. AmyShelton |
| 25 | Scan Types and Observing Directives | FrankGhigo | Computation of beamwidth | Tuning frequency rather than sky frequency is good enough for computing beamwidth. | AmyShelton to talk to FrankGhigo. |
| 29 | Observing Efficiency | FrankGhigo | SB multitasking | It would save a good bit of time if we could slew or move to position at the same time as the config is running, and have the possibility of completing the configuration while the antenna is still slewing to the source. | |
| 30 | Usability | FrankGhigo | Usability enhancements | Astrid should remember the project code and user name for the currently logged-in user and have these things filled in when starting up astrid. Also the directory used for importing a script should be the same one that was last used. | 20,30,44 and 45 are all related. |
| 31 | Usability | RonMaddalena | Edit Tab Cut & Paste | Edit window doesn't take the usual XTERM mouse behavior for cut&Paste. (sorry Amy ;-( I coudn't swipe and middle click to copy a line within the text widget. However, you can copy&paste with the mouse from another window into the edit text widget, though. Thus, it appears the 'copy' isn't happening on a swipe. | |
| 36 | Usability | RichardPrestage | System Restore Mechanism | How about being able to restore things to a known state? Should this even be a fxn of obs api (like for example, should it "clean up" every time it exits)? If people can completely screw up the system using the Obs Api (or anything else), is there any way to help so the resultant problems are not blamed on software??? I (Amy) would vote that we need a "revert to default state" just as we have a "revert to last legal value" in the M&C system. You can screw up the system in so many ways that it would be near impossible to catch everything and I feel that each device should know about its default state. | |
| 38 | Scan Types and Observing Directives | ToneyMinter | Need access to sampler values. | | Recommend approval. AmyShelton |
| 40 | Science Program Level | NicoleRadziwill | SB Builder | This is the GUI that would replace GO. Must be able to load up SBs and display them graphically, for editing or for saving Ability to specify globals such as coordinate mode to be used in all Scheduling Blocks | needs extensive planning |
| 41 | Offline Validation | NicoleRadziwill | Validator Upgrades | Right now, the Validate function only checks for syntactic validity, to ensure that Scheduling Blocks cannot be stored in the Observation Management Database if they contain fatal errors. To truly support offline use, we must be able to submit SBs to a full-telescope simulator and validate them for: (1) Completeness (contains enough information to set up as well as observe), (2) Configurability (make sure the SB is not asking for unsupported modes of the telescope), (3) Appropriateness (make sure the SB does not contain multiple or insufficient configurations, multiple maps, or other constructs that would make it difficult to recover from a failure or schedule the observation in a fully dynamic mode). After full validation, we should be able to tell whether a rule has not been followed that might lead to problems on the telescope (like the antenna slewing off to an unknown location), be able to tell whether there are any missing configuration keywords, and be able to tell whether an observation is capable of running with the current version of the production software. In order to implement these capabilities correctly, we must release them at the same time that a full-telescope software simulator is deployed, which is bound to the production control system software. The full-telescope simulator software that has been in place since December 2004 is bound to the test version of the software in development, which is fully appropriate given the goal of that development: to make it easier to test software under development without using excessive telescope time. Producing a new full-telescope software simulator is a substantial effort, requiring duplication of software on new hardware, and is best managed during a preventive maintenance cycle (ideally C8 2005). | Needs advanced planning. (Note, the validator does not see configurations contained within scan type definitions.) |
| 42 | Usability | NicoleRadziwill | Building SBs Remotely | Astronomers need to be able to build GBT SBs at their home institutions and upload them to the Observation Management Database easily. | |
| 47 | Usability | RonMaddalena | Interface to message mux | Add relevant messages from message mux to message log. | |
| 54 | Usability | AmyShelton | Eliminate need for Astrid to write files to directory where started. | Main offenders are Pyro and the Configuration API. | |
| 55 | Scan Types and Observing Directives | RichardPrestage | Need to review handling off offsets.
| offset arithmetic; location and offsets shouldn't be combined into antenna primary segments, may be a few others | |
| 58 | Usability | AmyShelton | Users keep losing dialogs | Users minimize or hide dialogs and then can't find them and Astrid appears to be hung up. Could force modal dialogs to always be on top. | |
| 59 | Usability | KarenONeil | Turtle needs to be able to handle red shifts | | |
| 61 | Usability | KarenONeil | Turtle should send up a warning message when it receives any command to move the antenna, yet the antenna is not in the scan coordinator. This message should give the option of sticking the antenna into the scan coordinator. It is very easy to not realize that the antenna isn't in the scan coordinator (either because it was taken out by the telescope operators, or because turtle was previously aborted during a configuration) and then try observing. This has bitten me at least once each time I run turtle. | | |
| 62 | Configuration API | ToneyMinter | Make config_tool ignore parts of devices | The 20 MHz YRB filter for the prime focus receiver is bad. The config_tool still tries to use this filter, however. There needs to be a way to tell the config_tool about bad filters (or parts of a device) and not just that a whole device is bad. | |
| 63 | Usability | MarkClark | Make on-line monitoring mode display SB information. | When turtle is in online monitor only,
and another turtle session is driving the observations, it does not fill in the project, observer, scheduling block, and data directory fields until a new block begins. | |
| 64 | Usability | FrankGhigo | Import many observing scripts at once | When using observing blocks for VLBI, it would be helpful to be able to import many files at once into the database. We should be able to select multiple files in the import dialog. | |
| 65 | Usability | AmyShelton | Consistent real time mode for all application components | Make sure that newly launched application components have the same real time mode as existing components. | |
| 66 | Observing Archiving | DanaBalser | Record Scan parameters in FITS file | It would be nice to include the parameters fed to the Scan in the HISTORY of the GO FITS file. | |
| 69 | Unclassified | JimBraatz | Abort balance if fails | We need a strong message and the option of aborting the SB when a balance fails. | |
| 70 | Usability | JimBraatz | Tab names in Astrid | When I start a second copy of an ObservationManagement tab, it is called "ObservationManagement -1". Shouldn't it be called " - 2" | |
| 72 | Unclassified | JimBraatz | Abbreviate balance output | Much of the output could be compacted, e.g. lists of power levels, duty cycles. | |
| 75 | Unclassified | GlenLangston | Save configuration state from daemon session to session | Eliminate the need to reconfigure to get GO FITS files when the turtle daemon is restarted. | |
| 78 | Source Catalog Implementation | FrankGhigo | Allow embedded blanks in source names by use of quotes. | The standard catalogs for Conic and NNTLE formats available on the web have source names containing blanks. Astrid's catalogs for those formats handles embedded blanks. The proposal is to extend the capability to Spherical and Ephemeris catalogs. | Reasonable request and provides the user a simple rule to remember. MarkClark |
| 79 | Source Catalog Implementation | FrankGhigo | Flag if a catalog row has more fields than specified by the HEAD keyword. | When checking the syntax of a catalog, the parser cannot check for missing columns because the user is allowed to leave columns blank.
Extra columns are currently ignored. The request is to accept, but warn the user when a row has too many columns. | This enhancement will catch errors which could easily be missed otherwise. MarkClark |
| 81 | Scan Types and Observing Directives | DanaBalser | Error check user's beam selection | When observing with multi-beam receivers the user has to specify the beam in two places: (1) During the configuration one has to set the beam parameter to route the desired beam with the backend; and (2) when performing a Peak or Focus scan one has to set the beamName parameter. It would be very useful if the user could get a warning message when these two parameters are not set to the same beam. The script will validate okay which gives the user a false sense that they have set everything up correctly but they have not. | I have been asked about this a number of times (after the observations were made) which implies it has bitten a number of observers. MarkClark |
| 82 | Scan Types and Observing Directives | FrankGhigo | Make scan types and observing directives case insensitive | Users often make mistakes because of having to enter the scan types with the exactly right capitalization. If we can't make the scan types case insensitive, we should provide aliases for them that are all lower case. | |
| 83 | Offline Validation | RonMaddalena | Enhance validator to check file permissions | We've had lost time due to problems with file and directory permissions. The CCC requested we add the following enhancement. The validator should check that any file it opens (catalogs, files that are runexec'ed, etc.) has read permissions for monctrl. If the permissions are wrong, the validator should issue an error message describing that the file or directory permissions need changing.
Since a user can move files between validation and when the block is run, Astrid should check file permissions before attemting to open a file. If the permissions don't allow the file to be read, Astrid should provide explicit error messages stating the possibility that the file is not readable by the monctrl account. | |
| 84 | Scan Types and Observing Directives | RonMaddalena | Add an automatic prepare to a SetValues. | My natural thought was that SetValues behavior was identical to our other interfaces and a 'prepare' would always be done. It's only by experimenting and using up telescope time that I realized that SetValues was counterintuitive and didn't do a 'prepare'. Maybe just as confusing to the users is that the line: SetValues( mgr, { paramname : newvalue, 'state': prepare}) does not work as expected since Python does not guarantee that the prepare will execute after the parameter value is changed. I suggest altering SetValues? so that the last thing it does is an automatic 'prepare' or 'activate' on the manager so that Setvalues' behavior matches what a user expects and matches the behavior of our other interfaces.
| |
| 85 | Usability | KarenONeil | Setting an illegal or non-existent beam name argument does not elicit any type of error, warning, or feedback. | Most scan types have an optional parameter called "beamName" which specifies what is being moved around the sky by Move and MoveTo commands. Entering a beamName that is inappropriate for the current receiver is not caught by the system. Note that other than the receiver selection, the system cannot know the observer's intentions, e.g., the observer may want to directy by a beam which is not configured to collect a radio signal! | Needs to be thought through, but it is likely that errors are not possible and only warnings or "heads up" are possible. |
| 88 | Scan Types and Observing Directives | ToneyMinter | Slew independence | This routinely brings forth a "feature/bug" of the slew command. The slew commands issues an activate to all devices in the scan coordinator. Since there has yet to be a configuration run in the above scenario it is quite likely that at least one of the devices other than the antenna will not be setup properly and will issue a fault or error during the activate. This then causes astrid to see an abort and ask the observer if they want to exit the scheduling block. Meanwhile, the antenna is doing the correct thing by slewing to the source. This behavior is very confusing to the observer. Most observers will exit the scheduling block without realizing that everything is actually OK and that they should just continue with the scheduling block. | Recommend approval. AmyShelton |
| 89 | Unclassified | JimBraatz | Antenna and Scan Coordinator antenna positions get out of sync | Sometimes the antenna and the scan coordinator get out of sync when the operator changes receivers by moving the antenna directly and not through the scan coordinator. We could possibly fix this problem by adding a "force" when sending antenna position commands to the scan coordinator via grail/turtle. | Recommend approval. AmyShelton |
| 91 | Usability | Anthony Remijan | Add more info to turtle log | 1) Would it be possible to list what scan # you are on as the subset entered when you hit the "submit" button. 2) Output the estimated completion time. 3) Add the offset when you are doing the off. What I mean is something like this:
"You currently entered 41 scans"
"Starting scan 1 of 41. There is ~90 mins left of observing time for the remaining 41 scans"
"Source: Sgr B2N @ RA; dec; Vlsr = 64 km/s; Off position = 1 degree"
"This subscan will be labeled as #xx in the dataset - you are in the Off position"
"Starting subscan"
"This subscan will be labeled as #xx in the dataset - you are in the On position"
"Starting subscan"
"You currently entered 41 scans"
"Starting scan 2 of 41. There is ~86 mins left of observing time for the remaining 40 scans"
"Source: Sgr B2N @ RA; dec; Vlsr = 64 km/s; Off position = 1 degree"
"This subscan will be labeled as #xx in the dataset - you are in the Off position"
"Starting subscan" | Need discussion. |
| 93 | Observing Archiving | BobGarwood | LASTON/LASTOFF keywords in GO FITS file are usually wrong | sdfits is failing to get the PROCSEQN number because LASTON, LASTOFF is not written correctly by Astrid in the GO fits files. Turtle is asking the Scan Coordinator for the "next scan" number at the wrong time, but I'm not sure how to fix it (AmyShelton) | This is a problem for Dish only, I believe. It is the only thing that uses LASTON/LASTOFF. AmyShelton |
| 94 | Scan Types and Observing Directives | BojanNikolic | Need more verbose error messages for problems in user-defined scans. | One of these is that when a new scan type is defined using DefineScan? call, any errors in the file supplied to DefineScan? cause an error message which simply ays "Error in DefineScan?" without any traceback into the file which caused the error. This makes tracking down errors in these files a little more difficult than need be. At the moment we've got all the files working but in the long term it would be extremely useful to get a full stack dump to the line that caused the validation error. | The alpha simulation capability might address this problem. |
| 96 | Usability | FrankGhigo | Turtle error when updating LFCs/LPCs | 'Traceback (most recent call last):\n',
'File "/home/sparrow/5.4/lib/python/gbt/turtle/proc/Scheduler.py",
line 150, in RunObservation?\n observation.Execute self.GetUserTelescope())\n',
'File "/home/sparrow/5.4/lib/python/gbt/turtle/proc/Observation.py",
line 102, in Execute\n exec(self.GetScript(), g, self.DefineLocals(telescope))\n',
'File "", line 3, in ?\n',
'File "/home/sparrow/5.4/lib/python/gbt/turtle/proc/RuntimeScan.py",
line 20, in __call__\n return proc.Execute(Receiver(self.telescope), Scan(self.telescope))\n',
'File "/home/sparrow/5.4/lib/python/gbt/turtle/proc/Focus.py", line 58, in Execute\n scan.UpdateCorrections()\n',
'File "/home/sparrow/5.4/lib/python/gbt/turtle/user/Scan.py",
line 54, in UpdateCorrections?\n self.GetTelescope().Execute("UpdateCorrections")\n',
'File "/home/sparrow/5.4/lib/python/gbt/turtle/user/Telescope.py",
line 270, in Execute\n return apply(getattr(self.telescope, method), args)\n',
'File "/home/sparrow/5.4/lib/python/gbt/turtle/ygor/Telescope.py", line 228, in UpdateCorrections?\n if self.antenna.UpdateCorrections() != 0:\n',
'File "/home/sparrow/5.4/lib/python/gbt/turtle/ygor/Antenna.py", line 107, in UpdateCorrections?\n if self.startTime < modificationTime and \\\n',
'File "/home/sparrow/5.4/lib/python/gbt/ygor/LocalCorrections.py", line 46, in __getitem__\n return self.values[key]\n',
"KeyError: 'last_scan'\n" | |
| 97 | Usability | RonMaddalena | Make use of scanId | [ Here's a plug for moving us into the e2e world. I've said this before but I'll put it in writing so we can place this kernel of an idea into our to-do files. ] Right now, scanId is not something one can easily modify in GO or Astrid, though I have used it from CLEO from time to time. I see a really good use for ScanID? that Amy & co would want to exploit in Astrid at some point. We all realize that the name of the observing procedure is not enough to convey the observer's intent for such things as calibration, source intensity, etc. Mark designed scanId to help hold observer's intent plus extra information about the source beyond a source name. And I see no reason why we should exploit it, or something like scanId, at some point. scanId is currently a free-form piece of text but that need not be how we use it. For example, Astrid could have a 'directive' where the observer can select from a list of options the kind of information we'll need to implement e2e calibration. Or, information GBTIDL will need for, for example, finding specifications for off positions in a pointed map. Or real-time GBTIDL could be made a bit smarter in what it does by using scanId. scanId or something just like it, might make a good way to store that information in the Keep files. So, putting scanId on the shelf is probably a good idea for now. But, I'd like to see it, or something like it, utilized in the not-too distant future. | |
| 98 | Usability | KarenONeil | Monitoring SBs | Turtle needs to be able to tell the observer/operator what line or source it stopped on when it aborts (or is aborted/stopped), and also to have the ability to restart observing on that source or line, with the option of configuring the telescope first. For example, my project pretty much does the same thing over and over again, running down a source list. I could easily imagine having separate .py files for the project: a file which does the configuration for the dcr and runs a peak, a configuration file for the spectrometer (my usual observing method), a .py file describing the type of observation I want to do, and a source list for the night. If the telescope had to stop in the middle of the run, I should be able to tell the operator to run the configuration file and then start observing at whatever source things stopped on. Or even (if, say, we had a wind shutdown for an hour) to skip 6 sources and then start observing. | |
| 100 | Usability | AmyShelton | Periodic saving of observing log | Periodically save observing log to database and to project data directory. Currently, we just write it out at the end of a SB and it could get "lost" if the SB doesn't complete properly. | Recommend approval. AmyShelton |
| 102 | Usability | KarenONeil | Add sort to SB list in Edit/Run tabs of Turtle | Sort by name + time modified | |
| 103 | Usability | JimBraatz | Text highlight bug in Turtle | While sweeping text from the log window, the astrid cursor got stuck in an angle/plus-sign shape, and the whole workstation locked up. I had to kill astrid from another system to fix it. | |
| 104 | Usability | JimBraatz | Consolidate GFM/Turtle logs | Could we consolidate the two logs (ObsManagement? and DataDisplay?)? It is still difficult to keep track of what the telescope is doing because of feedback going to too many different places. | |
| 105 | Usability | JimBraatz | Rename "Interactive" button in Turtle | I recommend renaming the "Interactive" button to "Bypass Pop-ups" or something like that, to give a clearer idea of what it does. | |
| 106 | Usability | JimBraatz | SB scrolling behavior | When I submit a SB from a lengthy list, the list of available scheduling blocks scrolls all the way up to the top, requiring lots of scrolling. Better if it stay put. | |
| 107 | Usability | KarenONeil | Check for unsaved files before exiting Turtle | Check to see if SB is unsaved and offer user a chance to save SB when exiting Turtle/Astrid | |
| 108 | Usability | JimBraatz | Command line options for Turtle | It would be nice to interact with Turtle via a command line rather than the GUI (Turtle client) | |
| 112 | Usability | ToneyMinter | Oscillating Project field. | The Project field in the Edit or Run tabs can get into a state where it osillates between two different selections, rendering the Astrid window inoperable. | Still happening? AmyShelton |
| 114 | Unclassified | ToneyMinter | Turtle doesn't apply GFM LPCs/LFCs | The LPCs did not update on the first attempt at AutoPeakFocus?. The peaks looked ok but astrid timed out saying it didn't get the values although gfm looked as if everything was ok. | Recommend approval. AmyShelton |
| 115 | Observing Efficiency | ToneyMinter | Sun Avoidance | The Auto procedures should not select calibrators near the sun or moon. | This requirement needs to dovetail with other avoidance issues such as sources setting and rising. In other words, the requirements need to be carefully thought out. MarkClark |
| 116 | Usability | BrianMason | Astrid Hangs | I have occasionally had a problem wherein astrid hangs my entire desktop. I don't know quite what happens but I can't do anything at all until I log in to another computer and kill python. | Recommend approval. This will probably take quite a bit of time to track down. AmyShelton |
| 119 | Source Catalog Implementation | FrankGhigo | Selection of subsets of catalogselection of subsets of catalogs | Accept sets of criteria to generate lists of sources from a catalog. See SourceCatalogSpecsV2. | Doable, really needed? MarkClark |
| 120 | Source Catalog Implementation | FrankGhigo | Intelligent Tracking | Automatic handling of rising, setting, and fast objects. See SourceCatalogSpecsV2. | This requirement needs to dovetail with other avoidance issues such as sources near the sun and moon. In other words, the requirements need to be carefully thought out. MarkClark |
| 123 | Usability | JoeBrandt | Incomplete setting of source velocity in LO1. | Does the use of the function SetSourceVelocity fail to set the time and derivatives of the LO1's sourceVelocity? | If true, could be a nasty surprise for someone. MarkClark |
| 125 | Observing Efficiency | JimBraatz | Scan types return values. | Scan types, especially the auto procedures, should return success or failure. | Clear requirements would be needed for the criteria of success and failure. Also affects gfm. MarkClark |
| 126 | Usability | AmyShelton | Dialogs in client need to go away after appropriate timeout | Right now, if a default action is taken after a user interaction request timeouts out, the corresponding dialog remains. This should automatically disappear if the timeout occurs. | Needed. AmyShelton |
| 127 | Usability | JimBraatz | Need communication between turtle and gfm | When the option to accept bad fits is turned on, then the "No New Corrections Detected" popup should be disabled. Currently it appears, unnecessarily, while the user is trying to decide whether or not to accept the fit. | Good point. Unfortunately at the moment, turtle and gfm don't communicate directly. turtle just looks at the LPCs file and pops up the message after a set timeout. AmyShelton |
| 128 | Usability | JimBraatz | Modal dialogs prevent users from moving about Astrid | More on interactively accepting "bad" fits: When I get the popup asking if I want to accept the fit, I am not able to switch tabs. Big problem, because typically one will go work on an astrid script while waiting for the peak or focus to finish. When it does, there is no way of getting back to the display tab to inspect the data in order to make a decision on whether to accept the fit. | Yeah, we actually made this a non-modal dialog in the past which would allow you to change tabs, etc. However when we upgraded to the new wxPython library, we had to change the dialog to be modal because it wasn't appearing at all.  I will add this to the astrid to do list (ObservingToolsRequests). There is a newer version out (2.6.3.2 vs 2.6.1.0) - maybe that bug is fixed. AmyShelton |
| 129 | Usability | JimBraatz | Sizing Issue | There are problems resizing astrid panel. When the spectral line plugin is shown, and the plot panel is expanded, the "Overlay" button is partly obscured and it is not clear if there is anything below it because I can't tell if the whole window is being displayed. | |
| 130 | Usability | ScottRansom | scheduling block scrolling (see #106) | Most pulsar observers keep their scheduling blocks ordered alphabetically (they name things A_config, B_slew, etc). But when there is a long list and you submit one from near the bottom, the screen jumps back to the top. This means that you need to scroll back to the bottom again. | |
| 131 | Usability | ScottRansom | scheduling block organization in list | How about being able to click the column header buttons so that the blocks are sorted in that list. That way you can find the most recently edited block in the list by clicking on the modification time column. | |
| 132 | Usability | ScottRansom | Scheduling block copying | The copying of SBs from one project is still a PITA. How about having a "copy to" button(s) in the Edit tab that brings up a dialog where you specify another project (maybe from a drop-down list, where the last-selected value is the default) and the selected block is copied to that project. Alternatively, a "copy from" button could bring up another SB window where you could select a group of SBs from another project and copy them into the current one. | |
| 133 | Usability | FrankGhigo | About dialog | It would be helpful if in the About screen the astrid version number was displayed. Any other information would also be helpful, such as env variables like YGOR_TELESCOPE. | |
| 134 | Usability | FrankGhigo | Session Numbers & Incrementing Them | We've really got to stop astrid from incrementing the session number! This "feature" almost always is bad as far as I can tell.
In this last PTCS session I wanted the session number to be 070929. But when
the operator took control for his session of astrid, the session number in his version was 70930, thus putting the data in a different directory. Whenever astrid is re-started, which can often happen during an observing run, or when control is passed to a different session, astrid increments the session number. The PI has to be very careful to re-set it to what is really desired.
I can imagine that an auto increment of the session number may sometimes be desirable, so let me suggest a compromise:
Whenever astrid feels like it might want to change the session number, have it present the user with a dialog such as:
1. keep session 070929 ?
2. increment session -> 70930 ?
3. enter new session number : .... ?
| |