SciOp

EUROPEAN SOUTHERN OBSERVATORY

La Silla Observatory

SCIENCE OPERATION DEPARTMENT

SciOp

Re-Engineering Project:

SciOp Communications

LSO-PLA-ESO-90000-4



Prepared Olivier Hainaut and Jorge Ibsen 2002-05-19
Reviewed SciOp
Released
2002-

SciOp Internal Use Only


Revision History

0.1 2002-05-19 first draft, ohainaut and jibsen








Content

1- INTRODUCTION

1.1- PURPOSE AND SCOPE

This document describes the generic structure of documentation and information flow within SciOps.

1.2- SUMMARY

Below is a list of the various machines and what is done on them.

2- PAPER DOCUMENTATION

2.1- INTRODUCTION

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 querry, 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:
Each module must contain:
latex report_emmi.ps
latex report_emmi.ps
dvips report_emmi.dvi -o document.ps
It must be noted that in this scheme, version numbers are handled directly by CMM.

2.2- DOCUMENTATION EDITION

Procedure to create a document

  1. Author requests a module from the Documentation officer
  2. Documentation officer assigns a document number and module to the author. This implies
    1. create the document in the Remedy database
    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 "document.ps" 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 retreive  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- EMAIL

3.1- EMAIL LISTS

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 

3.2- EMAIL ACCOUNTS

The only allowed email browsers is Netscape.
This must trigger a reply with CC to lasilla@eso.org 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 i) just arrived emails ii) CC'ed emails from lasilla to the Department, awaiting a reply.
Special case: ToOs and DDT observations requests: see below.
In the future, lasilla@eso.org could possibly evolve into a more automatic hepdesk (remedy?).

3.3- EMAIL POLICY

4- TOO/DDT AND OTHER PENDING OBSERVATIONS

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 following fields:
When a ToO/DDT requests arrive on lasilla (only valid account to receive emails), the lasilla person immediately creates a "ticket" with the Remedy form, selecting the ToO/DDT priority switch. This forwards the info  to 1/ the corresponding telescope, 2/ the corresponding instrument force, 3/ the astronomer Shift Leader (equivallent to the current La Silla coordinator), 4/ la Silla Director, 5/ visas. In case a request is for multiple telescopes/instruments, multiple tickets are created (one per instrument). As it is the case currently, the Shift Leader is to coordinate the execution of the ToO.

When a request for pre-imaging is received, or when a ToO compensation request has to be processed, the person in charge (typically a support astronomer) creates a ticket filling the Remedy form, selecting the appropriate Priority Status. In that case, emails are sent only to the corresponding requester and Instrument Force.

Everytime an entry is made in the Log field, a message is sent to the same addresses.

When a "ticket" is closed, a final message is sent to the same addresses. The shift leader is the one who closes the ToO, support astronomers close the other requests.

5- ALL PURPOSE ACCOUNT

A sciop account will be created on kila (to minimize the number of accounts, this could 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.

     

6- OFF-LINE P2PP PREPARATION AND VISITOR ACCOUNTS

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
These accounts are to be used for their off-line OB preparation and off-line data reduction. They can be used to send emails (but not to receive emails), browse the web, etc...
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).

--oOo--