This loads a font easier to read for people with dyslexia.
This renders the document in high contrast mode.
This renders the document as white on black
This can help those with trouble processing rapid screen movements.

Re: vt001h - apologies

From: <sellings_at_email.protected>
Date: Thu, 18 Nov 2004 09:48:09 +1100 (EST)

Hi Jim,

>>It seems to me that as we move towards a mode of operating using both the
>>S2 and disk-based systems we are increasing the potential complexity
>>significantly. In my opinion we need to think carefully and define a
>>limited number of well defined standard modes of operation that cover the
>>majority of experiments, otherwise we risk increased failure rates. This
>>perhaps could be something for discussion at the next operations meeting?
>
>I agree too!
>
>Although this session has been far from typical operationally, it has
>highlighted this problem of last minute changes causing confusion. This
>is how things are supposed to happen:
>
>1. The block schedule is prepared a month before the start of the
>session and PIs are emailed to let them know when they're scheduled.
>
>2. PI's are asked to have their schedules submitted at least a week
>before the start of the session.
>
>3. People at the various antennas check that the schedule will work at
>their site and provide feedback to the PI who revises the schedule if
>necessary.
>
>I think there are a couple of problems with this. The first is that some
>PIs don't get their schedules done in time. (What do we do if the
>schedule is late? Cancel the observation?) The second is that we don't
>always check the schedules as carefully as we should and therefore don't
>spot problems until the last minute.
>
>Some ideas on how to improve things:
>
>1. Move the deadline for schedules back to two weeks prior to the
>session and set a deadline of one week prior to the session for all
>observatories to check they're OK (again there's the question of how we
>enforce these deadlines). Then details on DAS and S2 configurations,
>frequencies, polarisations, all go on the web. I agree that having such
>a page is a good idea but it's not much help if it keeps changing right
>up to the start of the observation.

One advantage of this is the ability to wave a bit of a stick at the
PI. Two weeks is long enough that the time allocated to them could be
rescheduled to a different project. This isn't something that I think any
of us wants to do, but it could be used to motivate people to get there
schedules in on time.

>2. As Chris said, standard SCHED setup files will help avoid lots of
>these setup problems but PIs need to be encouraged to use them.
>
>3. The capability of every antenna needs to be listed in a single
>location on the web so that PIs can plan their observations. The page
>should list all the "standard modes" (as Simon suggested) and show which
>antennas can support them. We shouldn't support other observing modes
>unless they've been verified first.

This is the best idea, it should be relatively straight forward to give
two configurations for our standard frequencies 21cm, 18cm, 13cm, 6cm,
5cm, 3cm, 1.2cm, one being a 16 MHz dual polarization and one a 2x16 MHz
single polarization setup (which could also be used in dual polarization
form for 256 Mbps experiments). The presence of Tid, Hart or any other
regular participant in the array wouldn't make any difference if we chose
the standard frequencies to be ones that Tid can observe at too.

I'll volunteer myself to try and coordinate/arrange this across the array
(after the current session), using as a starting point the SCHED setups
that Chris has written. Does anyone have any objections?

Regards

Simon
--
Simon Ellingsen : Lecturer in Physics/Radio Astronomy, University of Tasmania
email : Simon.Ellingsen_at_utas.edu.au
WWW   : http://www-ra.phys.utas.edu.au/~sellings
Phone : 6226 7588 or 6226 7528 (Work)  ; Area Code : +61 3 (International)
         6278 8636 (Home), 6226 2410 (Fax)                   03 (Australia)
Received on 2004-11-18 09:48:26