EUROPEAN SOUTHERN OBSERVATORY

La Silla Observatory

SCIENCE OPERATION DEPARTMENT

SciOp Internal Use Only

Revision History

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

1.2- REFERENCED DOCUMENTS

1.3- ACRONYMS

1.4- SUMMARY

• 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

2- PAPER DOCUMENTATION

2.1- INTRODUCTION

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

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

2.2- DOCUMENTATION EDITION

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

Procedure to search and retrieve a document

3- WWW

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

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

• 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

• 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

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

6- ALL PURPOSE ACCOUNT

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

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.