Fortran - Allocatable arrays inside a user defined type as an argument.

Author

Allocatable arrays inside a user defined type as an argument.

rucuti@comcast.net

2005-02-05, 8:58 pm

I just would like to know whether the previous combination is supported
by the extended f95 standard (and the new 2003 one) or not.

The reason is that I have some code which looks like
________________________________________
_______________________
module foo1
implicit none
type, public :: velocity
real(kind=8), dimension(:), allocatable :: u,v,w
end type velocity
end module foo1

module foo2
use foo1
implicit none
type(velocity), save :: vel
end module foo2

program foo3
use foo1
use foo2
implicit none
allocate(vel%u(0:999999),vel%v(0:999999)
,vel%w(0:999999))

vel%u = 0.0d0; vel%v = 1.0d0; vel%w = -1.0d0

call foo4
deallocate(vel%u, vel%v, vel%w)
end program foo3

subroutine foo4
use foo1
use foo2
implicit none
integer :: i

do i=0,999999
vel%u(i) = vel%u(i) + 1.0d0
vel%v(i) = vel%v(i) * 2.0d0
vel%w(i) = vel%w(i) - 4.0d0
end do
end subroutine foo4
________________________________________
__________

And the values of the three components of vel (vel%u, vel%v, vel%w)
become out of bounds inside foo4. Nevertheless, at first, the computed
values are right, yet they go wrong after a few calls to subroutines
like foo4.

However, it does not happen when I define all foo4-like subroutines
more verbosely
subroutine foo4(x,y,z)
implicit none
real(kind=8), dimension(0:999999) :: x,y,z
....

and make the call from foo3 with the three components of vel as an
explicit argument.

I have worked with ifort-8.1 and lahey-6.20c in a Linux box with
similar output.

Donald R. Fredkin

2005-02-06, 3:58 am

I believe that F95 does not permit allocatable arrays as components of a
derived type. You can achieve the same effect by using pointers to
arrays. So you want

type, public :: velocity
real(kind=8), dimension(:), pointer :: u,v,w
end type velocity

and then the rest of your example works flawlessly.

When I tried you code with the g95 compiler, it compiled but complained
at run time about the deallocate statement. When I added write statements
to check the values of the velocity components I found that they had
nonsense values. The pointer version was fine.

rucuti@comcast.net wrote in news:1107649334.452610.311330
@c13g2000cwb.googlegroups.com:

> I just would like to know whether the previous combination is supported
> by the extended f95 standard (and the new 2003 one) or not.
>
> The reason is that I have some code which looks like
> ________________________________________
_______________________
> module foo1
> implicit none
> type, public :: velocity
> real(kind=8), dimension(:), allocatable :: u,v,w
> end type velocity
> end module foo1
>
> module foo2
> use foo1
> implicit none
> type(velocity), save :: vel
> end module foo2
>
> program foo3
> use foo1
> use foo2
> implicit none
> allocate(vel%u(0:999999),vel%v(0:999999)
,vel%w(0:999999))
>
> vel%u = 0.0d0; vel%v = 1.0d0; vel%w = -1.0d0
>
> call foo4
> deallocate(vel%u, vel%v, vel%w)
> end program foo3
>
> subroutine foo4
> use foo1
> use foo2
> implicit none
> integer :: i
>
> do i=0,999999
> vel%u(i) = vel%u(i) + 1.0d0
> vel%v(i) = vel%v(i) * 2.0d0
> vel%w(i) = vel%w(i) - 4.0d0
> end do
> end subroutine foo4
> ________________________________________
__________
>
> And the values of the three components of vel (vel%u, vel%v, vel%w)
> become out of bounds inside foo4. Nevertheless, at first, the computed
> values are right, yet they go wrong after a few calls to subroutines
> like foo4.
>
> However, it does not happen when I define all foo4-like subroutines
> more verbosely
> subroutine foo4(x,y,z)
> implicit none
> real(kind=8), dimension(0:999999) :: x,y,z
> ...
>
> and make the call from foo3 with the three components of vel as an
> explicit argument.
>
> I have worked with ifort-8.1 and lahey-6.20c in a Linux box with
> similar output.
>
>

beliavsky@aol.com

2005-02-06, 3:58 am

Donald R. Fredkin wrote:
> I believe that F95 does not permit allocatable arrays as components
of a
> derived type.

Yes, but "the extended f95 standard (and the new 2003 one)" mentioned
by the OP do include TR 15581, which permits allocatable array
components -- see http://www.nag.co.uk/sc22wg5/TR15581.html . Several
Fortran 95 compilers implement TR 15581.

Michael Metcalf

2005-02-06, 8:57 am

<rucuti@comcast.net> wrote in message
news:1107649334.452610.311330@c13g2000cwb.googlegroups.com...
> I just would like to know whether the previous combination is supported
> by the extended f95 standard (and the new 2003 one) or not.
>

Yes (see "Fortran 90/95 Explained", Ch. 13). Your code runs as expected with
CVF 6.6.

Regards,

Mike Metcalf

rucuti@comcast.net

2005-02-07, 3:59 am

I am the original author, some further comments.

1) I had an out of bounds access in other part of the code which was
the real cause of my problems. The out of bound access concerned a
variable completely unrelated to the type(velocity) stuff.

2) While debugging, the variables inside foo4 have absurd bounds yet
everything gets done rightly, provided that 1) has been put right.

3) From 1) and 2) I have obtained a

conclusion: Fortran is not any
more the good guy free of C-like "pointer horrors" (I am speaking of
code compiled with no optimization and "-g"). The code works because
memory positions get written to, regardless of any concern about
boundaries (conversely, it failed because of the same reason).

Rich Townsend

2005-02-07, 3:59 am

rucuti@comcast.net wrote:
> I am the original author, some further comments.
>
> 1) I had an out of bounds access in other part of the code which was
> the real cause of my problems. The out of bound access concerned a
> variable completely unrelated to the type(velocity) stuff.
>
> 2) While debugging, the variables inside foo4 have absurd bounds yet
> everything gets done rightly, provided that 1) has been put right.
>
> 3) From 1) and 2) I have obtained a

conclusion: Fortran is not any
> more the good guy free of C-like "pointer horrors" (I am speaking of
> code compiled with no optimization and "-g"). The code works because
> memory positions get written to, regardless of any concern about
> boundaries (conversely, it failed because of the same reason).
>

-g doesn't enable bounds checking. So your criticism (3) is not
relevant. Try enabling bounds checking in the original code, and see
whether it is caught.

cheers,

Rich

rucuti@comcast.net

2005-02-07, 4:03 pm

In the f77 I was used to work, bound checking was the default without
compiler options and -g told you the line where the program was dying,
were there any out of bounds access.

Sponsored Links