La Silla Observatory
SCIENCE OPERATION DEPARTMENT
|Re-Engineering Project: |
|| Jorge Ibsen
Internal Use Only
||2002-05-19 first draft, ohainaut and jibsen
|2002-06-09 include review comment
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 LSO-PLA-ESO-90000-6: SciOp Staffing Plan, O.Hainaut.
 http://www.eso.org/webproject/policy/web-policy.html: The ESO Web Policy, Neumann et al
 http://www.eso.org/webproject/policy/eso-guide.html: The ESO Web Standards, Neumann et al
 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
- cmm documentation repository
- xxx (possibly kayu or wMos, TBD)
- web server
- contains the sciops web pages
- cmm client for documentation
- 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
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.
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
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:
- 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
- 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.
- 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
dvips report_emmi.dvi -o document.ps
It must be noted that in this scheme, version numbers are handled directly by CMM.
- the final printable document, which must be named document.* (document.ps, document.pdf, document.html...)
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 
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.
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
- 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).
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.
The structure, content and look-and-feel of the SciOp
pages will be defined (in accordance to the ESO web policy  and standards
) and applied to all the sciop tree (note that, currently, the SciOp pages
only marginally adhere to these standards). As consequences:
- 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.
- 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 .
- 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
- 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.1- EMAIL LISTS & ALIASES
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
- Instrument forces:
- firstname.lastname@example.org and
- Generic lists:
- email@example.com: all SciOp staff, this is an alias joining the 3 following lists:
- firstname.lastname@example.org: all the astronomers
- email@example.com: all the TIOs
- firstname.lastname@example.org: all the op.Eng.
- all the members of the Force or group, for info or action,
- an email repository on kayu (or other TBD) (email@example.com, etc), see below.
4.2- EMAIL ACCOUNTSThe only allowed email browser is Netscape, as implemented on kila.
- firstname.lastname@example.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 email@example.com, and
- delete the original message as soon as the CC of the forward has arrived back.
This must trigger a reply with CC to firstname.lastname@example.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
In the future, email@example.com could possibly evolve into a more automatic helpdesk (remedy?).
- i) just arrived emails
- ii) CC'ed emails from lasilla to the Department, awaiting a reply.
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 firstname.lastname@example.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: email@example.com 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.
- firstname.lastname@example.org, email@example.com firstname.lastname@example.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: email@example.com 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 firstname.lastname@example.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:
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
Previous version used email@example.com 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
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
COMMENT: JMe: Paranal must be consulted for uniform implementation.
- 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
- 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.
- 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 .
- Approved ToOs trigger notification to "Current SciOp Shift Leader" and to the relevant telescope for execution.
- 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.
- 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.
- 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.
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.
- /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.
- /generic: home of the Instrument Force.
- link to ~/ntt/sofi
- link to ~/360/timmi
- link to ~/ntt/emmi
- link to ~/360/efosc
- link to ~/ntt/emmi
- link to ~/360/harps
- link to ~/360/ces
- link to ~/220/feros
- link to ~/ntt/susi
- link to ~/ntt/emmi
- link to ~/360/efosc
- link to ~/220/wfi
MSt: a proposal repository? REPLY: YES! This could evolve into something
more user-friendly, like a password protected web form. In the meantime:
: a repository of the proposal LaTeX files, replacing the current proposal
binders ( rw------- protected directory)
- /serviceObservations: info about the generic Service Observing Programs ( rw------- protected directory)
- /pendingObservations: Info on ToO compensation, Pre-Imaging, etc... ( rw------- protected directory)
- /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.)
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).