EUROPEAN SOUTHERN OBSERVATORY

La Silla Observatory

SCIENCE OPERATION DEPARTMENT

Re-Engineering Project:

SciOp Communications

LSO-PLA-ESO-90000-4

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

SciOp Internal Use Only
FOR REVIEW

Revision History

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

Content

1- Introduction
- 1.1- Purpose and Scope
- 1.2- Summary
2- Paper Documentation
- 2.1- Introduction
- 2.2- Documentation Edition
3. WWW
4- Email
- 4.1- Email Lists
- 4.2- Email Accounts
- 4.3- Email Policy
5- ToO/DDT and other Pending Observations
6- All Purpose Account
7- Off-Line P2PP Preparation and Visitor Accounts

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.

kayu

cmm documentation repository
email repository

meli

web server
contains the sciops web pages
cmm client for documentation

kechu

remedy server

kila

lasilla, ntt, 360 and 220 accounts.
personnal accounts for each sciop members
cmm client for documentation
edition tools (LaTeX, FrameMaker, etc...)

Linux Off-Line Data Reduction System

visitor off-line work in lsusr* accounts
sciop staff data reduction and off-line work

2- PAPER DOCUMENTATION

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.

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:

cmmCreate(?) document: creates the "document" module. "document" should be a doc.nr, something like LSO-MAN-ESO-90100-1234. This is done by the documentation officer.
cmmModify -l user document: retreive the latest version of the document module for edition. yser is the cmm account of the person retreiving the document. This is done by the person in charge of the edition of the document.
cmmCheckForArchive -l user document: check that the new version of the document is ready to be archived
cmmArchive -l user document: archive a new version of the document. This automatically generates a new version number.
cmmCopy document: get the last version of the document module.

Each module must contain:

all the source code (e.g. LaTex.tex files) needed for the document
all the figures, tables, etc...
a short README file describing:

very shortly the content of the document
how to generate the final printable document, eg

latex report_emmi.ps latex report_emmi.ps dvips report_emmi.dvi -o document.ps

the final printable document, which must be named document.* (document.ps, document.pdf, document.html...)

It must be noted that in this scheme, version numbers are handled directly by CMM.

2.2- DOCUMENTATION EDITION

Procedure to create a document

Author requests a module from the Documentation officer
Documentation officer assigns a document number and module to the author. This implies

create the document in the Remedy database
create the module in the cmm system on kayu ((in the future, both operations will be merged)

Author retreive the "empty" module in his personal account with cmmModify, and edit the the document. This should be done on kila.
Author sends the modified, final printable "document.ps" for review and approval, do the modification required and iterate till a final version is obtained.
Author checks the module with cmmCheckForArchive, and archive it with cmmArchive.
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- WWW

A space on the web server (meli) has been reserved, as user sciops, located at www.eso.org/lasilla/sciops.

4- EMAIL

4.1- EMAIL LISTS & ALIASES

The following email lists are available as majordomo mailing lists (TOBE IMPLEMENTED)

Instrument forces:

ls-imaging@eso.org,
ls-infrared@eso.org,
ls-spectro@eso.org,
ls-hires@eso.org and
ls-telescopes@eso.org

Generic lists:

ls-sciops@eso.org: all SciOp staff, this is an alias joining the 3 following lists:
ls-astro@eso.org: all the astronomers
ls-tios@eso.org: all the TIOs
ls-openg@eso.org: all the op.Eng.

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

all the members of the Force or group, for info or action,
an email repository on kayu (imaging@kayu.ls.eso.org, etc), see below.

4.2- EMAIL ACCOUNTS

The only allowed email browsers is Netscape.

lasilla@eso.org: front end to sci-ops, to be used as generic entry point and helpdesk. This will be made clear on the SciOp webpages. By default, any generic request should arrive at lasilla. During the day, La Silla is manned by the Top Telescope Coordinators (and during the night, by the TIO of the telescope on which the Top Telescope Coordinator works), who should

frequently check for new mails (several times per day)
forward every mail (possibly making the subject line more descriptive) to

one of the Instrument Forces, or

one of the Telescopes, or
head of SciOp for emails of "political" or managerial nature, or
another department (LED, SWC, management...) if that email was not meant for SciOps

with CC to lasilla@eso.org, and

delete the original message as soon as the CC of the forward has arrived back.

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?).

ntt@eso.org, 360@eso.org 220@eso.org (which should be connected to the current team addresses for continuity). Telescope specific. This is the email of the telescope coordinator. He should either deal with it (e.g. urgent information about something happening at the telescope), or forward to one of the Instrument Forces. As soon as a mail is dealt with (or forwarded), it is deleted, so that these account should be always almost empty. The home directory of these accounts should (and will) be kept empty: they are used only for email. As the lasilla account is manned by one of the TIOs, emails received on lasilla should be forwarded on the corresponding telescope account only if it is of interest for the other TIO of that telescope.
imaging, infrared, spectro, hires, telescopes@kayu.ls.eso.org: email repositories. They just store the mails received on the ls-imaging@eso.org, etc, mailing lists for long term history (say, 1year).(TOBE IMPLEMENTED)

4.3- EMAIL POLICY

Incoming emails

in all the SciOp accounts (lasilla, ntt, 360, 220), mail should be read exclusively using Netscape.

lasilla, nttt, 360 and 220 (i.e. the day-to-day operation account) should be kept "empty", i.e. contain only the "active" messages. A message is deleted as soon as is processed (i.e. dealt with, or forwarded to one of the forces).

incoming email of "political" nature will be forwarded to and dealt with by Head of SciOp.

Outgoing emails:

reply to emails that was forwarded by lasilla, or CC'd to lasilla must be CC'd to lasilla so that the original message can be deleted on lasilla.

inside sciOps: all sciop-related email must be CCd to at least one of the account SciOp accounts (lasilla, Telescopes or Instrument Forces) above. Use common sense to select which, e.g. urgent stuff related to instrument problem should be sent to the corresponding telescope and to the corresponding instrument force. SciOp emails that are not of general interest must be CC'd to the head of the corresponding Force, or to the head of SciOp in case of administrative or political emails.

5- 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:

Requester: name of the requester (cut and paste from original mail)
Requester email: email of the requester (cut and paste from original mail)
Short Title (cut and paste from original mail)
Telescope+Instrument: menu, select.
Priority status: select from ToO/DDT, PreImaging, ToO_compensation.
Status: selection buttion: rejected/assigned/completed/obsolete
Request (a cut-and-paste of the original email)
Log: where the observer reply.
Telescope Time: field to add hours to the Total Telescope Time
Shutter Time: field to add hours to the Total Shutter Time
Total Telescope Time: automatically gives the total telescope time spent on that ToO.
Total Shutter Time: automaticaal gives the total shutter time on that ToO
Current La Silla coordinator: email of the astronomer shift leader, automatically updated daily from another form.

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.

6- 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.

~lasilla

/ntt

/generic: stuff related to the telescope, e.g active optics business.
/susi: stuff related to that instrument. This is the home of the Instrument Core.
/sofi
/emmi

/220:

/generic
/wfi
/feros

/360

/generic
/efosc
/ces
/timmi
/harps
/adonis

/infrared

/generic: home of the Instrument Force.
link to ~/ntt/sofi
link to ~/360/timmi

/spectro

/generic
link to ~/ntt/emmi
link to ~/360/efosc

/hires

/generic
link to ~/ntt/emmi
link to ~/360/harps
link to ~/360/ces
link to ~/220/feros

/imaging

/generic
link to ~/ntt/susi
link to ~/ntt/emmi
link to ~/360/efosc
link to ~/220/wfi

/observations

/serviceObservations: info about the generic Service Observing Programs

/ntt
/360
/220

/pendingObservations: Info on ToO compensation, Pre-Imaging, etc...

/ntt
/360
/220

/ToO: finding charts, etc...

7- 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

scisoft, latest version
scisoft local configuration (MIDAS printers, etc... Details TBD).
p2pp and corresponding configuration files:

Instrument Packages (LaSilla instruments updated upon requests, other instruments updated 2x/yr)
Standard Calibration OBs (updated upon request by the corresponding Instrument Scientist).

standard Netscape configuration: home page points to www.ls.eso.org,

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--