Re: PCFS - please, please, please. (From Simon Ellingsen)
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: <Chris.Phillips_at_email.protected>
Date: Thu, 15 Jun 2006 12:08:25 +1000 (EST)
>FromSimon (please us a consistent email address or ask me to register
it!)
-------------------------------------------------------------
Hi Chris,
>Effort is being made already. Mopra antenna control works but is not well
>tested. Parkes antenna control should be straight forward.
Good. I guess the point I would like to make is that we should be
_trying_ our hardest to use the PCFS for as much of this stuff as
possible and not proliferating adhoc pieces of software to control new
hardware.
A couple of years ago there were lots of reasons why we couldn't do the
scheduling and experiment setups for VLBI in a better fashion. However,
we found a solution, and combined with the disk-based fringe testing its
improved our reliability and reduced problems with correlating.
>>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).
>
>I agree we should go in this direction, but doubt it will improve
>reliability. The ATNF antennas have very few problems if any related to
>not using the pcfs.
Except that no one knows where all the information is logged,
specialised scripts have to be written for each telescope to extract
information such as system temperature, whether the antenna was
onsource etc etc. This means that in going from observation to
analysed dataset requires a long chain of ongoing support and at the
point where one person is too busy, or forgets about a user request, a
project sits there gathering dust. If that isn't a serious problem
that we should be doing our utmost to fix, I don't know what is. Are we
a national facility servicing a user community, or a specialised niche
facility for dedicated experts?
We're offering to help sort some of these issues out. In terms of
time for testing surely we can find a couple of days with largish
directors time allocations and request some of that. I was
anticipating Jamie working with one of the local staff members at the
observatory so it wouldn't necessarily coordinating anyone from
Epping.
>>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?
>
>Its just software right. This is unrealistic. Euan is aware of my request
>to be able to control caobs "remotely" rather than from a script. He has
>grand plans of having a caobs server and a front end - we could use the
>pcfs as our front end. Don't hold your breath as this is a lot of effort.
I was largely focusing on the easier issue of Parkes and Mopra, if the
ATCA can't be included so be it. To quote meatloaf - two out of three
aint bad. My only point here is that the caobs/ATCA antenna control
issue looks to me like a basic design flaw that we've just missed the
opportunity to fix.
>This is *not* enough though. There is also Tsys and frequency setup.
>Currently frequency setup (when bug free!) just works - it would be a real
>step backwards to have to set LOs by hand which. The problem here is that
>the pcfs is not designed for VLBI is it designed for geodesy. They have a
>totally different concept of how LO chains are setup and so far I cannot
>figure out a way to get the correct sky frequency from
>vex->drudg->snap->telescope. (drudg deals with LO frequencies not sky
>frequencies). I have no idea if it is easy or hard to control frequency via
>the pcfs for Parkes.
>
>To go to the new pcfs we also need to either port Simon DAS controller to
>a 2.4/2.6 kernel or use Jonathon Quick's DAS control code. Jon's stuff
>works well but there is still an outstanding problem (possible with my
>understanding) with inverted bandpasses (Jon: I have not forgotten about
>this and will contact you when I have some more time to look at this).
At Hobart/Ceduna we don't control either the frequency setup, nor the
DAS through the PCFS. It would be nice to, but in general these are
set once and forget. If the EVN can do it, why can't we.
>I have spoken to Ed Himwich about Tsys logging and he felt it was not so
>trivially to cope with continuous Tsys such as all ATNF antenna use. Again
>this is because pcfs is not designed with astronomy in mind.
I don't know why this should be the case, a simple client-server model
would do it easily. Adding a command to the field system so that when
you type "tsys" it contacts it obtains and value and logs it is
(compared to a lot of the other stuff we do) kids-play.
Date: Thu, 15 Jun 2006 12:08:25 +1000 (EST)
>FromSimon (please us a consistent email address or ask me to register
it!)
-------------------------------------------------------------
Hi Chris,
>Effort is being made already. Mopra antenna control works but is not well
>tested. Parkes antenna control should be straight forward.
Good. I guess the point I would like to make is that we should be
_trying_ our hardest to use the PCFS for as much of this stuff as
possible and not proliferating adhoc pieces of software to control new
hardware.
A couple of years ago there were lots of reasons why we couldn't do the
scheduling and experiment setups for VLBI in a better fashion. However,
we found a solution, and combined with the disk-based fringe testing its
improved our reliability and reduced problems with correlating.
>>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).
>
>I agree we should go in this direction, but doubt it will improve
>reliability. The ATNF antennas have very few problems if any related to
>not using the pcfs.
Except that no one knows where all the information is logged,
specialised scripts have to be written for each telescope to extract
information such as system temperature, whether the antenna was
onsource etc etc. This means that in going from observation to
analysed dataset requires a long chain of ongoing support and at the
point where one person is too busy, or forgets about a user request, a
project sits there gathering dust. If that isn't a serious problem
that we should be doing our utmost to fix, I don't know what is. Are we
a national facility servicing a user community, or a specialised niche
facility for dedicated experts?
We're offering to help sort some of these issues out. In terms of
time for testing surely we can find a couple of days with largish
directors time allocations and request some of that. I was
anticipating Jamie working with one of the local staff members at the
observatory so it wouldn't necessarily coordinating anyone from
Epping.
>>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?
>
>Its just software right. This is unrealistic. Euan is aware of my request
>to be able to control caobs "remotely" rather than from a script. He has
>grand plans of having a caobs server and a front end - we could use the
>pcfs as our front end. Don't hold your breath as this is a lot of effort.
I was largely focusing on the easier issue of Parkes and Mopra, if the
ATCA can't be included so be it. To quote meatloaf - two out of three
aint bad. My only point here is that the caobs/ATCA antenna control
issue looks to me like a basic design flaw that we've just missed the
opportunity to fix.
>This is *not* enough though. There is also Tsys and frequency setup.
>Currently frequency setup (when bug free!) just works - it would be a real
>step backwards to have to set LOs by hand which. The problem here is that
>the pcfs is not designed for VLBI is it designed for geodesy. They have a
>totally different concept of how LO chains are setup and so far I cannot
>figure out a way to get the correct sky frequency from
>vex->drudg->snap->telescope. (drudg deals with LO frequencies not sky
>frequencies). I have no idea if it is easy or hard to control frequency via
>the pcfs for Parkes.
>
>To go to the new pcfs we also need to either port Simon DAS controller to
>a 2.4/2.6 kernel or use Jonathon Quick's DAS control code. Jon's stuff
>works well but there is still an outstanding problem (possible with my
>understanding) with inverted bandpasses (Jon: I have not forgotten about
>this and will contact you when I have some more time to look at this).
At Hobart/Ceduna we don't control either the frequency setup, nor the
DAS through the PCFS. It would be nice to, but in general these are
set once and forget. If the EVN can do it, why can't we.
>I have spoken to Ed Himwich about Tsys logging and he felt it was not so
>trivially to cope with continuous Tsys such as all ATNF antenna use. Again
>this is because pcfs is not designed with astronomy in mind.
I don't know why this should be the case, a simple client-server model
would do it easily. Adding a command to the field system so that when
you type "tsys" it contacts it obtains and value and logs it is
(compared to a lot of the other stuff we do) kids-play.
-- 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 12:08:25