[daip] IMAGR problems

[Eric Greisen]

Colleen Schwartz writes:

 > We're having trouble with IMAGR runs.  We have recently switched over to
 > the 31DEC99 version of AIPS from the 15OCT99 version, and then IMAGR runs
 > I've been doing for the past few months stopped working - the output from
 > IMAGR is at the end of this e-mail.  I've tried both new IMAGR runs and
 > re-running old ones, and we always get this error.  All of our
 > calibrations were done with the 15OCT99 version of AIPS.

       As you can imagine, many runs of IMAGR are done every day and
we have not heard of the complaint below prior to this e-mail.  It
makes me think that there must be something special about your
setup/usage or ??  It would help to see the IMHEADER of the input file
and the full set of INPUTS to IMAGR.

 > 
 > We tried using in the patches QCLEAN.FOR and QUVUTIL.FOR, thinking
this

        The patches for QCLEAN and QUVUTIL are for 15OCT99 not for
later versions.  No patches have been released as yet for 31DEC00
(since 31DEC00 is still not quite ready for release).  Apply the
QCLEAN and QUVUTIL of 15OCT99 to 31DEC00 would not be functional.

 > might fix the problem, and then we upgraded to the 31DEC00 version of AIPS
 > and again tried to use the patches, and both times the patches
failed to

       31DEC00 is just a rename of 31DEC99 other than some time
elapsed and the normal improvements occurred.

 > compile.  We're not sure if this is a compiler error on our end (using f77
 > and cc), but we've gone back to the 31DEC99 version now.  Have you
heard

        I thought 31DEC99 did not work for you.

 > of this happening? Any ideas why IMAGR isn't working?  

       When you got the compiler problems, why did you not e-mail me
then to ask about them?  I might have been able to help.  At some
stage, if you mix versions, then your only choice is top erase
eveything and start over - so it's wise to check as you go and to
report problems when you first encounter them.

       I have no idea why IMAGR works for everyone else and not in
your case.  This error 4 means end-of-file which is wierd since we
check for writing past the end in ways that issue messages and would
not reach the wait function which finds that no bytes were written.
This is a very strange error.  IMAGR's inputs changed a lot between
15OCT99 and 31DEC00 - there may be something visible when you send me
your INPUTS.

Eric Greisen

 > 
 > Thanks,
 > Colleen Schwartz
 > colleen at condor.physics.ucsb.edu
 > 
 > IMAGR output:
 > egret.> IMAGR1: FNDPOL: Stokes I computed assuming V=0
 > egret.> IMAGR1: FNDPOL: Stokes I computed assuming V=0
 > egret.> IMAGR1: FNDPOL: Stokes I computed assuming V=0
 > egret.> IMAGR1: Create W49N CALIB 1.IMAGR .   1 (UV)  on disk  3  cno   13
 > egret.> IMAGR1: Beginning channel  232 through  232 with  1 IFs
 > egret.> IMAGR1: FNDPOL: Stokes I computed assuming V=0
 > egret.> IMAGR1: IMACPY: Copied   101858 visibilities to be imaged
 > egret.> IMAGR1: OUNFWT: Sorting data to make them fit
 > egret.> IMAGR1: UVWAIT: begin finding uniform weights
 > egret.> IMAGR1: UVWAIT ERROR   4 WRITING WEIGHT GRID
 > egret.> IMAGR1: UVWAIT: ERROR WEIGHTING UV DATA
 > egret.> IMAGR1: OUNFWT: ERROR IN UNIFORM WEIGHTING OF UVdata work object
 > egret.> IMAGR1: Deleting UV work file:
 > egret.> IMAGR1: Destroyed  1 extension files of type AN
 > egret.> IMAGR1: Destroyed  1 extension files of type FQ
 > egret.> IMAGR1: Destroyed UV image file: catno=     13 disk= 3
 > egret.> IMAGR1: Purports to die of UNNATURAL causes
 > 
 > 
 >