[daip] question INDXR

[Jim Ulvestad]

On Wed, 3 Jul 2002, Thomas Krichbaum wrote:

> Hi,
> 
> we  started loading some VSOP data (V053D4, Oct.2000). I run FITLD, MSORT, USUBA, INDXR.
> This produces a new CL and NX table (because of subarray conditions met by FITLD).
> With LISTR and optype 'SCAN' I get lots of entries (new scans every couple of seconds), not
> matching at all the actual vlbi schedule. 
> 
> In the past I fixed such problem by UVCOPing only the xc's and throwing all ac's
> away, then reruning INDXR. Is there a better method to cure the problem ?
> 
> regards,
>            Thomas
> 
> 

Hi Thomas,

There probably is no better way to solve the problem than what you 
suggest.  The origin of the problem is that the ground telescopes
are changing sources several times, but the spacecraft does not.
This essentially puts the space element into its own subarray at
the times that the ground telescopes are changing sources.
Combining that with the fact that the correlator integration time
for the space baselines is different from the integration time
for the ground baselines (and they may not be related by a 
simple integral factor!), INDXR keeps starting new scans every
time you go across a 2-second (or whatever) dump time.

If you throw away the autocorrelation data, you essentially
throw away all the data from when the spacecraft is in its
own subarray, so then you have left only the subarray with the
ground telescopes continuously observing a single source.
INDXR then knows how to do a sensible job of breaking this
into scans.

I took a look at the schedule file for the observation,
and the job scripts, and I can see how the output data
set could have gotten into a lot of trouble.  Perhaps we
might have come up with a way to not correlate the spacecraft
when it was in its own subarray, but (a) some people want
the ac data from that time, and (b) I think it would have been
a heck of a lot of work.

Cheers,

Jim