Documentation

With the completion of the cookbooks for ALFOSC and NOTCam now all the instruments operated through the sequencer observing system are defined in a common way, where parts common to the instruction for users of different instrument now are taken from the same source so relevant changes only have to be made in a single place. This strongly limits the possibility of having different (incorrect) information about the same thing being present in various places, while making maintaining the cookbooks easier and less prone to error.

A common access to all the cookbooks can be found at

http://www.not.iac.es/observing/cookbook/current/

where one either can choose one of the instrument, or only get all the information relevant for observers when observing with a visitor instrument.

With all the new cookbooks the printed documentation in the control room has changed to smaller, more concise booklets with the relevant information for each instrument separately. It was noted that the printed documentation for the TCS in the control room was rather outdated and scattered. A printed version of all the information about the new TCS in a single binder will be made. There was some discussion how extensive this should be as for, e.g., including a copy of the original TCS manual where the question is if that would be relevant for regular users. Maybe a general user version and a more complete version for the staff should be provided. Also, all outdated printed information will be removed.

The new sequencer command documentation database was introduced for ALFOSC. At the moment we are discussing the issue of defining the Type for each command/script. Specifically, what names are needed to describe commands/scripts such that they can be properly searched and selected in a structured way. E.g., it should be possible to (only) view all the commands/scripts needed to do spectroscopy, or the basic commands/scripts that are normally needed for observing (where there could actually be [significant] overlap between these different selections). A direct implication is that a command/script can have more than one Type. A full list of the possible Types that commands/scripts can have is being made. On the basis of this, for each command/script one or more Types should be set to define them, where the database then provides a way to select them in a dynamical way. This would also allow to simply add a new command/script with the appropriately defined Types.

In the end all sequencer commands and scripts will be managed through this database system.