[daip] VLBAUTIL vlbapcor procedure

[Yuri Y. Kovalev]

Dear Amy,

I have used not the current AIPS but the frozen 31DEC07.
I was reducing the experiment BP125A.
This is a K-band survey which has short (~100 sec) scans on many 
sources, two scans per target, one-two-three scans per (tropospheric) 
calibrator. The two scans on every target are separate by hours. It is 
obvious that in this case, if a phase-cal measurement did not happen 
during the short scan on a given target, the 'self' interpolation could 
result in a problem.

It is very unusual and strange that phase-cals depend on sources. Phase 
cals are a measure of the telescope instrumental delay, should not depend 
on a source to the first order. That is why I would expect the default 
interpolation in the vlbapcor procedure to be '2pt'.
I guess the user DID had to use tasks PCCOR and CLCAL directly not 
affecting the sort-of-standard procedure in the VLBAUTIL vlbapcor.

If you keep 'self' interpolation in vlbapcor, I will just not use this 
procedure in the future any more. That is fine with me.
My worry would be other users who are at a potential danger by using 
this kind of interpolation in vlbapcor.

Cheers,
Yuri.

On Mon, 7 Jan 2008, Amy Mioduszewski wrote:

> Dear Yuri,
> 
> I changed the interpolation for VLBAPCOR because a user DID see differences
> between sources and had weird interpolation effects.  Also, you will see if
> you do a HELP CLCAL, 'SELF' now uses all the data for each source and
> interpolates across scan boundaries.  Have you had a problem with the current
> version, if yes that is most likely a bug with CLCAL not VLBAPCOR.  If so
> please send details of your specific problem.
> 
> Amy
> 
> Yuri Y. Kovalev wrote:
> > Colleagues,
> > 
> > There was made a change in the way how PCAL solution is applied in the
> > VLBAUTIL procedure vlbapcor.
> > Until AIPS version 31DEC06 inclusive a default interpolation was used.
> > Starting with 31DEC07 the interpol 'self' is applied:
> > %%% Part of the VLBAUTIL 31DEC07 code:
> > if vba_ok >=0 then
> > type 'run pccor'
> > task='pccor'; default; tget vlbapcor;task='pccor'
> >   delcorr 0; runwait('pccor')
> > if(vba_frg>0)then
> > type 'run sncor'
> > task 'sncor';default; tget vlbapcor;task 'sncor'
> >  snver=MAXTAB('SN');opcode 'zphs';timer 0; sour ''
> >  runwait('sncor'); opcode 'zdel';runwait('sncor')
> > end
> > type 'RUN CLCAL'
> > task 'clcal';default; tget vlbapcor;task 'clcal'
> > gainv gainu; gainu=MAXTAB('cl')+1; snver=MAXTAB('SN')
> > interpol 'self'; calsour '';timer 0; ante 0;runwait('clcal')
> > vba_sn=snver
> > vba_cl=gainu
> > end
> > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> > 
> > I believe that this change can be potentially dangerous.
> > In case when a short scan is observed, no PCAL value might exist for a
> > given short-scan source and interpol 'self' might deliever proper result.
> > 
> > I also see no specific reason why PCAL soulitons should be applied on a
> > source by source basis (interpol 'self'). There must be no or very little
> > dependence between the instrumental phase and different sources observed.
> > 
> > I suggest that you correct the vlbapcor back to the default interpolation
> > in the task 'clcal'.
> > 
> > Cheers,
> > Yuri.
> > 
> > _______________________________________________
> > Daip mailing list
> > Daip at listmgr.cv.nrao.edu
> > http://listmgr.cv.nrao.edu/mailman/listinfo/daip
> > 
> 
>