CIMA To Do List

A list of bug fixes and upgrades suggested to CIMA

This page is a discussion and work-in-progress page for the CIMA users working group which will discuss and prioritize how CIMA should be improved.

To submit a suggestion, send an email to the CIMA administrator (see address at bottom of this page).

Bugs and minor fixes

Idea Description Comment
* Warning when observations are done without the back-end being configured CIMA should warn the observer if (s)he tries to observe without having configured the back-end. This is mostly a problem for interim correlator users, since the default configuration for the interim correlator is to take data WITHOUT storing it. This feature already exist, however, it does NOT catch the situation when an observer tries to configure a back-end but the attempt is rejected because the executive is busy.
* WAPP restart button for spectral line observers The WAPP restart button is hidden in a submenu to the pulsar menu, which is an awkward location for spectral line users. Another button could be added in the correlator menu or in the utilities menu (where the other restart buttons reside)
* Write WAPP power levels to log The attenuator settings for the WAPPs are currently reported to the CIMA log when the power is adjusted, but the power levels are not. Fairly easy to implement.
# Telescope positions in observing status window Adding telescope positions to the observing status window could be useful, especially for remote observers who then could avoid launching the big 'aostatus' window. The coordinates should probably be Az/ZA as well as the currently used system. There is a risk that the observing status window grows too big if we add to many features to it. One possibility could be to add options so that the observer can choose what (s)he wants to be shown.
# Current azimuth shown for source selections It would be useful not only to see the zenith angle but also the azimuth when selecting sources in the pointing window. Should be fairly easy to implement.
E Always send correlator configuration before an observing command CIMA would always send the correlator configuration to the correlator before it sends an observing command. Sounds a bit unnecessary. This was suggested to cure a problem that has already been solved in another way.
C Abort and Stop buttons just in one place Currently, there are Abort and Stop buttons in three different places: the observing window, the observing status window and the log window. It should be enough to have them in one place. We just have to agree on where they should be.
E Ask for email address at start-up Add another question asking the observer for his/her email address when starting up CIMA. The email address could then be added automatically to any RFI report/CIMA comment. It would also provide a contact address in case there is a problem and the observer do not send any comment.
* CIMA news shown at start-up Should we add a small box with CIMA news when CIMA is selected or launched that could inform about new versions etc? The real problem is: how to communicate changes in CIMA to the observers.
A Single command to slew the telescope and rotate ALFA simultaneously Should we add a command to command file observing that slews the telescope and rotates ALFA to a certain sky angle in one go? The two things can be done in parallel so there is performance to be gained. This possibility may also be useful for some ALFA observing modes.
* Include 430 MHz filterbank selection The Gregorian 430 MHz receiver has a filterbank that should be set from CIMA. This is fairly easy.
* Include ALFA filterbank selection The ALFA receiver has a filterbank that should be set from CIMA. This is fairly easy.
* Stop the telescope by tracking current Az and ZA Currently the 'Stop telescope' button uses the command to hold the telescope. This would be more straightforward since it doesn't need the release command to be issued. This is easy.

Larger projects

Idea Description Comment
# WAPP power levels The WAPP power levels are not shown in the back-end window when ALFA is selected. Also, power levels for non-ALFA are shown but not updated continuously. Should they be added or should we have a new small power level window that adjusts to the selected receiver/back-end mode and that updates contiuously? Would be derived from the 'alfaobswin' window.
# WAPP power level warning CIMA doesn't complain if the power levels to the WAPPs are way out. Some sort of warning would be useful. Should it just check the levels after a power adjustment or do it continuously? How do we handle a bad ALFA amplifier?
* Sound for remote observers It would be useful also for remote observers to get audio warnings for errors and incoming messages in the chat box. This is difficult since we don't know what sound capabilities a remote computer has. However, what could be done fairly easily is to use the terminal bell.
# Standardized spectral line observing options Options for the various spectral line modes could be more standardized. For example, some modes allow the observer to select the length of the calibration scans while other modes just use hard-coded values. This would be fairly straight-forward to implement. Some interim correlator modes have values hard-coded though.
? Automatic FITS-file creation Currently CIMA allows the observer to control when and what goes into each WAPP FITS-file. This prevents us from creating a better, straight-forward FITS-format by avoiding writing data on the heap. We need a good FITS-format that can be used on the other back-ends as well and the current format is not a very good one. The suggestion is to remove the 'New FITS-file' buttons and automatically create a new FITS-file each time the 'Observe' button is hit. The options to divide a loop of observations into several files should be retained for those observing modes which have it and be added to those which don't. It is a bit painful to change the data format, but helps us a lot down the road.
# Collecting similar WAPP messages When running the WAPPs, messages scroll of the log window rapidly since all messages from the WAPPs are repeated once for each WAPP. The situation could be improved by collecting identical messages from the different WAPPs and present them on a single line. For example, we would have just one line saying 'WAPP 1+2+3+4 DONE with spectra' instead of four lines saying 'WAPP(n) DONE with spectra'. This has to be done with some cleverness, but is not that difficult to do.
# Improve the observing logs The logging routines would be modified so that all messages going to the CIMA log file and the log display window should be tagged with an originator (i.e. computer/program/procedure) that generated the message as well as a type that classifies the message (warning, error, status, alert, debug etc.). This is done to some extent today (We do have the ERROR, WARN and DONE classes) and messages generated from other computers are reported with an origin. This should be done with all messages generated in CIMA. This would be a help when debugging problems. It also would allow the observer to select what kind of messages to write to the log file and show in the log window. An observer could thus decide to switch off debug messages and low-interest messages and then switch them on if (s)he runs into some problem.
D Menus versus entry fields In some windows, the observer has to type in numerical values by hand and in other windows they are selected from pull-down menus. Which is the preferred way to do it? It would be nice to do things in standard ways everywhere it is possible. Some modes can't take any value and then a menu is more appropriate. Maybe the pulsar way would be useful: to have both a menu and an entry field?
# Validity check of input values Currently CIMA does not do very much validity checking. In most cases, CIMA just assumes that the observer always types in sensible values. Complete crap can thus be passed on to other systems, in the worst case causing system or program crashes. This is useful but takes some time to implement.
D Flexible input of times and angles Right now the format is very rigid for a number of parameters; they have to be given in seconds or minutes or as 'hhmmss.s'. With a more sophisticated interpreter there would be more flexibility. For example, an integration time could per default be in minutes but could also allow you to give an integration time as '1m20s'. Could be nice sometimes, but do we really need it? Inputs could be changed from arcminutes to arcseconds instead.
# Better handling of configuration files The handling of configuration files could be improved to better show what configuration files contain, to allow selection of what to read in from a configuration file and to allow automatic set-up of IF/LO-system and back-ends. This would be quite useful.
E Command stacking When the executive is busy it just rejects further commands. This could be changed so that commands are accepted and put on a stack for later execution. If this is implemented, it is important that it is implemented in a clever way to avoid confusion.
# Only show relevant modes Currently, both pulsar and spectral line observing modes are shown regardless of which mode the observer has selected. Also, all observing modes are shown regardless of whether they are available for the selected back-end or not. If CIMA would only show the relevant options, some menus would become less cluttered and less confusing. This would be fairly easy to implement.
# Improving IF/LO and backend set-up Currently there are several windows dealing with these set-ups, and things can be done in several ways which are confusing for many observers. It would be good to redesign the way the set-up is done to make it more logical/easy to use. Would be useful but needs to be discussed carefully.
D Add command file commands for remaining observing modes Although the list of available observing modes for command file observing is going to be improved with CIMA version 2.1, there will still be a number of modes that don't have commands set up. Should they be implemented when they are needed? A short-term solution is always to use the EXEC command. Observers should know that they can ask for it.
D Add new specialized command file modes Pulsar observers already have a specialized mode PULSARCATOBS that in one command combines the operations of selecting a source, rotating ALFA and carrying out an observation. For some of the surveys, it could be useful to have similar specialized modes that, for example, could read source positions and other parameters from a specialized file. This could make command file generation easier. If specialized commands are fairly straight-forward, they could probably be implemented fairly rapidly. Observers should know that they can ask for it.
* Remove or fix unused modes There are some observing modes that have bad options and does not work as intended. It seems that they are never used by anyone. Should they be fixed or removed? Things that are really not needed should be removed in order not to waste time maintaining ununsed features. Several broken pulsar modes have been fixed. The hex map will be removed.
# Quick start scheme For beginners and for standard observations, there could be a quick start scheme which guides the observer through the set-up process by popping up menus and asking for receiver, source, back-end and frequencies as well as correlator set-up. Could be useful, but we need to discuss how to do it.
* Possibility to select telescope wrap CIMA should allow the observer to select which telescope wrap to use. Default should be '-1'. Should be fairly simple to add, but note that some interim correlator observing modes have the wrap set-up hard-coded into them.
D Command file recording This would be an alternative way of generating command files instead of having to write them. CIMA could then be run off-line in a 'recording' mode to record an observing session to a command file by clicking buttons to select receiver and source, setting up IF/LO and back-end and finally making observations just like during a normal observing session. Then at the telescope, the 'recorded' command file can be loaded to 'play back' the session. Is this interesting at all? One problem is if observers then want to use these files as templates, since the easy way to implement them is using the EXEC command.
E Auto-creation of project directory Currently CIMA does not allow an observer to start if the project directory does not exist. Should this be changed so that CIMA could create a non-existing project directory? We don't want to have observers creating new directories when they are typing in the wrong project number. This has mostly been a problem for pulsar observations, but Gomathi's automatic scripts have been updated to deal with them as well.
# Text version of aostatus The aostatus screen is big and slow for remote observers. A compact text-based version could be developed for remote observers. There is already a small text-based window for this. Should that one be developed further?
# New backends CIMA needs to be adapted for the new PALFA and EALFA machines. This has to be ready when they arrive.
E Commensal observing Since there are more commensal observing projects coming, maybe we need to implement a way for several observers to run CIMA together, each controlling a different back-end? This needs to be discussed. Is there really enough things that a second observer can do, that justifies the effort to implement such a facility?
# 800 MHz WAPP observing The 800 MHz observing capability for the WAPPs needs to be implemented at some point. This will probably take quite some time and will need a lot of testing time.
D Improve the quick-look display for single pixel receivers Although the data quick-look display can be used with single pixel receivers, menus and labels still assume that the different WAPP channels correspond to different ALFA beams. This is mostly cosmetical, but some people may think it is important.
D Time to block in aostatus window It would be useful to display the time it will take before the telescope is going into the zone where it will block the cable car. This would be useful for people who need to go up to the telescope. Maybe it should be part of a bigger upgrade of the aostatus window.
C CIMA for VLBI Currently the VLBI people do some of their set-up by manually typing commands into VX-works. That procedure could probably be incorporated into CIMA. Should it be a separate mode (i.e. not line or pulsar)? The VLBI people have to tell what they want.
D CIMA for radar, aeronomy or others Are there any other users who could be interested in using CIMA? If so, they have to speak up and tell us what they want.
B A new CIMA manual We need a new manual for how to use CIMA. It is a big but necessary project. Should it be started now or should we wait until some of the items on this page have been implemented?

The codes given indicates suggested priorities and have the following meanings:

You can return to the main CIMA page by clicking here.

This page is administered by Prakash Atreya ( patreya (a) naic . edu ) and was last updated on 11 December 2008.