From: aborel on
Thank you very much for all your responses.
I tried it out like Paul and Richard suggested and it worked. Thanks
Richard for your thorough answer.

By the way Point 2. of Richards answer is still an issue for me. I
would like to pass just allocatable arrays to my
subroutines which are collected in different modules (especially since
I do not think to understand pointers very well).

But this doesn't work. If I define my allocatable arrays as pointer

for example in the main program:
character(50), pointer, dimension(:) :: arr_data_res1

then I can pass them from the main program to the subroutines (in the
modules). I do not have yet a complete understanding of this
behaviour.
Maybe I will make an example and ask this in an other post.
I use CVF 6.6C.

Regards Alex


From: Richard Maine on
<aborel(a)pilatus-aircraft.com> wrote:

> ...I
> would like to pass just allocatable arrays to my
> subroutines
....
> But this doesn't work. If I define my allocatable arrays as pointer
>
> for example in the main program:
> character(50), pointer, dimension(:) :: arr_data_res1
>
> then I can pass them from the main program to the subroutines (in the
> modules). I do not have yet a complete understanding of this
> behaviour.
> Maybe I will make an example and ask this in an other post.
> I use CVF 6.6C.

A couple of things.

In order to have allocatable dummy arguments, you have to have a
compiler that supports the so-called allocatable TR (or f2003). Most of
the current compilers support the TR, but I suspect that the version you
are using is a bit old for that. In that case, yes, using pointer can be
a workaround.

However, note that you don't need the dummy argument to be allocatable
unless you are doing the allocation in the subroutine. Once the array is
allocated, you can pass it around as an "ordinary" array, with no need
to fuss with the corresponding dummy being allocatable in the
subroutine. It is only when you are allocating (or deallocating) that
the allocatable attribute matters.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
From: aborel on


Richard
I was just trying to write an example for a better understanding.


In the directory .\Modules (for more "cleaness"):

!
!
module defs
!
implicit none
!
character(2), allocatable, dimension(:,:) :: arr_data
!
! contains
!
end module defs
!
!


!
!
module subs
!
implicit none
contains
subroutine tst_arr_alloc(arr_data2)
!
integer :: m, n
character(2), allocatable, dimension(:,:) :: arr_data2
! character(2), pointer, dimension(:,:) :: arr_data2
!
write(unit=*, fmt="(///, a, /)") "Array: arr_data"
write(unit=* ,fmt="(8a4)") ((arr_data2(m,n), n=1,8), m=1,4)
write(unit=* ,fmt="(//)")
!
end subroutine tst_arr_alloc
!
end module subs
!
!

The main program:

!
!
program tst
use subs
use defs
!
implicit none
integer :: status
integer :: i, j
!
! character(2), allocatable, dimension(:,:) :: arr_data
! character(2), pointer, dimension(:,:) :: arr_data
!
i=4; j=8
allocate (arr_data(i,j))
arr_data = "qq"
!
call tst_arr_alloc(arr_data)
!
deallocate (arr_data)
!
end program tst
!
!

Compilation with the command:
df /exe:tst.exe /module:.\modules .\modules\subs.f90 .\modules
\defs.f90 .\tst.f90


The output is

...\Programs\Tst>tst.exe

Array: arr_data

qq qq qq qq qq qq qq qq
qq qq qq qq qq qq qq qq
qq qq qq qq qq qq qq qq
qq qq qq qq qq qq qq qq

...\Programs\Tst>


So it is how you say. I must have tried to allocate my arrays in the
subroutines
in the past, without understanding the error. I will study this
further.

Now I just wonder if my way of splitting my programs with the
subroutines in separate
modules (and also certain "definitions") is good programming practice
or if there are
counter-indications given by the standard or "professionals" common
practice.


Thank you again for your answer
Regards Alex
From: Richard Maine on
<aborel(a)pilatus-aircraft.com> wrote:
[eliding much that I find distracting]

> subroutine tst_arr_alloc(arr_data2)
....
> character(2), allocatable, dimension(:,:) :: arr_data2

There is no reason for you to have the allocatable in the above
declaration. That's the situation I mentioned. You are not allocating or
deallocating the array in this subroutine. Therefore, having the
alllocatable attribute does nothing useful. It may do harm in that it
won't work with older compilers.

Just because the actual argument is allocatable, that does *NOT* mean
that the dummy argument has to be.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
From: glen herrmannsfeldt on
Richard Maine wrote:

>Now I searched my books and this group for a description of how to
>initialize above derived type "init_mat_data" but the only way I can
>imagine would be

>do m=1,n_rows,1
> init_mat_data(m)%id = "xx"
> init_mat_data(m)%name = "xx"
> init_mat_data(m)%type = "xx"
> init_mat_data(m)%info1 = "xx"
> init_mat_data(m)%info2 = "xx"
> do j=1,25,1
> init_mat_data(m)%mat_data(j) = "xx"
> end do
>end do

Good or bad, PL/I allows structure assignment,
including assigning scalars to structures.

This could be done

init_mat_data='xx';

I don't believe Fortran, even 2008, has that.

-- glen