Is this the kind of thing you want? This works in HPF. You don't
want to say the subroutine is PURE in this case (nor do you need to,
since there is no FORALL involved any more).
module t_mod
type t
private
real, dimension(:), pointer :: x
end type t
contains
subroutine p (one_t, size)
type(t) :: one_t
integer, intent(in) :: size
allocate(one_t%x(size))
!
! etc. ...
!
end subroutine p
end module t_mod
program foo
use t_mod
type(t), dimension(100) :: ta
!hpf$ distribute(block) :: ta
!hpf$ independent
do i = 1, 100
!hpf$ on home (ta(i)), resident
call p (ta(i), i-1)
end do
end program foo
--Carl Offner
****************************************************************
Carl Offner
High Performance Fortran Compiler Development
Digital Equipment Corporation
129 Parker Street, PKO3-2/B12
Maynard, MA 01754-2198
USA
(978) 493-3051
[log in to unmask]
****************************************************************
>Date: Wed, 29 Apr 1998 19:06:52 +0200
>From: Thorsten Ohl <[log in to unmask]>
>Cc: [log in to unmask], [log in to unmask]
>
>> Well, there are some problems with this and I really don't know what
>> you are trying to parallelize.
>
>It's an adaptive Monte Carlo integration program. I split the volume
>into subvolumes which are sampled independently. The x in
>
> type t
> private
> real, dimension(:), pointer :: x
> end type t
>
>corresponds to an adaptive importance sampling grid and is in general
>more complicated than a simple real array. I want it to contain
>allocatable arrays, because the library should work for any
>(reasonable) number of dimensions and for any (reasonable)
>granularity.
>
>> 1. You can't call a pure subroutine inside a FORALL construct. You
>> can call a PURE *function*, however.
>
>*Blush*. You're right, I should have tried that with Fortran95 before
>posting. I seem to be falling into the old trap
>FORALL-is-just-an-independent-DO-loop over and over again :-(.
>
>> (And a PURE function can call a PURE subroutine.)
>
>Unfortunately, all dummy arguments of pure functions have to have
>intent(in) ...
>
>Anyway, in the context of HPF,
>
> !hpf$ independent
> do i = 1, 100
> call p (ta(i))
> end do
>
>is just fine with me.
>
>> Note that the way I have written this program [a deleted FORALL
>> example, -tho], the pointer field x is itself not mapped to more
>> than one processor. That is, all the elements of ta(i)%x(:) live on
>> one processor -- the one processor that owns ta(i).
>
>That's exactly what I want. However, I really want T to be an abstract
>data type, i.e. with PRIVATE components. Then your other example
>
>> !hpf$ independent
>> do j = 1, 100
>> do i = 1, 100
>> !hpf$ on home(ta(j)%x(i)), resident
>> call p (ta(j)%x(i))
>> end do
>> end do
>
>is not possible, even
>
> !hpf$ independent
> do i = 1, 100
> !hpf$ on home(ta(i)%x), resident
> call p (ta(i)%x)
> end do
>
>(if it makes any sense) is not allowed. Does
>
> !hpf$ independent
> do i = 1, 100
> !hpf$ on home(ta(i)), resident
> call p (ta(i))
> end do
>
>make any sense for an abstract type? For my application I need double
>indirection (allocatable arrays of allocatable arrays) inside the type.
>
>My problem is that I have this mental model that on the implementation
>level, a pointer is two things: the pointer itself and the data it
>points to. Fortran hides this complication from me (which is good),
>but if I want to know on which processor the data ends up, I am faced
>with this ambiguity, of whether the data is mapped to the same
>processor as the pointer or not.
>
>Cheers,
>-Thorsten
>
>--
>Thorsten Ohl, Physics Department, TU Darmstadt -- [log in to unmask]
>http://crunch.ikp.physik.tu-darmstadt.de/~ohl/ [<=== PGP public key here]
>
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|