La Silla/Paranal Unification Project


General Considerations

Prepared: ohainaut

Version:   2003-09-29 ohainaut

Introduction & Purpose

Several scenarii can be considered for the unification of SciOpses:
a- and c- are listed for completeness; b- is described in details in [1]

In my view, our duty is to improve the operation of both observatories by a full re-engineering, i.e. -e-, including changes -hopefully improvements- to both LSO and PAO operation schemes. Moreover, this is a unique opportunity to get what we have always dreamed for, since, if we decide that we need something for the merge to work, it is likely that we will get it.

What follows is not a full implementation of an operation plan, but some ideas that should be explored/discussed/expanded/destroyed in the process of re-engineering.

Relevant Documents:

[1] La Silla - Paranal unification - gmathys

1- Industrial data/ crafted data

The PAO has been compared to an "industrial backery", producing a high quality AND highly standardized product (data, not croissants). On the other hand, LSO has been compared to an old fashioned, artesanal backery, producing also high quality product, but that could be tuned to the exact requirements of a client when these are not standard. I suggest to formalize and expand this:
In "industrial production" mode, a telescope can be run almost in automatic mode, one TIO driving the whole system, with (a fraction of) an astronomer available for assessing complex cases (complex change of service queue, difficult acquisition, strange case of data quality control). This frees a considerable amount of highly qualified manpower for tasks requiring their qualification.

These two modes should be detailed and explained to the community, in particular that "crafted data" are definitely not optimal for a standard mass-production program, and that "industrial data" is not (necessarily) the same as service mode.

2- Service/Visitor modes:

Various scenarii can be considered:
Service-related problem: loss of contact between the Community and the Observatory:

In scenarii with a high fraction of Service Mode, the number of visiting astronomers will strongly decrease. In a first stage this would result in a increasing Phase-II preparation problems (PI with unrealistic ideas/expectations), then in a strong problem for staff replacement, since our potential staff pool is the Community.
As Service Observing is likely to stay, we have to take corrective actions. Possible ideas are listed below.

3- Optimization

Any task that is currently repeated several times (per day, week, period...) must be automatized or delegated to technical staff (basically technicians, as opposed to highly qualified/expensive staff as TIOs, Astronomers, DHI).

All staff should be utilized to perform tasks that require their respective education/expertize. In particular:


A significant benefit of this day work is that the TIOs get a much deeper knowledge and understanding of the systems, which allows them to operate in a very efficient way.This makes the front line night time troubleshooting very efficient.  It has also some side advantages on the personal side: the integration of the TIOs in the observatory is much deeper than when they were night-only, and breaks the monotony of night-only work.We should discuss the benefit of both models (night only vs day/night).


  Data Handling Administrator

Operation Engineers

Operation Engineers, or operation managers, exist at La Silla. Their key role involves
While some of their tasks could be passed to engineering/software, their role is very deeply linked to the Operation side of SciOp. We should investigate their status in the unified scheme (i.e. do we want OpEng? if not, who does their work? would PAO-SciOp (have) benefit(ted) to have some "in house" engineering expertise for day-to-day operation management?