[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): Eric Greisen
                Type: Issue
              Status: Open
            Priority: Default
                 SLA: NRAO E2E
      Template Group: Default
             Created: 14 February 2014 12:10 AM
             Updated: 24 February 2014 10:56 PM
      Resolution Due: 27 February 2014 12:12 AM (2d 1h 16m)




If the SN-table rates *in mHz* are independent of IF then SNPLT seems to plot exactly the same value (in mHz) for the different IFs, as it should.

If run in 'IFDF' mode, SNPLT *does* plot IF-IF differences in rate in this instance.  

It believe SNPLT is 1) scaling the sec/sec to mHz correctly per IF when run normally,  and 2) when run w/ IFDF mode it first calculates the relevant IF-IF differences in sec/sec and then scales the difference to mHz (probably using the freq of the first of the two IFs involved in the
difference).

This is a bit inconsistent since if run in the normal mode, the rates in each IF are identical, and one might expect IF-IF differences should be identically zero.  When run in IFDF mode, however, SNPLT shows non-zero differences.   

As far as FRING solutions, you are correct.  I think when I looked at an old table, it was one that had been passed through SNSMO, and I hadn't
figured out that caused the sec/sec rates to become IF-independent.  So, as you had said, the situation is and has been for a long time that FRING (DPARM(5)=1) calculates its rates in mHz and therefore comes up with IF-dependent values in sec/sec in the SN-table.  Running SNSMO (VLMB) seems to turn these into IF-independent sec/sec values.  Presumably the reason for SNSMO's behaviour is that smooths all the rates together (across IF as well as in time), and does so using the SN-table sec/sec entries.

At this point, I'm not sure what the right way of doing it is.  It seems a bit odd that SNSMO (VLMB) starts with sec/sec rates that do scale with IF and outputs sec/sec rates that don't scale with IF, but then I also think that its the sec/sec values are actually the ones that *should* be IF-independent.  In practice this likely doesn't make a much difference to anyone anyway.

I've attached an TASAV with some relevant tables
1) FRING output (IF-dependent rate values)
2) SNEDT SN1
3) TABED SN2 to drop -ive weight rows (I've found this helps with SNSMO interpolation problems)
4) SNSMO (SMOTY 'VLMB'; SAMPTYP 'GAUS'; CPARM 1.5 1.5 1.5 0 0 0.5 0.5 0.5 0 0; REFANT 7) of SN3


------------------------------------------------------
Staff CP:  https://help.nrao.edu/staff
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tasav.fits.gz
Type: application/x-gzip
Size: 1797783 bytes
Desc: not available
URL: <http://listmgr.nrao.edu/pipermail/daip/attachments/20140224/609251d6/attachment.gz>