[daip] Fwd: Re: AIPS antenna numbers

[Eric Greisen]

-------- Forwarded Message --------
Subject: Re: AIPS antenna numbers
Date: Mon, 22 Jun 2015 08:18:12 -0600
From: Eric Greisen <egreisen at nrao.edu>
Organization: National Radio Astronomy Observatory
To: Colin Lonsdale <cjl at haystack.mit.edu>, daip at nrao.eud

On 06/22/2015 07:30 AM, Colin Lonsdale wrote:
> Hi Eric,
>
> Nearly 2 years ago now I asked your advice on a version of AIPS capable of >90 antennas (see below).  I never got round to implementing it, and last summer my REU student worked on VLBA data, not MWA data.  Now I have another student and we again want to use AIPS for MWA.  I have a version compiled with MAXANT=200 in PUVD.INC, on an Ubuntu Linux box.  Things seemed to work OK, and PRTAN, UVPLT etc showed the data present for all 128 antennas OK.  However, when attempting IMAGR (and I went back to UVMAP as well for a test), it seems something is getting overwritten, I assume in a common block somewhere.  I get lots of error messages from UVWAIT, claiming zero weight for thousands of data points.  By specifying UVWTFN = NA I can get those to go away, but the task still dies nastily, with the sum of gridding weights=0, and silly numbers coming out of QINIT.  The error messages are copied at the end of this message.
>
> To make sure this is not something wrong with the MWA data files, I tried the MAXANT=200 version on last summer's VLBA data and got the same result - the messages below are from the VLBA data that was successfully processed a year ago.  I tried to do some grepping around for where the problem might be, and saw some hardcoded array sizes in PUVD.INC, like XBTBSZ, but I really don't know where to look - it's been a long time since I messed around in the guts of AIPS.
>
> So, any insights or help you can offer would be very gratefully received.  We are a bit stuck here, and the tools in AIPS for exploring the behavior of MWA data are very much needed.


This sounds like our experience trying to compile AIPS with relatively
recent versions of gfortran.  I had good luck with gfortran 4.4.7 which
comes with our RedHat 6.  More recent versions do what you describe.

If you can find an option to the compiler that tells it to initialize
memory (to zero presumably), that might help.

Sigh....  I guess I may have to work on this.  Our programmers did not
assume dynamic memory and did assume initialization.  Neither of those
are guaranteed in the latest Fortrans.

Eric Greisen