> 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]
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|