[daip] 31DEC07 LINUX midnite job (dave, 20070322.044406)

Eric Greisen egreisen at nrao.edu
Thu Mar 22 11:18:40 EDT 2007


Walter Brisken writes:
 > 
 > Hi Eric,
 > 
 > Two of todays midnight job updates seem related to things that I've 
 > suspected in the past but could not conclusively prove as problems.  Both 
 > affect astrometry so I've been reluctant to use these functions since 
 > starting to wonder about them.  Is it possible to get a bit more 
 > description of how or under which circumstances they affect data?  For 
 > example, for the CLCOR problem noted below, is this for opcode = 'ANTC', 
 > 'ANTP', or both?  For the UVFIX problem what is the error in REFCHN for 
 > uncompressed data?  In both cases my usage of these functions has been for 
 > position shifts of up to 10 mas and I'd be senstive to errors up to 0.05 
 > mas.  Have these problems been around since the beginning or were they 
 > introduced more recently?  It seems that my use of UVFIX to move a source 
 > for my ionosphere calibration seemed to work better before 2002 than it 
 > did recently, but that might be mostly due to signal-to-noise differences 
 > between the two experiments.  It might be worth informing the astrometry 
 > community of these fixes.
 > 
The CLCOR problem has been there for some time - arising due to the
change in which the source position is updated in the SU table (before
the phase change is computed).  It is 2nd order in that it shifts the
phase in the right direction but from the output position to the
output + another delta.  It should have been and is now output
position - delta to output position.

The UVFIX problem was a frequency error of REFCHN channels in
uncompressed data only.  Typically REFCHN=1 so it is 1 channel
separation over the center frequency * the shift.  In Amy's data this
was 1 part in a 1000.  Prior to about 2002, UVFIX did not include the
W * Delta Z term, so the modern code really should be better in that
respect.

It would be good if you informed us of problems so that they could be
addressed sooner.  Amy was kind enough - through her student - to
document this issue and enable us to find the problems.

Eric Greisen




More information about the Daip mailing list