[daip] Web page
Eric Greisen
egreisen at nrao.edu
Mon Nov 26 17:13:37 EST 2012
Katherine Blundell wrote:
> Hi Eric,
>
> Belated Happy Thanksgiving. I'm glad Lynn was in good shape and you could spend quality time with her.
>
> I intend to try and catch up on sleep this weekend. I'm sure that will help everything.
>
> Btw - I encountered a bit of a curiosity in AIPS today, with my new student Rob who is processing our recent
vlba data on ss433. Rick had reminded me last week in Manchester of
the remarkable importance of getting the
peak of a map on the absolute centre of a pixel, so I used impos then
maxfit to get the fitted position of the
peak on the image (which is very well defined in these data). Then
we used Rashift and Decshift in imagr...
However, this didn't behave entirely as expected. We tried several
iterations but I reached the conclusion
that it is as though there is some of rounding issue in trying to shift
by e.g. 0.4 of a pixel that is 0.0005
arcsec across. At first I thought it was because I was doing some of
the arithmetic in pops, but even doing
the relevant arithmetic on a calculator then typing it to Rashift and
Decshift produced results that were just
a little out and never quite right. Is it possible that there could
be a rounding error lurking in Rashift
and Decshift for milli-arcsec cell sizes?
>
> I also found myself wondering if you could make a slight tweak to maxfit... Could you get it to output what
Rashift and Decshift would be needed to move the peak it has just
found to the nearest centre of pixel? It
would save the business of getting the signs right first time!
There is no way that the code (spread all over) is doing any truncation
of entered RASHIFT and DECSHIFT values. In most places the computations
are done with double precision, but not all as these start as single
precision numbers. So long as your shifts are 12.0003 arc sec but
0.0012 or so there should be no loss of accuracy. There is some danger
with the Intel compiler optimizer which does not like double precision,
but I don't think it really violates most rules. We did catch it
once doing single in
s = d1 - d2
where d1 and d2 are double and s was single. This messed up FRING so we
made s double.
Adverbs are fundamentally single but we could force more double
computations deeper - but it should not matter with small shifts.
I have worked on MAXFIT as you requested (a lot of work actually to get
things like rotation correct). It will output the SHIFT adverb to then
set, e.g. for IMAGR RASH=shift(1),0; DECSH=shift(2),0
Run the MNJ tomorrow.
Eric
More information about the Daip
mailing list