La Silla Observatory



Re-Engineering Project:

SciOp Communications


Prepared Olivier Hainaut 2002-05-19
Reviewed Jorge Ibsen
Released Jorge Melnick

SciOp Internal Use Only

Revision History

0.1 2002-05-19 first draft, ohainaut and jibsen
2002-06-09 include review comment




This document describes the generic structure of documentation and information flow within SciOps, focusing on Information Technology related aspects.

Version 0.1 of this document was circulated for comments. Comments from J.Melnick, G.Andreoni, G.LoCurto, M.Sterzik, E.Pompei were received. They are included and discussed in version 0.2 of this document (review version).


[1] LSO-PLA-ESO-90000-6: SciOp Staffing Plan, O.Hainaut.
[2] The ESO Web Policy, Neumann et al
[3] The ESO Web Standards, Neumann et al
[4] LSO-POL-MAN-000-001: Policy for ToO Observations.


DDT: Director Disctretionary Time
CCS: Cascade Style Sheets
CMM: Configuration Module Mechanism
LED: La Silla Engineering Department
SWC: La Silla Software and Communication Team


Below is a list of the various machines and what is done on them.
COMMENT: MSt: you will need a PC for dreamweaver edition
Reply: see below


A La Silla-wide working group is working on the documentation procedures in order to make them compatible with ISO-9001. This section is a proposal for that working group.


Paper documentation refers to documents that are originally designed to be printed after going through the standard "Prepared/Reviewed/Released" stages. This can be extended to other kind of documentation, like a web-based user's manual.

The Documents are refered to in a Remedy Database that is described elsewhere. In summary, that database lists all the documents, with an abstract,  an author, and a web pointer. It is also used to generate document numbers. It can be searched to list all documents related to a given query, either directly on a Remedy client or through a web client.

The main documentation repository is kayu, which runs a local CMM server. The documentation repository is structured as CMM modules. Each document is a module, which is dealt with using the standard CMM commands. In summary, this includes (for illustration purpose, a manual will be produced):
Each module must contain:
latex report_emmi.tex
dvips report_emmi.dvi -o
It must be noted that in this scheme, version numbers are handled directly by CMM.
COMMENT: (many): it will be a huge task to convert the existing documentation (which is there, but stored using many different systems) to the CMM system
REPLY: manpower will be hired. Text added:

As the conversion from the currently existing documentation repositories to the CMM repository is a major task, manpower will be hired. This is considered in the Staffing Plan [1]


Procedure to create a document

  1. Author requests a module from the Documentation officer COMMENT: MSt: how does the author know the number module name? REPLY: he does not. Rephrased: Author requests the creation of a module from the Documentation Officer. The author should provide enough information for the creation of the module in Remedy, such as a doc. title, the type of document (Manual, Plan, Procedure...), the group authoring the document (SciOp, other), etc. 
  2. Using the info received from the Author, the Documentation officer assigns a document number and module to the author. This implies
    1. create the document in the Remedy database, which assigns the Nr.
    2. create the module in the cmm system on kayu ((in the future, both operations will be merged)
  3. Author retreive the "empty" module in his personal account with cmmModify, and edit the the document. This should be done on kila.
  4. Author sends the modified, final printable "" for review and approval, do the modification required and iterate till a final version is obtained.
  5. Author checks the module with cmmCheckForArchive, and archive it with cmmArchive.
  6. Author notifies the Documentation Officer that the document is archived.

Procedure to create a new version of a document

Repeat steps 3-6 of the creation procedure.

Procedure to search and retrieve a document

Using a Remedy client (can be ARuser or Web browser), query the database to identify the document.
In the Remedy page, click on "link to document". This performs on the fly (through a CGI script) a cmmCopy of the corresponding document and puts it on-line (To Be Implemented).

3- WWW

A space on the web server (meli) has been reserved, as user sciops,

COMMENT: GLC: WWW: you may add that the documentation opened to the public has to obey to some standards (as it is done now, more or less), i.e. page format, completeness and clarity of the information.  The all WWW may be redesigned to reflect the new structure. Also protected web pages for internal use would be helpful, for example in the case I want to show a calibration plot to my instrument force, or some test results to some experts. Also the protected internal web pages should have a standard (more elastic than the public ones) to avoid the mess.
COMMENT: MSt: more info is needed on this (standard, structure, etc)
REPLY: added this whole section:

A space on the web server (meli) has been reserved, as user sciops,  located at The current information available in the various Telescope Team pages is huge, and it would be an enormous task to move all these sites under the sciops pages. Moreover, all external links to these pages would be broken. Therefore,
The structure, content and look-and-feel of the SciOp pages will be defined (in accordance to the ESO web policy [2] and standards [3]) and applied to all the sciop tree (note that, currently, the SciOp pages only marginally adhere to these standards). As consequences:



The following email lists are available as majordomo mailing lists (TOBE IMPLEMENTED)
The leader of each group is in charge of the maintenance of these majordomo lists (i.e. adding new users, removing obsolete ones). Email to these lists will be distributed to 


The only allowed email browser is Netscape, as implemented on kila.
This must trigger a reply with CC to by someone in the Department. When a reply is received, both the original and the reply are deleted (ie that email is processed).

So, at any given time, the lasilla email should countain only
In the future, could possibly evolve into a more automatic helpdesk (remedy?).

COMMENT: MSt: more specific words on ToO:
REPLY: Text added:

Special case: DDT proposals. Currently, all DDT proposal (Urgent ToOs and not urgent DDT, for La Silla and Paranal) arrive at on At the time of SciOp implementation, these will be filtered and stored in a DDT subfolder for reference. Changes are being requested on the DDT procedure, so that the emails sent include the urgent/not urgent nature of the proposal, and the telescope(s) requested, so that proper filtering can be implemented.

COMMENT: GLC: account: this triggers few things. I believe we should have at every moment an "astronomical operations coordinator" in La Silla, which is not a TIO (who can be the La Silla coordinator).  One of the tasks of the astronomical operations coordinator would be to read the lasilla account.  This is the front end with the astronomical community, so no sense to me that it is a TIO to manage this.  It should be an astronomer, who should take care of DDT, ToO, etc..  answer/redirect technical astronomical questions.
REPLY: actually, only a  fraction of the incoming email on LaSilla will require an immediate reply  from an astronomer, and it will be better addressed if forwarded to the corresponding force. If needed, the lasilla TIO can also forward it to the Astronomer Shift Leader for immediate attention (if needed, calling him). The DDT/ToO are now dealt with using the Web form -NO CHANGE.

COMMENT: EPo: 360, etc mail accounts: when the merging is done, I do not think it is a good idea to keep these accounts, the instrument+telescope forces should do, otherwise it will not be clear for the astronomers or visitors of the pages to whom address the mail, especially if a lot of advertisement will go on the new LS structure.
REPLY: these accounts are needed for day-to-day operation, as they are the contact for the team coordinator. They will not appear on any web page, and --normally-- no outgoing mail should leave them. No change.

COMMENT: MBi: Currently, we keep a lot of information in the team email accounts. It would be nice to keep this feature for reference.
REPLY: the ntt, 360... email repositories have been added



5.1- Definitions

Previous version used as main entry point for DDTs and Co.
COMMENT: MSt: ToO account arrive on lasilla, this will be time consuming and confusing. Let's separate general operation and ToOs
REPLY: done.

The current follow-up of ToO, DDT, MOS requests, ToO compensations, etc... is a time-consuming mess. A Remedy scheme will be created (TO BE IMPLEMENTED) (on the generic model of the telescope problem report), with the corresponding Web Form, with the following fields:

5.2- Work Flow

COMMENT: JMe: Paranal must be consulted for uniform implementation.
REPLY: Paranal was consulted. They basically do not need this form, as they use the USG/OT combination as main interface for ToOs and Co. Nevertheless, the sheme should be able to expand to consider Paranal telescopes/instruments.


An account will be created on kila (to minimize the number of accounts, this should be lasilla, which would simplify the handling of finding charts and similar). Its structure will be the following (can evolve with time). It will merge the current nttt, 360cat and 2p2team account and serve as repository for dynamic info (i.e. not documents). This structure has to be kept clean.



Each visitor is assigned a lsusr* account on the Linux Off-Line System. These are re-generated for each new visitor according to a template, maintained by SWC, that currently includes
COMMENT: EPo: Off line PCs: a list of non-scientific software, commonly available to all the PCs should also be defined (ghostview, xv, soffice etc...). The mirroring can be done in the same way as scisoft.
REPLY: A list is added below, based on the Kila requirement definition list. At this point, everything is standard linux distribution, so no special action has to be done.
COMMENT: EPo: Moreover: the PCs should be able to print on the telescope printers (not just one PC open,like now.)

These accounts are accessible directly from any of the Linux pc of the Off-Line system, and from X-Terms.
By default, the visitor's X-Term in the control rooms should be logged on these accounts.

Each Telescope is assigned an account on the Linux Off-Line System. This is used for data processing, off-line P2PP, etc... by the SciOp staff. These accounts can also hold limited amount of data on a long term bases (like a flat-field library).