[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