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

Revision History

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

Content

1- Introduction
- 1.1- Purpose and Scope
- 1.2- Reference Documents
- 1.3- Acronyms
- 1.4- 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

5.1- Definitions
5.2- Work flow

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, 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.2- REFERENCED DOCUMENTS

[1] LSO-PLA-ESO-90000-6: SciOp Staffing Plan, O.Hainaut.
[2] http://www.eso.org/webproject/policy/web-policy.html: The ESO Web Policy, Neumann et al
[3] http://www.eso.org/webproject/policy/eso-guide.html: The ESO Web Standards, Neumann et al
[4] LSO-POL-MAN-000-001: Policy for ToO Observations.

1.3- ACRONYMS

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

1.4- SUMMARY

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

kayu

cmm documentation repository

xxx (possibly kayu or wMos, TBD)

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

COMMENT: MSt: you will need a PC for dreamweaver edition
Reply: see below

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

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. user 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.tex 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.
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]

2.2- DOCUMENTATION EDITION

Procedure to create a document

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.
Using the info received from the Author, the Documentation officer assigns a document number and module to the author. This implies

create the document in the Remedy database, which assigns the Nr.
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 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 http://www.eso.org/lasilla/sciops. 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 current lasilla/telescopes structure will be preserved for existing information.
lasilla/sciops will contain pointers to the various telescopes, intruments and other generic sciop info.

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:

all the individual pages will have to be created or updated using DreamWeaver to include Cascade Style Sheets (CCS) info. Manpower will be hired to perform this transformation, cf [1].
template pages will be created (i.e. just having the CCS structure, and dummy text) with DreamWeaver for each type of pages (i.e. each level)
web pages edition will have to be performed exclusively with editors that produce clean HTML code and do not destroy the CCS code. More specifically, the following editors are encouraged:

DreamWeaver: creation, edition, site-wide changes. WinPCs with DreamWeaver will be made available at SciOp buiding, 3.6m and Administration buiding.
EMACS: careful edition
Mozilla, version >= 1.0: careful edition

and the following tools are forbidden, as they mess the code in an unrecoverable way:

Netscape 4.*, Netscape 6.*
Internet Explorer editor.

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 (or other TBD) (imaging@kayu.ls.eso.org, etc), see below.

4.2- EMAIL ACCOUNTS

The only allowed email browser is Netscape, as implemented on kila.

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.

In the future, lasilla@eso.org 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 lasilla@eso.org. 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: lasilla@eso.org 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.

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.

COMMENT: EPo: ntt@eso.org 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

ls_imaging, ls_infrared, ls_spectro, ls_hires, ls_telescopes, ntt, 360, 220, lasilla @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, as implemented on kila.

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

5.1- Definitions

Previous version used lasilla@eso.org 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:

Requester: name of the requester
Requester email: email of the requester
Short Title
Telescope+Instrument: menu, select. If more than one instrument are needed, separate tickets must be submitted.
Priority status: select from ToO/DDT, PreImaging, ToO_compensation, Other (other not available from the web form)
Status: selection buttion: rejected/assigned/completed/obsolete
Request: text describing the observations to be performed, including the OBs to be executed in case of OPC-approved ToO.
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 SciOp Shift Leader: hidden field with the email of the astronomer shift leader, automatically updated daily from another form.
La Silla Director: hidden field with the email of the ToO main authoriser(s) (currently jmelnick + ohainaut for backup)

5.2- Work Flow

Submission:

The DDT Web form will be the only authorized entry point for DDT, ToO... etc requests. Incoming requests will constitute a Remedy Ticket, that arrives with status "requested". An email is immediately sent to the Requesters, that includes the ticket number, with instructions on how to submit the mandatory finding charts (similar to the Figures for ESOFORM proposals).

Requests of other types (ToO compensation etc....) can be entered directly by the relevant support astronomer using the Remedy tool, or using the Web form.

Approval:

ToOs:

If a ticket arrives with ToO status, VisAs, "La Silla Director" and "Current SciOp Shift Leader" are notified and have to approve/reject it according to the ToO policy [4].

Approved ToOs trigger notification to "Current SciOp Shift Leader" and to the relevant telescope for execution.

Others:

Tickets arriving with other status than ToOs trigger notification to the "Current SciOp Shift Leader" who deals with it with input from the relevant support astronomers.
Approved ticket trigger notification to the relevant telescopes for execution.

Execution:

ToOs: are executed as soon as possible, according to telescope availability, other priorities (following the ToO policy).
Others: when a technical/set-up/reserved night is scheduled, the support astronomer in charge checks the Remedy client for pending observations that can/should be executed.
The support astronomer in charge fills in the "log" in the corresponding ticket using the Remedy client, including the location of the data for retreival (e.g. acj.hq.eso.org for ToO observations, /data/raw/MOS_preImaging for MOS, etc). This triggers an email to the requester, containing the log information.

Completion:

In case all the observations are completed, the support astronomer or Shift Leader (for ToOs) changes the status of the ticket to "completed".
This triggers an email to the requester, and, in case of ToO, to the emails specified in the ToO policy.

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.

6- ALL PURPOSE ACCOUNT

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.

~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

COMMENT: MSt: a proposal repository? REPLY: YES! This could evolve into something more user-friendly, like a password protected web form. In the meantime:
/proposals : a repository of the proposal LaTeX files, replacing the current proposal binders ( rw------- protected directory)

/P69
/P70
...

/serviceObservations: info about the generic Service Observing Programs ( rw------- protected directory)

/ntt
/360
/220

/pendingObservations: Info on ToO compensation, Pre-Imaging, etc... ( rw------- protected directory)

/ntt
/360
/220

/ToO: finding charts, etc... ( rw------- protected directory)

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

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.)
REPLY: OK.

scisoft, latest approved version, with 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).

netscape with standard Netscape configuration:

home page points to www.ls.eso.org/lasilla/sciops
SMTP server set to kila
Identity set to "La Silla Visitor"
Default "Reply-to:" set to no-reply@this.email
signature set to-- + --La Silla Visitor --------------------------------------------------
+E S+ European Southern Observatory Phone: +56 2-464 4162 O DO NOT REPLY TO THIS EMAIL ADDRESS Fax: +56 2 463 3001 -- + -------------------------------------------http://www.eso.org/lasilla

Printer configuration that includes all printers of the mountain.
```
Standard software package, including
```

```
LaTeX 2e
```
```
EMACS, vi
```
```
GhostScript/GhostView, Xdvi
```

a README file based on the following template, to be also printed and handed to the visitor together with their user name and pw.

This account is accessible from all Linux PCs of the Off-Line PC Cluster, e.g. all PCs in the main User Room (administration buiding), Astronomy office, Science Operation building and telescope control rooms. You can also point any X-Terminal to one of the drl* machine (drl1 - drl9) by clicking [direct], enter the drl* host, [OK]. You should use this account to prepare your observations, including Phase II (P2PP is installed, just type p2pp at the prompt). You can use this account for web browsing (Netscape is configured), data processing (Midas, IRAF, IDL, Eclipse, SkyCat are installed configured -actually, the whole SciSoft collection). You can use this account to send emails using Netscape, but it is important to note that you cannot receive emails on that account. Email sent to lsusrXX@eso.org will not reach you. If you want to read email, you should point Netscape to your home mail server: - start Netscape - Edit > Preferences > Mail & Newsgroups > Mail Server - add an Incoming Mail Server, and configure it (give the address and user name). This of course supose that your home Mail Server can be queried from the outside world. When you send emails from your lsusr* account, you should indicate to your correspondants that they should not directly reply, but use your home address. Alternatively, you could set the "Reply-to:" to your usual email address: - start Netscape - Edit > Preferences > Mail & Newsgroups > Identity - fill the Reply-to field with your usual email address. The content of this account will be entirely wiped out after you leave La Silla, and no backup is performed. The drl* computers cannot be accessed from outside La Silla. It is therefore critical that you back-up or rapatriate all important information before you leave La Silla.

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