[daip] VLBAUTIL vlbapcor procedure

[Yuri Y. Kovalev]

Dear Amy,

I have a different view on the whole reason to have the phase cals in 
the first place, but I can be wrong and in any case this is not 
important for our discussion. What you describe below is the second 
order effect which I always keep in mind. FRING will take care on this 
residual effect, if any. This will certainly *not*damage* the data.
I guess there are experiments for which it could be important, but not 
many (they can easily avoid using vlbapcor). However, there are many 
experiments with short enough scans.

In my case it has indeed damaged the data. Believe it or not, I have 
lost some IFs of a short K-band scan on 3C279 because of this effect. 
That is how I discovered the problem.
(I did vlbapcor and then FRING.)

Again, it is completely up to you to decide what is the best approach in 
vlbapcor. My claim is that the 31DEC07 version with 'self' could and has 
already damaged data. And I do not think a potential problem will be so 
severe for the '2PT' approach.

Many thanks for your work on vlbautils.

Cheers,
Yuri.

On Tue, 8 Jan 2008, Amy Mioduszewski wrote:

> Dear Yuri,
> 
> Phase cals change because of the slew.  So if you are slewing between very
> different positions the cable wraps etc. will give you different phase cals,
> the is the whole reason to have phase cals in the first place.  Admittedly
> this is not much of a problem with the VLBA because it is so stable but would
> be with non-VLBA stations.  I can see your problem if you have short scans
> very far apart in time, but think I need to stick to the current settings
> because to change the interpolation to 2PT could damage someones data by
> putting phase ramps at the beginnings and end of scans as it did for the user
> than reported the problem.
> 
> Have you tried VLBAPCOR on your data?  You haven't told me if it "did" result
> in a problem just that it "could" result in a problem.
> 
> Amy
> 
> Yuri Y. Kovalev wrote:
> > 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
> > > > 
> > > 
> > 
> > _______________________________________________
> > Daip mailing list
> > Daip at listmgr.cv.nrao.edu
> > http://listmgr.cv.nrao.edu/mailman/listinfo/daip
> > 
> 
>