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

[Leonia Kogan]

Eric,

You'll find my answers in the text.
I hope it will help although I am not sure because I am sick
a little bit

Leonia

Eric Hooper wrote:
> 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;

As I remember the 30 sec are not used

  the time on
> source is 120 seconds, so less than a single YINC?

120sec are used;

> 
> 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.

The chosen YINC determines the fringe rate resolution, and may depend on 
the period of the circle, position of expected complex exponent on the 
fringe rate axis.
> 
> 
> Data Sort Order

I can not answer on these section questions :)
> ---------------
> 
> 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?

I'd say still complex exponents....
YES, APARM(4) is equivalent to NITER...
> 
> 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.)

APARM(5) controls subtraction of components near zero fringe rate,
because the signal is near zero fringe rate.

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

It is your choice. I used APARM(8)=0 in many cases

> 
> 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?

This is the width of dirty beam used in subtraction. It is up to you.
I used APARM(9)=10

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

> 
> 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?
YES

> 
> 
> 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
> 
> _______________________________________________
> Daip mailing list
> Daip at listmgr.cv.nrao.edu
> http://listmgr.cv.nrao.edu/mailman/listinfo/daip