PCFS - please, please, please. (From Simon Ellingsen)
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: <Tasso.Tzioumis_at_email.protected>
Date: Thu, 15 Jun 2006 10:45:14 +1000
>
>Hi All,
>
>Yesterday we spent a lot of time discussing the issue of logs
>and calibration data and the decision that was arrived at was to try
>and fix the messy system currently in place. I'd like to make an
>impassioned plea to instead use these resources to properly
>implement PCFS
>control at Parkes, Mopra (and the ATCA if possible).
>
>The executive summary (for those without the time to read a long
>email) - it will make our operations more reliable and for a small
>effort it will dramatically improve our user support (and bring us
>into the 1990s).
>
>Here is the long-winded _lots_ of reasons why I think we should do
>this :
>
>- The PCFS was designed to run VLBI experiments; control the
>antenna,
>recorder and ancillary hardware and log system information
>such as Tsys,
>weather etc.
>
>Whenever I go to ATCA, Mopra, Parkes for other types of
>observing, one
>piece of software controls the telescope and observing hardware
>(correlator or whatever). No other user group would accept such
>a cobbled together, anachronistic and archaic observing
>system - why
>should we?
>
>- The PCFS is the _world_ standard for VLBI observing - the EVN
>uses
>it at all its telescopes, the geodetic community, even NASA!
>
>- If we can make the PCFS control the antennas, recorder, log the
>Tsys and weather then we have the unthinkable - one log from
>each telescope all in the same standard format.
>
>At the moment we have a situation where an ATNF student
>supervised
>by one of the members of this group, has been waiting months to
>get the basic information they need to calibrate their data. No
>wonder we only get proposals from black-belt VLBI experts,
>who else
>has any chance of being able to reduce their data without
>Herculean
>effort?
>
>- As part of the ARC e-research grant, Jamie is currently
>working on
>software to enable the PCFS to operate the disk-based recorders.
>This system is compatible with disko. I think that we should
>aim
>to view disko as being equivalent to the S2 front panels -
>something that you can use to control the recorder if necessary,
>but generally best left untouched during an experiment (so that
>the recorder commands are logged by the PCFS). I'm pretty
>sure it
>should also be possible (although perhaps a little messy) to
>have
>commands/comments entered into disko logged by the PCFS (if
>thats
>what people _really_ want).
>
>So how do we achieve this? Perhaps I'm being naive and lack vital
>knowledge about the detailed operation at some telescopes, but I think
>there are fairly simple solutions that would only take a couple of
>days
>for people with the right expertise.
>
>To control the antenna using the PCFS all you need is a program
>running
>on some machine at the observatory that can do three things
>- communicate with the PCFS via a standard TCP/IP socket
>- slew the antenna to a location in RA/Dec (you may also want to be
>able to control the antenna drives)
>- determine whether the antenna is at that location or not
>Once you have that in place it is a matter of a few minutes work to
>modify the antcn.c stub program in the PCFS. If this can't be done at
>the ATCA, why not, the control systems have just been rewritten and
>this
>is a piece of basic functionality?
>
>At the ATNF sites the system temperatures are automatically logged
>into files somewhere on some machine. To get that information into
>the PCFS you need another simple program that when requested reads the
>most recent value from that file (you might have a simple client
>program on the machine where the Tsys information is logged say) and
>writes it to the log. The weather information can be done the same
>way
>(as it is at Hobart).
>
>The antenna control in particular I see as being very useful in the
>near future. At slow slewing antennas like Parkes, during a phase
>reference experiment you might spend as much as 50% of the time
>slewing between sources. We are currently disk limited and so if we
>can reliably know when we are onsource we can significantly increase
>the duration, or number of experiments we do by not recording when
>offsource. This will also save network bandwidth when we move to real
>eVLBI.
>
>Finding the people with the time and expertise to do these types of
>jobs is always difficult, but given the importance of this UTas will
>help with this as part of the e-research project. Phil, John, if you
>can identify the appropriate people at Parkes & Mopra and arrange for
>them to have a couple of days to work on this, we can send Jamie up to
>work with them on the PCFS and implementation side. How does that
>sound to everyone?
>
>--
>Regards
>
>Simon
>--
>Simon Ellingsen : Senior Lecturer Physics & Astronomy, University
>of Tasmania
>email : Simon.Ellingsen_at_utas.<!--nospam-->edu.au
>WWW : http://www-ra.phys.utas.edu.au/~sellings
>Phone : 6226 7588 ; Area Code : +61 3
>(International)
>6278 8636 (Home), 6226 2410 (Fax) 03
>(Australia)
Received on 2006-06-15 10:45:47
Date: Thu, 15 Jun 2006 10:45:14 +1000
>
>Hi All,
>
>Yesterday we spent a lot of time discussing the issue of logs
>and calibration data and the decision that was arrived at was to try
>and fix the messy system currently in place. I'd like to make an
>impassioned plea to instead use these resources to properly
>implement PCFS
>control at Parkes, Mopra (and the ATCA if possible).
>
>The executive summary (for those without the time to read a long
>email) - it will make our operations more reliable and for a small
>effort it will dramatically improve our user support (and bring us
>into the 1990s).
>
>Here is the long-winded _lots_ of reasons why I think we should do
>this :
>
>- The PCFS was designed to run VLBI experiments; control the
>antenna,
>recorder and ancillary hardware and log system information
>such as Tsys,
>weather etc.
>
>Whenever I go to ATCA, Mopra, Parkes for other types of
>observing, one
>piece of software controls the telescope and observing hardware
>(correlator or whatever). No other user group would accept such
>a cobbled together, anachronistic and archaic observing
>system - why
>should we?
>
>- The PCFS is the _world_ standard for VLBI observing - the EVN
>uses
>it at all its telescopes, the geodetic community, even NASA!
>
>- If we can make the PCFS control the antennas, recorder, log the
>Tsys and weather then we have the unthinkable - one log from
>each telescope all in the same standard format.
>
>At the moment we have a situation where an ATNF student
>supervised
>by one of the members of this group, has been waiting months to
>get the basic information they need to calibrate their data. No
>wonder we only get proposals from black-belt VLBI experts,
>who else
>has any chance of being able to reduce their data without
>Herculean
>effort?
>
>- As part of the ARC e-research grant, Jamie is currently
>working on
>software to enable the PCFS to operate the disk-based recorders.
>This system is compatible with disko. I think that we should
>aim
>to view disko as being equivalent to the S2 front panels -
>something that you can use to control the recorder if necessary,
>but generally best left untouched during an experiment (so that
>the recorder commands are logged by the PCFS). I'm pretty
>sure it
>should also be possible (although perhaps a little messy) to
>have
>commands/comments entered into disko logged by the PCFS (if
>thats
>what people _really_ want).
>
>So how do we achieve this? Perhaps I'm being naive and lack vital
>knowledge about the detailed operation at some telescopes, but I think
>there are fairly simple solutions that would only take a couple of
>days
>for people with the right expertise.
>
>To control the antenna using the PCFS all you need is a program
>running
>on some machine at the observatory that can do three things
>- communicate with the PCFS via a standard TCP/IP socket
>- slew the antenna to a location in RA/Dec (you may also want to be
>able to control the antenna drives)
>- determine whether the antenna is at that location or not
>Once you have that in place it is a matter of a few minutes work to
>modify the antcn.c stub program in the PCFS. If this can't be done at
>the ATCA, why not, the control systems have just been rewritten and
>this
>is a piece of basic functionality?
>
>At the ATNF sites the system temperatures are automatically logged
>into files somewhere on some machine. To get that information into
>the PCFS you need another simple program that when requested reads the
>most recent value from that file (you might have a simple client
>program on the machine where the Tsys information is logged say) and
>writes it to the log. The weather information can be done the same
>way
>(as it is at Hobart).
>
>The antenna control in particular I see as being very useful in the
>near future. At slow slewing antennas like Parkes, during a phase
>reference experiment you might spend as much as 50% of the time
>slewing between sources. We are currently disk limited and so if we
>can reliably know when we are onsource we can significantly increase
>the duration, or number of experiments we do by not recording when
>offsource. This will also save network bandwidth when we move to real
>eVLBI.
>
>Finding the people with the time and expertise to do these types of
>jobs is always difficult, but given the importance of this UTas will
>help with this as part of the e-research project. Phil, John, if you
>can identify the appropriate people at Parkes & Mopra and arrange for
>them to have a couple of days to work on this, we can send Jamie up to
>work with them on the PCFS and implementation side. How does that
>sound to everyone?
>
>--
>Regards
>
>Simon
>--
>Simon Ellingsen : Senior Lecturer Physics & Astronomy, University
>of Tasmania
>email : Simon.Ellingsen_at_utas.<!--nospam-->edu.au
>WWW : http://www-ra.phys.utas.edu.au/~sellings
>Phone : 6226 7588 ; Area Code : +61 3
>(International)
>6278 8636 (Home), 6226 2410 (Fax) 03
>(Australia)
Received on 2006-06-15 10:45:47