Report on the investigations for mosaicing in AIPS++

The profiled run of qimager was found to be healthy.  About 75% of the
total runtime was spent in gridding, de-gridding and memcopy routines.
Most of the time consuming memcopy() calls originated from the
FFTServer (for convolution) and that has already been optimized.  Most
of computational load for Clean type of algorithms comes from the
major cycle residual computation and that in turn is dominated by the
gridding and de-gridding operations.  Hence, the observed profile fits
the expectations.

However the gprof styled profiling only samples the amount of time
spent in each routine.  It does not distinguish between I/O and
computational loads.  The I/O load at present for qimager is probably
still higher than needed and will get fixed with the work that Kumar
is doing (or already done).

We then did a imaging run of the ATCA SMC mosiac with 400 frequency
channels, 6 antennas and 112 pointings.  A 1K x 1K x 100 image cube
was made and deconvoled using the qimager in about 8K sec.  Same run
using imager did not converge in a reasonably time (I waited for a
day!).  A 512 x 512 x 100 cube was made using imager in about 15K sec.
A major difference between qimager and imager based mosaic imaging is
that imager would do a FFT per pointing (112 FFTs in this case), while
qimager does a single FFT (but of a larger size).  For the same image
size, we expect qimager to be faster than imager by a factor of 5 or
more.  Though there will be point of crossover for the performance
curve for the two algorithms as a function of image size.

While I was doing this, there was also a possible bug in the VisIter
where the row blocking being used was very small.  With a fix to that,
the run time for both should improve a bit.

Both, imager and qimager, were quite unstable (apart from being slower
of course) when they had to use TempLattices which went to the disk.
And qimager in general was also less stable than imager.  Also, for
large sized cubes (like the one used in this test), the bigger problem
is that of the need to access the entire cube efficiently rather than
one plane at a time.  This is a more generic problem which affects all
spectral line imaging and we need to think if there is a better
solution for this.

Since we have to anyway work on stabilizing imager (it is more stable
than before and more stable than qimager, but not stable enough to be
called stable IMHO), I think we are better off focusing our efforts on
stabilizing qimager now since the underlying algorithms are inherently
faster.  The underlying better algorithms will not get used/noticed
unless they are packaged in a stable/usable software.  And these
algorithms, according to me, probably for the first time offers
something to the user which gets her/him distinct scientific
advantages and hence the reason to learn a new package (AIPS++).

The interface of imager and qimager are almost same.  For certain
imaging needs (like wide field imaging) qimager interface, due the
underlying algorithm, is actually simpler.  So again, my
recommendation would be focus on existing qimager code for stabilizing
it.  I must also add that further development on this like of code
for qimager must be frozen or else it will not stabilize to the
required level.  The underlying class infrastructure change in the
offing should be done as a separate exercise.