As of Wed Jun 12 9:14:00 2024

VBGLU: Task which glues uv frequency blocks back together


INNAME                             Input UV file name (name)
INCLASS                            Input UV file name (class)
INSEQ             0.0     9999.0   Input UV file name (seq. #)
INDISK            0.0        9.0   Input UV file disk unit #
IN2NAME                            Second UV file name (name)
IN2CLASS                           Second UV file name (class)
IN2SEQ            0.0     9999.0   Second UV file name (seq. #)
IN2DISK           0.0        9.0   Second UV file disk unit #
IN3NAME                            Third UV file name (name)
IN3CLASS                           Third UV file name (class)
IN3SEQ            0.0     9999.0   Third UV file name (seq. #)
IN3DISK           0.0        9.0   Third UV file disk unit #
IN4NAME                            Fourth UV file name (name)
IN4CLASS                           Fourth UV file name (class)
IN4SEQ            0.0     9999.0   Fourth UV file name (seq. #)
IN4DISK           0.0        9.0   Fourth UV file disk unit #
OUTNAME                            Output UV file name (name)
OUTCLASS                           Output UV file name (class)
OUTSEQ           -1.0     9999.0   Output UV file name (seq. #)
OUTDISK           0.0        9.0   Output UV file disk unit #.
FQCENTER                           >= 0 -> center frequency axis


Task:  This task is meant to deal with data sets that are very similar
       but have been separated by frequency.  The initial use was for
       the old hardware VLBA correlator which could do all baselines
       simultaneously, but only 8 IFs at a time.  Current usage often
       involves putting multiple IFs back together after they have
       been separated in order to simplify calibration and editing.
       (Remember UVRANGE applies to the header frequency and so has a
       very different behavior with different IFs of wide-band data.)

       A new usage is to combine data sets that have the same number
       of polarizations and spectral channels, but differ in observing
       frequency and even in observation date.  They must also have
       identical antenna tables.  IMAGR cannot, intrinsically, handle
       multiple FQIDs, so VBGLU offers the possibility to combine
       different frequencies in a way that IMAGR can handle - at the
       cost of a doubling of the data set size (for 2 input data sets).

       Up to 4 input files can be handled simultaneously.  The task
       has been rewritten so no data are lost even when not all files
       have data from the same times.  The task will also glue
       together all table extension files, combining all version 1
       extensions of a given type into output version 1, all version 2
       extensions (if any) into output version 2, and so forth.  The
       user should be careful to make sure that this is a meaningful
       operation - e.g. all CL table versions 4 contain the same level
       of calibration.  The one exception is that the highest flag
       table versions found in the input files will be combined into
       one output flag table.

       Certain table types may not be handled by this task.  FO
       (frequency offset) and BS (baseline solution) tables are
       not processed properly.  The former is used by CVEL and PCVEL,
       after SPLIT; the latter is used by BLAPP and BLING.  FITS IDI
       tables that are translated by FITLD are not handled.  Any EOP
       correction should be applied to the input files before VBGLU
       unless the CT tables are all identical.

       It is best if the random parameters are all the same in the same
       order.  The task will attempt to fix this if they are not.  The
       first input file should have the maximum number of parameters.
  INNAME.....Input UV file name (name).      Standard defaults.
  INCLASS....Input UV file name (class).     Standard defaults.
  INSEQ......Input UV file name (seq. #).    0 => highest.
  INDISK.....Disk drive # of input UV file.  0 => any.
  IN2NAME....Second file name.
  IN2CLASS...Second file class
  IN2SEQ.....Second file sequence number.
  IN2DISK....Second file sequence number.
  IN3NAME....Third file name.
  IN3CLASS...Third file class
  IN3SEQ.....Third file sequence number.
  IN3DISK....Third file sequence number.
  IN4NAME....Fourth file name.
  IN4CLASS...Fourth file class
  IN4SEQ.....Fourth file sequence number.
  IN4DISK....Fourth file sequence number.
  OUTNAME....Output UV file name (name).     Standard defaults.
  OUTCLASS...Output UV file name (class).    Standard defaults.
  OUTSEQ.....Output UV file name (seq. #).   0 => highest unique
  OUTDISK....Disk drive # of output UV file. 0 => highest with
             space for the file.
  SUBARRAY...Subarray to do.  0 -> all.
  FQCENTER...>  0 => Change frequency axis reference pixel to
                     Nchan / 2 + 1
             else => do not change reference pixel


VBGLU Glues VLBA data together IF by IF.
DOCUMENTOR: P.J.Diamond & Amy Mioduszewski


NOTE: VBGLU will only work on single FREQID datasets.

It may now be used to combine data sets that would be different
FREQIDs if combined in other ways.

VBGLU Glues together data that were correlated in multiple passes on
the VLBA correlator, multiple pass is not used in its historical
sense of different baselines/pass but in the sense of different
IFs/pass. This is necessary because the VLBA correlator can only deal
with 8 IFs at a time, but when MkIII Mode A,B or C are correlated the
data have to be split up in frequency space.

VBGLU reads the file headers and FQ tables and constructs a composite
header/FQ table.  It reads all input files constructing a time-ordered
list of output records.  When times and baselines match the output
data will contain the input data from all input files.  For times when
the files do not match, some output IFs will be marked as flagged
while the other output IFs will contain the appropriate data.  No data
will be lost in this way, although some records may not contain data
for all IFs.  The task is more efficient if the data are in strict
time-baseline order, but any order can be processed.

Several assumptions are implicit in this process:
   (1) The source/antenna numbers are identical - use task MATCH to
       fix this if needed.
   (2) There are the same number of spectral channels per IF
   (3) There is a sigle FREQID

VBGLU then copies those tables that have no IF dependency. It then
takes the tables that do have arrays that depend on IF and performs an
analogous operation to that done on the uv-data. The tables from the
first file are taken to be the master representations and the others
are merged with them. The tables that are bonded in this way are:
     AT  IM  CL  SN  MC  TY  PC  BP  BL  SU  GC  CQ
If there is a significant mismatch between the tables a warning
message is issued.

CT Table

One table that is treated differently than those above is the CT table.
The CT table is the CALC table and contains the earth orientation
parameters (EOPs) that were used by the correlator.  It is possible that
the EOPs used were not the most accurate because it takes a week or two
after the observation date to get the most accurate EOPs (see VLBA
Test Memo 69).  Inaccurate EOPs can substantially negatively effect
phase referencing experiments.  Therefor it is recommended that they are
corrected with CLCOR (OPCODE=EOPS; see EXPLAIN CLCOR).  CLCOR uses the CT
table to calculate the difference between the old EOPs and the new EOPS.
Therefor, it is VITAL that the CT table be correct.  The CT table has
no IF dependence but it is possible in the two correlation that the
EOPs were different.  So VBGLU compares the CT tables and if they are
identical and if they are not it refuses to copy them and issues a

If VBGLU refuses to copy the CT table to the output file and you want
to fix the EOPs for your experiment you can follow these steps, BEFORE
running VBGLU:

1) run CLCOR (OPCODE='EOPS') on both files.
2) run SPLAT to apply those corrections (because VBGLU only copies the
   first CL table).
3) run VBGLU on the SPLATed files