[daip] Re: AIPS question

[Tracy Clarke]

Hi Eric,

Thanks for info. I have stressed to the folks here that I think they really
need
to make a revision to the way they convert to FITS so that the files are
more conventional. If for no other reason than that would make life much
easier when adding data. I'm glad that my FQ table modification is ok. It
seemed to work fine in the tests I ran. I was worried about CALIB because
when I calibrate the pseudo-continuum here I do it on the line data and give
CALIB a range of channels. I was not certain exactly what calculations went
into the use of those channels and in particular if the frequency of each
channel
was needed for the calculations. I guess that this is not the case then
based on
your e-mail?

So far things are much better here at the site than previously. I wouldn't
say the
data are anywhere comparable to VLA data but for bright sources where
resolution
at lowish frequencies is needed this system would be great. Unfortunately my
project is not
that so I'm not sure I'll get much out of this. It is still too early to
really tell though.
Cheers,
                          Tracy

On 2/14/06, Eric Greisen <egreisen at nrao.edu> wrote:
>
> Tracy Clarke writes:
>
> > We are working on GMRT data in India and have run into an odd issue we
> > wanted
> > to ask you about. We are working in 31DEC05 AIPS and the way the GMRT
> > writes their data they have two sidebands, one with a negative frequency
> > increment and one with a positive. They allocate this increment by
> writing
> > the
> > sideband label in the FQ table as -1 for the file with the negative
> > increment
> > and +1 for the sideband with the positive increment. We have noticed in
> > IMAGR
> > though that this does not work in 31 DEC05 and so IMAGR thinks both data
> > sets
> > have positive increments. I did a quick fix to this by re-writing the
> > channel width in
> > the FQ table to be a negative channel width and so IMAGR now calculates
> > things
>
>     Yes - the sideband code is not used so far as I know and the
> channel width has been handled badly until recently (i.e 31DEC06) when
> the 2 differ.  IMAGR may well get it right but DBCON and SPLAT with
> averaging of channels did not.  This is the correct fix and is an
> error on the GMRT's part.
>
> > for the correct frequency. I am worried though about CALIB. It is not
> clear
> > to me
> > what this will mean for CALIB and I have spent the day trying
> > (unsuccessfully) to
> > do tests to see if CALIB is calculating the channels with the correct
> > negative
> > frequency increment or if it is seeing a positive one. Could you please
> > advise me on
> > how to determine what exactly CALIB is seeing for the frequency
> increment?
>
> Why do you think CALIB cares?  It is a continuum task.
>
> Eric Greisen
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listmgr.nrao.edu/pipermail/daip/attachments/20060214/0d289b5f/attachment.html>