[daip] [!4918]: aips - CLPLT & gdb
Michael Bietenholz
do-not-reply at nrao.edu
Tue May 13 16:45:24 EDT 2014
Michael Bietenholz updated #4918
--------------------------------
CLPLT & gdb
-----------
Ticket ID: 4918
URL: https://help.nrao.edu/staff/index.php?/Tickets/Ticket/View/4918
Full Name: Michael Bietenholz
Email: mbieten at yorku.ca
Creator: User
Department: AIPS Data Processing
Staff (Owner): -- Unassigned --
Type: Issue
Status: Open
Priority: Default
SLA: NRAO E2E
Template Group: Default
Created: 13 May 2014 08:45 PM
Updated: 13 May 2014 08:45 PM
Due: 15 May 2014 08:45 PM (2d 0h 0m)
Resolution Due: 21 May 2014 08:45 PM (8d 0h 0m)
I'm not sure if this is an AIPS bug or not, it could just indicate a strange failure of gdb and/or , gcc version 4.6.3 (64-bit, Ubuntu/Linaro 4.6.3-1ubuntu5; Ubuntu 12.04), but I'll put it up here in case anyone knows what is going on.
I was getting strange results from CLPLT, and I was trying to run it under gdb to figure out what was going on. This is the 31DEC13 version (although the .FOR is identical to the 31DEC14 version). I found very strange behaviour while I was stepping through the program line-by-line in gdb, with control jumping around apparently without regard for the code. Here's a piece of code from CLPLT.f (attached) with line # prepended:
1250 SUBROUTINE SCALCL (IRET)
........ [many statements, but all still inside SCALCL]
1698 C Determine the number of
1699 C triplets to be plotted.
1700 IF (.NOT.DOALCL) THEN
1701 CALL CLOSET (XANT, NUMTRP, CPTRIP, IRET)
1702 IF (IRET.NE.0) GO TO 999
1703 C All independent
1704 ELSE IF (INDECL) THEN
1705 CALL INDCLT (NANT, NUMTRP, CPTRIP, IRET)
1706 IF (IRET.NE.0) GO TO 999
1707 C Else plot them all
1708 ELSE
So I get to statement 1700. At this point DOALCL and INDECL are both .TRUE. Now I would expect that it would run 1705 next, but inexplicably, I wind up back at statement 1250, i.e. the start of the routine I was already in (doesn't matter whether in gdb I use "n" to step over subroutines and execute the next statement; or "s" to step into subroutines).
When COMLNK'ing it I got numerous warnings about
"Warning: Possible change of value in conversion from REAL(4) to INTEGER(4)" (see CLPLT.LOG, attached), although in the end it
did seem to COMLNK successfully. Is it perhaps some strange effect of code which is not 64-bit clean?
While on the subject, there two very minor quibbles with the actual CLPLT program & doc: the help file for adverb TRIANGLE claims that it is used *in conjunction* with ANTENNAS and BASELINES, however, the two places I think it shows up, CLPLT and CAPLT, "TRIANGLE" seems to be used *instead* of ANTENNAS and/or BASELINE.
The other thing I noticed is that if you have closures that are exactly +-180degs (as might be obtained from model data rather than observed data), then setting BPARM = 0,1,1,0,0,-180,180 will cause many points not to be plotted, but without giving you any warning that they are out of range. In fact on my data set I had to set the limits at +-182 degrees to get all the points. I assume that because of some numerical inaccuracy, some points are calculated to have closure phases slightly in excess of 180degs, but it might better to have enough slop built in to CLPLT so that it plots all the points with the limits set at +-180degs. when the limits are set to +-180degs.
------------------------------------------------------
Staff CP: https://help.nrao.edu/staff
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CLPLT.LOG
Type: text/x-log
Size: 19665 bytes
Desc: not available
URL: <http://listmgr.nrao.edu/pipermail/daip/attachments/20140513/9b8373dc/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CLPLT.f
Type: text/x-fortran
Size: 353406 bytes
Desc: not available
URL: <http://listmgr.nrao.edu/pipermail/daip/attachments/20140513/9b8373dc/attachment-0001.bin>
More information about the Daip
mailing list