forums.silverfrost.com

[aerotex]

I am having a problem getting array elements assigned. I am first trying to set all array elements to zero. The relevant code is:

SUBROUTINE SOLVER(N_COMPS,MAX_PANS,ALPHA,U,N_OUTER,
& VECT_POINTS_PERP,PANEL_VECTA,DIST_POINTS,A,V_PERP,VTAN,
& GAMMA,N_PTS,TOT_PTS)
!
IMPLICIT NONE
!
INTEGER :: I, J
INTEGER, INTENT(IN) :: N_COMPS,MAX_PANS, TOT_PTS

REAL*8 :: A(N_COMPS*(MAX_PANS+1),TOT_PTS-N_COMPS)

REAL*8 :: U_NORM((MAX_PANS*3)+N_COMPS)
!
! Initialise arrays
DO I = 1, N_COMPS*(MAX_PANS+1)
DO J = 1, TOT_PTS-N_COMPS
A(I,J) = 0.0
ENDDO
ENDDO

DO I = 1, (MAX_PANS*3)+N_COMPS
U_NORM(I) = 0.0
ENDDO

When I use Checkmate to debug the code, the 'A' array has all elements set to 0.0 correctly, but the 'U_NORM' array has a random assortment of: 0.0, 'Invalid floating point number', 'Undefined', or a very small number (e.g. 2.9e-291).

I cannot see why this is occurring. Can anyone shed any light?

[IanLambley]

First if you are setting whole arrays to zero, or any other single value, then you can simply use

A=0
U_norm=0

Secondly, try putting =0d0 to force use of a real*8 zero, especially as you have used IMPLICIT NONE

Regards

Ian

[aerotex]

Thanks for the tip in setting a whole array to a single value (although I was only using that as an example - I get the same results when actually trying to set the array elements to calculated values further down in the code).

I have tried using =0d0, but it makes no difference at all.

I have just tried compiling and debugging on an old compiler I have (which I cannot use commerically), and it sets all values to 0.0 as I thought it should, which suggests that the code is fine. I have also tried debugging on a 32 bit system rather than my standard 64 bit system, but again it does not make any difference at all, and I'm getting increasingly frustrated!

[PaulLaidler]

This code works OK for me but I have had to use my own input values.

The arrays A and U_NORM have sizes that require a back-handed calculation to get the sizes of the input arrays and this is probably where things are going wrong. The size (i.e. shape) of the two dimensional array A must match in the main program and the subroutine (strictly the first dimension only for a 2-D array).

The alternative is to use Fortran 90 assumed shape arrays.

[JohnCampbell]

You are asking for a lot of problems when defining the array dimension as you have. It may be legal fortran 90+, although I don't expect it is.
Why use such a messy coding technique ?

REAL*8 :: A(N_COMPS*(MAX_PANS+1),TOT_PTS-N_COMPS)
REAL*8 :: U_NORM((MAX_PANS*3)+N_COMPS)

My solution would be to transfer the dimensions in the argument list (fortran 77) or use implied array sizes, as Paul has suggested.
If, as I suspect, the array A is not dimensioned as you imply in the calling routine, then calculate the dimensions before you call.

In the calling routine:-
na1 = N_COMPS*(MAX_PANS+1)
na2 = TOT_PTS-N_COMPS ! never negative ?
nu = (MAX_PANS*3)+N_COMPS
!
call SOLVER (N_COMPS, MAX_PANS, ALPHA, U, N_OUTER,
& VECT_POINTS_PERP, PANEL_VECTA, DIST_POINTS, A, V_PERP, VTAN,
& GAMMA, N_PTS, TOT_PTS, na1, na2, nu)


In the routine SOLVER, use

REAL*8 A(na1,na2) ! dummy argument
REAL*8 U_NORM(nu) ! local automatic array ?

! zero with
A = 0
U_NORM = 0

should all work with all 90+ compilers.

You have checked any of the dimensions are -ve ?
I'm sure that the array dimensions are of use elsewhere in the routines.