[daip] SDGRID convolution function

[Bob Garwood]

Eric Greisen wrote:
> 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?
There is emission there.  But there's also continuum in the channels so 
it's difficult to see.  If you do a slice through cells north of the 
center (e.g. (46,49) ) you should see 2 groups of lines.  The rest 
frequency in this data really is just the center of the band and, I 
think, not an actual line.

It's difficult to automate baseline removal and so the KFPA pipeline 
will likely not attempt to do that and instead just give the user the 
calibrated data without any baseline removal - leaving that for 
something to do downstream on the image cube.

As far as the second paragraph goes.  I need to think this through more 
carefully.  We need to be able to do this for a second reason: the 
pipeline will just process individual mapping passes across a region.  
Deeper integrations done by making multiple passes or extending the 
mapped region to wider areas will need to be turned into a final image 
by carefully knitting together (aligning and co-adding the individual 
images).  That means that we're going to need to carry around the 
appropriate weights to properly combine the images.  Looking at the 
SDGRD help files I'm starting to think that that means using the 
reweight(1)=3 type of output or perhaps using WT for the UVWTFN 
parameter (I actually can't tell what that defaults to but perhaps I've 
just missed that in the file).  From reading the help file, it looks 
like reweight(1) = 2 isn't quite right because it normalizes the weights 
to 1 which might be close to OK in the case of combing the data from 
each beam all taken on the same pass across the image but I doubt it's 
right when combing data taken from different passes across that 
image.    I'll look more closes at 10.4.3.

-Bob
>
> Eric Greisen
>