[daip] SDGRID convolution function

[Glen Langston]

Thanks for the update.

Actually the Orion data do have spectral lines.  There
are actually two lines at opposite ends of the bands (NH3 1-1
at 23694 MHz and NH3 2-2 at 23722 MHz, and nothing much in the middle,
the lines are about 8 km/sec wide or about 0.6 MHz, but there
are several lines in the NH3 1-1 and 2-2 spectra, separated
by about 0.3 MHz)

It takes running IMLIN to subtract out the continuum to see the
lines.  See the figures at the top of page:

https://safe.nrao.edu/wiki/bin/view/Kbandfpa/WebHome

In that example, we'd averaged three channels (I'm not sure
what data we gave you concerning averaging of channels, the
original data set has 4096 channels)

I appreciate your points.  Its a tough problem, but I think
the thing to check is for the "divide by zero problem" in the
sum of weights.    Maybe perform a quality control check on the
sum(wt), not just on the individual input "wt" weights input
to the grid.   If "sum(wt)" falls inside some +/-threshold, then
those data should be flagged as well.   This check threshold
could be a new parameter or threshold = max(wt)*reweight(2) (?).
or something similar.

Any other thoughts?

Thanks

Glen

> Bob Garwood wrote:
>> I think what I've been slow to wrap my head around is the difference
>> between weighting by a function that goes negative vs one that is always
>> positive.   i.e. thinking of it as something like <x> =
>> sum(x*wt)/sum(wt) we think of it as a weighted average of x.  But when
>> both x and wt can be negative then surprising things can happen.  In
>> this case it must be that an essentially unsampled point in the grid is
>> getting a small (in terms of abs(wt)) contribution from a couple of data
>> points such that the sum(x*wt) value is increasing (either positively or
>> negatively) while the sum(wt) value is decreasing.   That can't happen
>> for the exponential function, even at poorly sampled cells.
>>
>> FYI: I've verified at least qualitatively that it will work for us to
>> process the data from each beam in a separate process (for
>> parallelization purposes) and then combine the resulting images with
>> weights to get the final image (as opposed to dbcon'ing all of the data
>> and then making one image).  For that I think it's best to use
>> reweight(2) = some very small number and capture the convolved image
>> (reweight(1)=2) and the weight image (reweight(1)=3).  Assuming all of
>> the beam images are made with the same center, cellsize, etc, then
>> combining the images is just summing the convolved images, summing the
>> weight images and dividing the two.  At that point you can apply a
>> cut-off in weights and blank the final image appropriately.  It's also
>> necessary when summing the images to watch out for the NaNs in the
>> things being summed.  In IDL I had to replace those with zeros before
>> summing.  I would expect that to be the same as doing it via dbcon and
>> one call to sdgrd and qualitatively it looks the same - I haven't yet
>> done a quantitative comparison.
>
> Your first paragraph is an excellent explanation of the issue.  I may
> steal some to put in the help file.
>
> Thinks closely and read the details about paragraph 2.  See also section
> 10.4.3 which is about combining independent observations of the same
> field with proper weighting (task WTSUM).  What you propose I think will
> work but check the details closely.
>
> I notices that Glen's data set did not actually appear to contain a
> spectral line.  Instead the images at all channels were noisy but about
> the same.  Is this correct?
>
> Eric Greisen
>