Документ взят из кэша поисковой машины. Адрес оригинального документа : http://www.naic.edu/~tghosh/software/reply_10oct04 Дата изменения: Mon Oct 11 00:34:23 2004 Дата индексирования: Sun Apr 10 13:07:55 2016 Кодировка: Поисковые слова: stars

Hi Steve,

Sorry to send something in response to your software document
so late in the day. However, I don't think that I am going to say
anything "show-stopping", and what I will add is really in the way of
a few random comments.

I'll quote the bits of your document below that I have comments
on, and then add the comments.

% Software requirements at the Observatory can be divided into five main
% categories.
%
% 1) telescope control
% 2) datataking
% 3) user interface to datataking and telescope control
% 4) data monitoring
% 5) data processing

A software requirement which doesn't quite fall under either
1) or 2) is that of setting up the rf/if/lo path, including calibration
options. I am not sure if this is handled by PNT or COR, as a routine
such as "setupall" set up the turret, the receiver, if/lo path, and the
pointing model, and can also stow the carriage house. Maybe it uses both?

% 2) Datataking
%
% Datataking for spectral-line observations is done either by the
% Interim Correlator (COR), or the WAPP. This memo addresses software
% effort for the WAPP and future spectral line machines.

Is it worth a mention of the GALFA spectrometer, (and perhaps
the EALFA machine due a while down the road)?

% The WAPP is a cluster of four dual-processor Pentium based systems
% running the GNU/Linux operating system. The WAPP writes spectral line
% data in FITS format. This is a standard file format which is
% recognized by a large number of applications developed worldwide. A
% utility developed by NASA called fitsview can read and display data in
% any FITS file, including those written by the WAPP.

I believe a number of Arecibo users (Snezana and probably Erik
Muller?) prefer Richard Gooch's "Karma" package to fitsview. Apart
from (I gather) very nice graphical display options, Karma seems to
have a lot of associated processing tools available. I have not used it,
only seen it (impressively) used by Snezana. It might be interesting to
look at the relative capabilities of fitsview and Karma?

% 4) Data Monitoring
%
% Observers can run an online data display on the Dataview computer.
% The ALFA data display shows raw bandpass plots, waterfall plots, and
% updated text of the FITS header. Data from the WAPP is multicast on
% the WAPP subnet using Jeff Hagen's socket communication library. This
% method allows data display without increasing disk i/o, and without
% relying on sometimes sporadic Network File Share (NFS). Future
% developments for the online data display include data accumulation for
% display of integrated data and on/off subtraction. The ALFA data
% display will be adapted for use with single-pixel observations.
%

Many years ago, the on-line monitoring program we had at Pico
Veleta displayed the accumulating spectral sum of data acquired in a
scan as the data came in, (as well as the most recent record.) This was
a very useful option. In passing, it also displayed the (On-Off)/Off
after the cycle was completed.

% Data display for the Interim Correlator is possible by running the IDL
% routine CORMON ALL. This routine works by polling the saved data
% file, and plotting results after data has been written to disk.
%
% Phil Perillat is responsible for CORMON.

Phil also has another less-well-known, but very useful,
monitoring program for spectral-line (interim correlator) monitoring.
This is "corstripch", and it gives a "strip chart recorder" display of
the total power versus time. It is especially useful for showing RFI,
gain or Tsys jumps, and other irregularities.

% 5) Data Processing
%
% 5.1) Current Data Processing Software
%
% There is a large library of routines for data processing at Arecibo
% written in the Interactive Data Language (IDL). Many of these were
% written by Phil Perillat in support of the Interim Correlator. There
% are also large contributions from past and present staff members,
% notably Tapasi Ghosh, Chris Salter, Snezana Stanimirovic, Karen
% O'Neil, Gomathi Thai. Visiting observers have also contributed, Carl
% Heiles being the main contributor.

Out of interest, Carl H. was the initiator of IDL usage at
Arecibo during a short sabbatical stay here in 2000.

% The Arecibo IDL library can be used to process spectral line data from
% the WAPP using routines which read the FITS files and translate the
% data to the COR structure. Phil Perillat has developed the
% translation routines.
%
% A common complaint regarding the Arecibo IDL routines is its
% complicated user interface. To address this issue, Erik Muller
% developed a text-based, menu driven user interface to some of the COR
% routines. This user interface is called ICRed (Interim Correlator
% Reduction) and is a prototype which demonstrates an easy-to-use user
% interface.
%
% An independent development, also in IDL, is WapRed (WAPP Reduction)
% which is written by Erik Muller. WapRed uses the same menu philosophy
% as ICRed, but it reads the FITS files and processes the data directly
% without going through a translation stage. It can do basic data
% manipulations including on/off and co-adding. It can also split FITS
% files according to keywords which has been used to create FITS files
% which are compatible with other packages, such as IRAF.

I really like Erik's concept of a simple text-based interface
for the IDL library. Could not WAPred have an option to use Phil's (sigh)
WAS routines to allow usage of Phil's library (via WAPred) to WAPP
users? Erik's interface reminds me very much of that used by (old)
AIPS. That interface was declared "out of date" 20 years ago, but has
proved to be very popular with a huge user community right up to
the present day.

% 5.2) Future Directions
%
% Data reduction software at Arecibo must be developed within the
% context of the worldwide effort on spectral line data reduction
% software. There are many packages for reduction of Astronomical
% spectral line data. A short list of some of these is: CLASS, AIPS,
% IRAF, SPECX, XS, DRP. In addition, the astronomical community has
% made available a large number of routines written for generalized data
% processing packages such as IDL, MatLab, and PerlDL to name a few.

I think it would be worth including SPA, the reduction system at
FCRAO, in the above list. It has a lot of enthusiasts, including Mark
Heyer (who probably wrote it in part, and who is either on our AUSAC or
AVC this year, I believe.) Perhaps AIPS++ should also go in? :-)

% 5.3) Recommendations
%
% I propose that the pipeline software as described above should be
% developed, and that Mikael Lerner should be responsible for leading
% the effort. This follows naturally from the work he is doing on the
% data display.
%
% I recommend that the IDL library should continue to be developed by
% those people using IDL, but that it is not necessary to develop a user
% friendly interface. Arecibo users who run IDL are already familiar
% with IDL and the Arecibo routines. A friendly user interface will not
% have such a great impact on those people to warrant the enormous
% effort required to make the interface. New users will have the option
% to use their favorite package once the pipeline is in place, or they
% can simply take the data "as-is" and produce output using fitsview.
%
% Ideally, the continued IDL development would have a coordinator. That
% person would work towards having a uniform interface, either by
% writing wrappers for contributed routines, or by requiring developers
% to pass data and arguments in a standard way. The coordinator would
% be responsible for quality assurance by ensuring that the routines
% produce the correct results.

Above in paragraphs 2 and 3, it says;

% I recommend that the IDL library should continue to be developed by
% those people using IDL, but that it is not necessary to develop a user
% friendly interface. Arecibo users who run IDL are already familiar
% with IDL and the Arecibo routines. A friendly user interface will
% not have such a great impact on those people to warrant the enormous
% effort required to make the interface.

and

% Ideally, the continued IDL development would have a coordinator.
% That person would work towards having a uniform interface

Is there any inconsistency here?

Indeed, I would see Erik's WAPred as a potentially
user-friendly interface that can handle IDL? It also would not need any
"enormous effort" for its development?

Well, Steve, just random thoughts. I am really happy to see
your document, as a wonderful discussion document focusing on the
really important points.

See you tomorrow,

Chris