[daip] New Ticket - [!HIU-291162]: AIPS task UVRFI

[Eric Hooper]

New Ticket: AIPS task UVRFI

Dear NRAO Support, 

We have several questions regarding the relatively new AIPS task
UVRFI.  We have read AIPS memo 116, the UVRFI explain file, and Athrea
(2009, ApJ 696, 885).  First, many thanks to Leonid Kogan & Fraser
Owen for writing and documenting this task!  It seems like a godsend
for the RFI plagued observer.

Our current situation: we are reducing L-band continuum data with 5
second integration times from the old VLA.  One of the IFs is heavily
corrupted with RFI, the other is mostly clean.  For our initial
experiments we have chosen a solution interval (FULLTIME, or UVRFI
parameter YINC) over which to correct the RFI of 150 seconds.

Practicalities and Questions about the Algorithm
------------------------------------------------

1) What happens to the "leftover" data points when the total observing
time on a source is not exactly an integer times YINC?  Two specific
examples: the time on source is 180 seconds, with YINC = 150 seconds
-- what happens to the data in the remaining 30 seconds; the time on
source is 120 seconds, so less than a single YINC?

2)  Is there a practical upper limit to YINC (FULLTIME)?  

3) Have you discovered the practical lower limit to the number of data
points within YINC?  For example, AIPS Memo 116, section 5 discusses
an application with 100 time points for L-band data, and the next
section describes an application with 36 time points at 74 MHz.
Currently we are using 30 time points.


Data Sort Order
---------------

1) The data must be in BT order, which precludes indexing (UVSRT does
not copy the NX table, nor will INDXR work on any data set that is not
in time-* order).  Yet, the execution of UVRFI generates numerous
complaints about the lack of an NX file.  Are these complaints benign?

2) Statements attached to INNAME ("Sort must be 'BT'!!!") and DOCALIB
("If the data are not in time order, then DOCALIB must be false.")  in
the explain file are incompatible.  One cannot use time ordered data
for UVRFI, and one cannot calibrate data that are not time ordered.
Are we missing something here, or is DOCALIB simply a redundant
parameter in UVRFI?

3) What is the recommended way of calibrating the data either before
or after the application of UVRFI?


Questions about UVRFI Parameters
--------------------------------

The questions about the APARM parameters refer to the use of the FT
method (OPCODE = 'CEXP').

1) APARM(4) The explain file says this "is the number of subtracted
complex exponents."  We do not understand this wording.  Do you mean
"complex components"?  So, is APARM(4) essentially the equivalent of
NITER in imaging CLEAN applications?  Do you have advice on how to
pick a reasonable value for this parameter?

2) APARM(5) Presumably this means that no dirty beam can be fit which
is *centered* on a pixel (in the FT space) that is within NPIX of zero
frequency?  Moreover, this does *not* exclude the subtraction of parts
of a dirty beam, centered on higher frequency pixels outside of the
NPIX range, which extend into the NPIX range of lower frequency
pixels?  (As to the latter question, the ability to subtract parts of
a dirty beam centered outside of NPIX from the zero frequency signal
would seem to be the whole point of the CLEAN operation in the first
place.)

3) APARM(8) Is there any advice on how deeply we should clean in terms
of the expected rms noise on a single baseline?

4) APARM(9) This seems to be limiting the range of frequencies over
which a scaled dirty beam is subtracted.  Is this analagous to
limiting the area in a dirty 2-D map over which a scaled dirty beam
can be subtracted; i.e., *not* the same as a CLEAN box which just
limits the pixels to which a dirty beam can be fit, rather than the
extent of the subtraction of said dirty beam?  When should this be
something other than the entire range of Fourier transform
frequencies?  What is the default (e.g., by entering zero for this
paramter) behavior?

5) APARM(10) We are baffled by this parameter and do not understand
its description in the explain file.

6) ZINC.  If the data have not been pre-averaged, should this be set
to the integration time used for the acquisition of the data?


Thank you for your time.  

Best regards, 

Eric Hooper and Matt Huang
University of Wisconsin-Madison


Ticket Details
===================
Ticket ID: HIU-291162
Department: AIPS Data Processing
Priority: Default
Status: Open
Link:  https://help.nrao.edu/staff/index.php?_m=tickets&_a=viewticket&ticketid=2393