New compilation - array problems

Hi, I have just recompiled/built a programme a wrote in F95 in 2011/2014 it seems fine expect it not passing a multi dimensional array from a subroutine to another subroutine, its values are zero. ok I am still using the common block method but it does not appear to complain enough, i do get warnings e.g. floating point concerns, but it does prevent compilation it runs except i have these arrays that were zeroed...no good of course.

If you can post a short program that illustrates the failure then someone may be able to help you.

Quoted from PaulLaidler If you can post a short program that illustrates the failure then someone may be able to help you.

PROGRAM ETA WINAPP DIMENSION PXYZ(3),PRPM(10),PRESS(10,8,721),PMEAN(10,1,721) COMPLEX GENG(58,721),DIS(512,3,6),X(512,3,6),KE(6,3),TFC(512,3,6) COMMON /INTG1/ NPT,NCYL,NBRG,IGRP,IANG(8),NPOS,ORMS COMMON /REAL1/ RPM,P(8,721),BDIS(9),WR(9),RALPH(9),F1(9),F2(9),F3(9),F4(9),WROT,WREC,R,CL,D,PMOD(8),TILT,DVEE,TDIS(9),GR COMMON /REAL2/ COG(3),EM,SM(6),TCOG(3) COMMON /REAL3/ THETA(2,721) COMMON /COMP1/ GENG COMMON /COMP2/DIS,X,KE,TFC ........ The key function GENG is referenced in several subroutines...as COMMON/COMP1/GENG.... see example below

SUBROUTINE ENGINE COMPLEX GENG(58,721) COMMON /INTG1/ NPT,NCYL,NBRG,IGRP,IANG(8),NPOS,NRPM COMMON /REAL1/ RPM,P(8,721),BDIS(9),WR(9),RALPH(9),F1(9),F2(9),F3(9),F4(9),WROT,WREC,R,CL,D,PMOD(8),TILT,DVEE,TDIS(9),GR COMMON /REAL3/ THETA(2,721) COMMON /COMP1/ GENG COMMON /ENGR1/ FACTR,FIC(721),YM(8,721),FANG(8)...

I am getting zeros...in GENG. In earlier compilations e.g. 2014 This was fine...now it’s not

Quoted from colt1954 Hi, I have just recompiled/built a programme a wrote in F95 in 2011/2014 it seems fine expect it not passing a multi dimensional array from a subroutine to another subroutine, its values are zero. ok I am still using the common block method but it does not appear to complain enough, i do get warnings e.g. floating point concerns, but it does prevent compilation it runs except i have these arrays that were zeroed...no good of course.

Further to the above is there anyway to compare how the latest compiler has changed since the new compiled version of my old code seems not to work fully.. though the program runs it does not return a key array variable's values correctly, just zeros. So should the compiler flag up the unacceptable condition? Hope this make some sense

Compiler became since that time only deeper picky at user errors. Compile all files with /undef and use SDBG debugger. In debugger there exist options to stop at the place of first use or first change of specific variable. Try to use them to find which place zeroizes your array

colt1954

If you use a) the same code b) the same data and c) the same FTN95 command line arguments, then you can expect to get the same results as before. If you change any of these then it may not 'work' for various reasons.

The thing to do is to first reproduce exactly what you did before and then progress in small step changes.

I am puzzled by what appears in your code as an emoticon (you have an option to suppress them when you post). If it means the presence of a colon then how does that work?

You say you wrote it 'in F95'. Did you use FTN95, or some other compiler?

As Paul notes, what appears as an emoticon is the combination of [colon : ] and [right bracket ) ], and that wouldn't have worked in 2011-14, just like it doesn't now.

Eddie

Quoted from PaulLaidler colt1954

If you use a) the same code b) the same data and c) the same FTN95 command line arguments, then you can expect to get the same results as before. If you change any of these then it may not 'work' for various reasons.

The thing to do is to first reproduce exactly what you did before and then progress in small step changes.

I am puzzled by what appears in your code as an emoticon (you have an option to suppress them when you post). If it means the presence of a colon then how does that work?

Oh no, ignore not sure how they crept in i can assure you no such things exist in the code

Quoted from DanRRight Compiler became since that time only deeper picky at user errors. Compile all files with /undef and use SDBG debugger. In debugger there exist options to stop at the place of first use or first change of specific variable. Try to use them to find which place zeroizes your array

Sorry what's /undef....please, and how do you use the SDBG exactly

https://www.silverfrost.com/ftn95-help/devel/checking_for_undefined_variables_undef.aspx

Suppose you have the program aaa.f95

a=1
b=a*c
Print*, 'b=', b
END

You compile it

FTN95 aaa.f95 /link /debug /undef

You can just run the program as usual and get error report in the form of crash but better run it via debugger and see all the variables

SDBG AAA.EXE

Use F7 and F6 keys to see the execution step by step or just run to the error.

/undef and /full_undef are the most powerful debugging options

Inside debugger there exist prompts how to set debugger to stop on first use of any variable (or similarly stop on any change by the code of specific variable). Point with mouse on any variable and use right mouse button for that. All that is intuitive and does not need any guide, just try and see

The second part of this video by Paul gives a basic introduction to using the debugger from within Plato.

https://www.youtube.com/watch?time_continue=1&v=7P8vPlCPxuk&feature=emb_logo

colt1954,

some more remarks:

it might be worthwhile knowing the version of ftn95 used for your compile/linking step (which is printed if executing command ftn95 in a Windows cmd window);

to get more information about ftn95 I often use the ftn95 online help window (by executing command 'ftn95 --help' in a Windows cmd window);

in order to see what is displayed to the forum before submitting a post I often use the 'Preview' button (and in most cases I do some corrections to my posts before finally submitting them 😃

Regards, Dietmar

Quoted from DanRRight Suppose you have the program aaa.f95

a=1
b=a*c
Print*, 'b=', b
END

You compile it

FTN95 aaa.f95 /link /debug /undef

You can just run the program as usual and get error report in the form of crash but better run it via debugger and see all the variables

SDBG AAA.EXE

Use F7 and F6 keys to see the execution step by step or just run to the error.

/undef and /full_undef are the most powerful debugging options

Inside debugger there exist prompts how to set debugger to stop on first use of any variable (or similarly stop on any change by the code of specific variable). Point with mouse on any variable and use right mouse button for that. All that is intuitive and does not need any guide, just try and see

Hi Dan but where do you type: FTN95 aaa.f95 /link /debug /undef

i use the rebuild option not sure how you invike the above are you suggeting you do it in command mode?

Guys you have been so helpful.

I have found something with my code its not a zero array problem per se. lets explain: Its a rigid engine vibration program and it appears that the rotational responses are zero - ie the 'rotation variables are zero' and i am now looking at this - it is only working for one translation response e.g. Z direction...but the point is I have not knowingly changed any of the code, only re-compiled hence this problem now!

Couple of ideas:

1. Can you un-compile to get back to the original source of the one that does not work?

2. If so is there a way to compare codes side by side in an automated way without trawling through what is a very large programme.

colt1954

No you can't 'un-compile'.

Quoted from colt1954 Can you un-compile to get back to the original source of the one that does not work?

That would be a great question to ask the candidate in a job interview. If the candidate answers 'Yes', [s]he will enjoy many more such interviews.

he will enjoy many more such interviews.

[quote:4a773ac3b8="colt1954"]...is there a way to compare codes side by side in an automated way without trawling through what is a very large programme

Many text editors, including Plato, provide a file-comparison feature. There are also specialised utilities such as Beyond Compare, http://scootersoftware.com for comparing files.

Further to my previous posts regards problem with certain arrays returning unexpected zero’s this a simplified program cut and pasted from part of my program (below) it returns expected none zero’s for GENG(I,J) as I want!

Program Loop DIMENSION VEC(12) COMPLEX GENG(50,50),ENG(50,50) NPT=5 DO I=1,12 VEC(I)=I*0.5 ENDDO ENG(1,1)=(1,1) DO I=33,35 DO J=1,NPT GENG(I,J)=(0.0,0.0) DO K=1,3 GENG(I,J)=GENG(I,J)+ENG(1,1)*VEC((I-33)*3+K) print *, I,J,GENG(I,J),VEC((I-33)*3+K) ENDDO ENDDO ENDDO END

Here is the code from the program that returns zero values for GENG(I,J) array even though the VEC and GENG (3+K,J) arrays return values....bizarre, i include the VEC definition so could it be the double precision definition that’s screwing it up

!CALCULATE ACCELERATIONS

SUBROUTINE ACCL(NPT) COMPLEX GENG(58,721) DOUBLE PRECISION VEC(9) COMMON /REAL2/ COG(3),EM,SM(6) COMMON /COMP1/ GENG

Here is the almost exact routine as per the first listing except for the array

Double Precision VEC array definition difference.. I used this DP definition because another subroutine i adopted called for it. This gives zero for GENG(I,J) though GENG(3+K,J) and the VEC arrays return non zero believable values

!CALCULATE ANGULAR ACCELERATIONS

DO I=33,35 DO J=1,NPT GENG(I,J)=(0.0,0.0) DO K=1,3 GENG(I,J)=GENG(I,J)+GENG(3+K,J)*VEC((I-33)*3+K)

print *, I,J,GENG(I,J),GENG(3+K,J),VEC((I-33)*3+K) ENDDO ENDDO ENDDO

Colt1954,

You appear to be multiplying a single precision complex by a double precision real. Are you using 32 bit or 64 bit compiler? Reason for the question will be apparent in the following note to the folks at Silverfrost.

Paul,

Testing this, I found that multiplying a single precision complex by the double precision real produces incorrect results, for WIN32 (X64 is OK).

A simple example demonstrating the incorrect results is below. Mathematically the correct return value is 2.00 + j 2.00, but the return value with this code incorrect for Win32.

integer, parameter :: dp = kind(1.d0), sp = kind(1.0)
complex(kind=sp) a, z     
real(kind= dp) b     
a = cmplx(1.0,1.0)
b = 2.0
z = a*b
print*, 'a  ',   a
print*, 'b  ',   b
print*, 'a*b',   z
end

Multiplying a double precision complex by the single precision real produces the correct results.

The correct results are also obtained when the real and the complex number have the same precision (or kind number).

Rather perplexing. This looks like a compiler bug to me.

Ken

Quoted from Kenneth_Smith Colt1954,

You appear to be multiplying a single precision complex by a double precision real. Are you using 32 bit or 64 bit compiler? Reason for the question will be apparent in the following note to the folks at Silverfrost.

Paul,

Testing this, I found that multiplying a single precision complex by the double precision real produces incorrect results, for WIN32 (X64 is OK).

A simple example demonstrating the incorrect results is below. Mathematically the correct return value is 2.00 + j 2.00, but the return value with this code incorrect for Win32.

integer, parameter :: dp = kind(1.d0), sp = kind(1.0)
complex(kind=sp) a, z     
real(kind= dp) b     
a = cmplx(1.0,1.0)
b = 2.0
z = a*b
print*, 'a  ',   a
print*, 'b  ',   b
print*, 'a*b',   z
end

Multiplying a double precision complex by the single precision real produces the correct results.

The correct results are also obtained when the real and the complex number have the same precision (or kind number).

Rather perplexing. This looks like a compiler bug to me.

Ken

Ken this looks promising will check it out tomorrow how do I check 32 versus 64 bit compiler etc Also will Implicit none have any effect I since it appears in subroutines where VEC array gets used...?