Hi Eric,<br>
<br>
Thanks for info. I have stressed to the folks here that I think they really need<br>
to make a revision to the way they convert to FITS so that the files are<br>
more conventional. If for no other reason than that would make life much<br>
easier when adding data. I'm glad that my FQ table modification is ok. It <br>
seemed to work fine in the tests I ran. I was worried about CALIB because<br>
when I calibrate the pseudo-continuum here I do it on the line data and give<br>
CALIB a range of channels. I was not certain exactly what calculations went<br>
into the use of those channels and in particular if the frequency of each channel <br>
was needed for the calculations. I guess that this is not the case then based on<br>
your e-mail? <br>
<br>
So far things are much better here at the site than previously. I wouldn't say the<br>
data are anywhere comparable to VLA data but for bright sources where resolution<br>
at lowish frequencies is needed this system would be great. Unfortunately my project is not<br>
that so I'm not sure I'll get much out of this. It is still too early to really tell though. <br>
Cheers,<br>
                         
Tracy<br><br><div><span class="gmail_quote">On 2/14/06, <b class="gmail_sendername">Eric Greisen</b> <<a href="mailto:egreisen@nrao.edu">egreisen@nrao.edu</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Tracy Clarke writes:<br><br> > We are working on GMRT data in India and have run into an odd issue we<br> > wanted<br> > to ask you about. We are working in 31DEC05 AIPS and the way the GMRT<br> > writes their data they have two sidebands, one with a negative frequency
<br> > increment and one with a positive. They allocate this increment by writing<br> > the<br> > sideband label in the FQ table as -1 for the file with the negative<br> > increment<br> > and +1 for the sideband with the positive increment. We have noticed in
<br> > IMAGR<br> > though that this does not work in 31 DEC05 and so IMAGR thinks both data<br> > sets<br> > have positive increments. I did a quick fix to this by re-writing the<br> > channel width in<br> > the FQ table to be a negative channel width and so IMAGR now calculates
<br>> things<br><br>    Yes - the sideband code is not used so far as I know and the<br>channel width has been handled badly until recently (i.e 31DEC06) when<br>the 2 differ.  IMAGR may well get it right but DBCON and SPLAT with
<br>averaging of channels did not.  This is the correct fix and is an<br>error on the GMRT's part.<br><br> > for the correct frequency. I am worried though about CALIB. It is not clear<br> > to me<br> > what this will mean for CALIB and I have spent the day trying
<br> > (unsuccessfully) to<br> > do tests to see if CALIB is calculating the channels with the correct<br> > negative<br> > frequency increment or if it is seeing a positive one. Could you please<br> > advise me on
<br> > how to determine what exactly CALIB is seeing for the frequency increment?<br><br>Why do you think CALIB cares?  It is a continuum task.<br><br>Eric Greisen<br></blockquote></div><br>