[daip] [!5764]: aips - SNSMO with mode "VLMB" sometimes breaks the relationship between phase(per IF) and delay

[Michael Bietenholz]

Michael Bietenholz updated #5764
--------------------------------

              Status: Open (was: Response Overdue)

SNSMO with mode "VLMB" sometimes breaks the relationship between phase(per IF) and delay
----------------------------------------------------------------------------------------

           Ticket ID: 5764
                 URL: https://help.nrao.edu/staff/index.php?/Tickets/Ticket/View/5764
           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: 11 November 2014 03:35 PM
             Updated: 17 February 2015 05:28 PM
                 Due: 19 February 2015 05:28 PM (2d 0h 0m)
      Resolution Due: 24 November 2014 03:39 PM 



Thanks Eric for the quick work on UVFIT

As far as SNSMO: I think one approach would be to smooth at least delay first and then smooth phase.  However, I think the crux here is that in such cases there is really only one set of values, say those in IF1.  The delay and rates in the other IFs should be identical to the IF1 ones, while the phase in the other IFs should be just calculable from the IF1-phase and the delay.  I'm not sure about amplitude in this case - I'm not sure there is any sensible occasion to run SNSMO with mode=VLMB on SN tables that do not just have unity amplitude gains.  Non-default values of BIF and EIF may not make sense with VLMB either.

So I think a more efficient approach would then be to just smooth IF1, and then after smoothing one could just fill in the SN-table values for the other IFs from ones in IF1

The only issue is if the input table is *not* in this format (ie. has not been generated by FRING w/ APARM(5)=1, or monkeyed  with in some other way).  The options for SNSMO would be to 1) just to *assume* that SN table is in this format, and ignore any values in the input table which are not in IF1, or 2) to check that its true.  I would just go with the former, but perhaps issue a warning that SNSMO is ignoring the values at IFs other 1. For amps one could perhaps just prohibit ampl. smoothing with VLMB (or spin it off independently and just process each IF separately as in other SNSMO modes)

Another worry would be if IF1 happens to be flagged (e.g., no data) - I'm not sure if FRING w/ APARM(5) would then produce flagged SN-table entries for that IF or just produce good SN-table entries, since its calculating the solutions from the data at all the other IFs.

It might be better to use (BIF+EIF)/2. instead of IF1 (although barring any flagging or non-conforming input SN-table issues, it should produce identical results).

               


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