[daip] IMAGR channel binning problem

[Eric Greisen]

Linda Watson wrote:
> Dear Eric and Eva,
> 
> I think there might have been a little bit of miscommunication.  I'm 
> still new to this, so I apologize if I'm wrong and this makes things 
> more confusing.
> 
> Just to be complete here, I'll explain our velocity averaging problem: 
> when we attempt to do velocity averaging in IMAGR on the file Eva sent 
> and using the parameters below, the result is an image with the correct 
> number of channels (half the original), but the emission in each channel 
> is the same and it looks like a bright, almost point-like source in the 
> middle with a very high amplitude beam pattern.  In contrast, an image 
> without velocity averaging looks okay to me, with the typical rotation 
> curve pattern.  And strangely, when we do the velocity averaging in 
> SPLIT (using APARM(1)=1, NCHAV=2, CHINV=2) and then run IMAGR with 
> NCHAV=1, the image also looks okay.
> 
> My interpretation of Eva's email from yesterday is that she was
> asking if the bad continuum subtraction of the source in the NE of the 
> image caused the problem we had in averaging channels together in IMAGR, 
> which, according to my interpretation of Eric's emails, is not the case.
> 
> I believe Eric wanted to bring our attention to the fact that the 
> continuum subtraction went badly for the source in the NE.  But as I 
> understand it, this is completely independent of our original query 
> about the velocity averaging.  Perhaps this is very basic and the things 
> you are discussing are higher order, but I think the continuum 
> subtraction went badly because the source in the NE is at a lower 
> redshift relative to NGC 2805 (the central object).  Therefore the 
> high-frequency channels that I use to fit the continuum for the central 
> source actually contain emission for the NE source.  When I do the 
> continuum subtraction, an over-subtraction results.  We are not 
> interested in the NE source at all.  The over-subtraction does not seem 
> to be negatively affecting the data for the central source, so I would 
> tend to just accept it.
> 
> I can at least exclude the possibility that aliasing from EVLA-EVLA 
> baselines is the cause of the bad continuum subtraction.  We excluded 
> all EVLA-EVLA baselines to minimize the aliasing problem.
> 
> Eric, since I have gotten a bit confused, could I ask you to confirm 
> once more that using the same input parameters as Eva sent (copied 
> below), IMAGR produced a reasonable (i.e. not a point source with a 
> strong beam pattern) result for you?  Since doing the velocity averaging 
> with SPLIT works for us, does it seem reasonable for us to just use this 
> rather than velocity averaging in IMAGR?  And finally, do you think the 
> over-subtraction of the NE source is affecting the data for the central 
> source and deserves more attention?
> 
> Thank you both so much for helping me,
> Linda
> 
> 
> -------------
> IMAGR inputs:
> 
> default 'imagr';sources 'ngc2805','';calcode '';freqid 1;qual -1
> timerang 0;selband -1;nfield 1;uvwtfn 'un';gain 0.1;bmaj 0
> selfreq -1;subarray 0;docalib -1;gainuse 2;dopol -1;blver -1;
> flagver 1;doband -1;bpver 1;smooth 0;stokes '';bchan 1;echan 0
> channel 0;bif 0;eif 0;outdisk 0;outseq 1;outver 0;in2name ''
> in2class '';in2seq 1;in2disk 0;do3dimag -1;fldsize 0;rashift 0
> decshift 0;uvtaper 0 0;uvrange 0 0;guard 0 0;rotate 0;zerosp 0
> uvsize 0 0;uvbox 0;uvbxfn 1;xtype 5;ytype 5;xparm 0;yparm 0
> bcomp 0;allokay 0;boxfile '';oboxfile '';minpatch 51;overlap 0
> phat 0;factor 0;cmethod '';imagrprm 0;ngauss 0;wgauss 0;fgauss 0
> maxpixel 0;bpa 0;bmin 0
> 
> outname 'ngc2805-test'
> cellsize 4
> imsize 512
> robust 5
> niter 0
> nboxes 1
> clbox 0
> flux 0
> nchav 2
> chinc 2
> dotv -1
> 
> getn 24 (this refers to am942_ngc2805_line_uvlin.fits file)
> go imagr
> 
> 
> 
> On Fri, 29 May 2009, Eric Greisen wrote:
> 
>> Eva Schinnerer wrote:
>>>
>>>  Hi Eric,
>>>
>>>  Thank you very much for looking into this! I am cc'ing Linda Watson on
>>>  this message as well as she has been doing all the hard work. I just 
>>> want
>>>  to check that I understood you correctly: Due to the strong continuum
>>>  source off the field the continuum subtraction was non-perfect and 
>>> this is
>>>  causing the effect we see in the averaged channels. Is that a correct
>>>  summary? I am only puzzled that we did not encounter this effect when
>>>  using the averaging option in SPLIT.
>>
>> Your summary is correct except that the channel averaging has nothing 
>> to do with it and SPLIT and IMAGR averaging produce very near 
>> identical results.  I do not know why you THOUGHT that you did not see 
>> the effect after a SPLIT, I certainly did and I also saw it with no 
>> channel averaging.
>>
>> I have thought of another possibility.  When there is strong continuum 
>> and a narrow total bandwidth, the interim VLA produced a bad aliasing 
>> only on EVLA-EVLA baselines.  This was an aliasing of the continuum 
>> from "negative" frequencies (to the left of the band) that caused the 
>> continuum to come in strongly at low channel numbers with the aliasing 
>> dropping off as channel number increased.
>>
>> Unfortunately, I deleted your data set already since it was large - 
>> otherwise I would look for this.  Use POSSM on the uv data before the 
>> continuum subtraction.  There is a proc FXALIAS which helps with this 
>> problem but it is not a magic bullet.  See the AIPSLetter for June 30, 
>> 2008 and the NRAO VLA observing pages.
>>
>> ERic Greisen
>>
> 

I took the parameters the Eva sent and drag-dropped them in my aips 
window.  They looked fine.  Note that I did IMAGR with nchav 2 and SPLIT 
with NCHAV 2 and made the dirty image cubes.  I then did a COMB where I 
difference the cubes and then TVMOVIE on that as will as looking at 
histograms etc.  The two results were identical to 1/1000 or better and 
the pattern of differences suggested that IMAGR would likely be better 
in that it knows about the freq difference.  Eva's complaints did not 
make clear what you have just said but I saw no sign of it.   The images 
made with 2 different compilers in IMAGR and one additional test with 
SPLIT essentially produced the same results.  The sidelobes of the 
source to the NE will cause you problems but perhaps they will Clean 
away enough.  The images themselves did not look good but they were the 
same with all 3 approaches plus IMAGR with NCHAV=1.

Eric Greisen