[daip] [!4505]: aips - FRING and combined-IF solutions: rates in mHz or sec/sec

[Michael Bietenholz]

Michael Bietenholz updated #4505
--------------------------------

FRING and combined-IF solutions: rates in mHz or sec/sec
--------------------------------------------------------

           Ticket ID: 4505
                 URL: https://help.nrao.edu/staff/index.php?/Tickets/Ticket/View/4505
           Full Name: Michael Bietenholz
               Email: mbieten at yorku.ca
             Creator: User
          Department: AIPS Data Processing
       Staff (Owner): -- Unassigned --
                Type: Issue
              Status: Open
            Priority: Default
                 SLA: NRAO E2E
      Template Group: Default
             Created: 14 February 2014 12:10 AM
             Updated: 14 February 2014 12:10 AM
                 Due: 18 February 2014 12:10 AM (4d 0h 0m)
      Resolution Due: 25 February 2014 12:10 AM (11d 0h 0m)



This concerns the residual rates, and whether they are in sec/sec or mHz.  The problem is that if you have  single
rate solution for different IFs, ie. at different frequencies,  for example FRING w/ APARM(5)=1, 
then the solutions for rate can be constant across the IFs (freqs) either the sec/sec rate or the mHz one, 
but they cannot both be constant in both (except in the trivial case of 0 mHz).  

I think the reasonable assumption is that it is the rate in sec/sec which is constant across the
IFs.  However, the 31DEC14 version of FRING (w/ APARM(5)=1) produces SN tables that have the 
rate being constant in mHz across the IFs, but varying in sec/sec.

FRING run this way generates a SN table that has residual rates,  in sec/sec, which 
scale with IF frequency, so that the SN-table rate (in sec/sec) is different in each IF.    They are 
scaled with frequency so that the rate in mHz is constant across the IFs.

I checked an older SN table made with 31DEC09 AIPS and found that for that version,
the sec/sec rates were in fact IF-independent (meaning of course that the mHz
rate should actually change by dfreq/freq between IFs).

The difference is of course small potatoes, but I think there is some inconsistency in the current version:
1)  LISTR, opty ='GAIN'; DPARM(1)=7:  claims that the mHz rates identical in all IFs
2)  SNPLT, opty='IFDF':                         claims that the mHz rates differ between IFs
The reason for the above discrepancy is that LISTR scales the SN-table sec/sec rates to mHz at 
the reference frequency only while SNPLT does it more correctly and uses the IF-frequency.

(I stumbled across this while investigating some R-L phase winds that were introduced by SNSMO;
although it mostly probably makes not much difference to anything, there may be cases
where it can introduce noxious effects, for example slow R-L phase winds).

        

------------------------------------------------------
Staff CP:  https://help.nrao.edu/staff