(j3.2006) CO_BROADCAST vs. CO_REDUCE

[Bill Long]

On Sep 17, 2014, at 4:55 AM, John Reid <John.Reid at stfc.ac.uk> wrote:

> 
> 
> Tobias Burnus wrote:
>> Dear all,
>> 
>> looking at the current draft of the T18508, I wonder why CO_BROADCAST
>> accepts polymorphic arguments while CO_REDUCE doesn?t.

CO_BROADCAST does not have to worry about a piece of internal C library code trying to call an external function, which is problematic if the arguments to that function are polymorphic.  Since all the images in the team call CO_BROADCAST, and A on each image has the same dynamic type, each image locally has the type information needed.


>> 
>> I do not see a big difference between the two ? and implementation wise,
>> a polymorphic argument also causes only little extra implementation
>> work. By contrast, allocatable components (which can also be
>> polymorphic) cause me much more grief. And those seem to be permitted
>> for both.
> 
> Is it to allocatable coarray components that you object? For 
> CO_BROADCAST, we used to require SOURCE to be a coarray (see N1996). It 
> seems to me that we should not allow a type with a coarray component for 
> either CO_BROADCAST or CO_REDUCE.

Several cases here:

1) A is allocatable.  By the current wording, if A on SOURCE_IMAGE is not allocated, then A will end up deallocated on all the images.  If A is allocated, then A gets allocated on the other images.  If A is an array, then the allocation state on all the images is already handled, since the shape is required to be the same everywhere.  Once the allocation state of A is correct, it if is allocated, the values of A on SOURCE_IMAGE are copied into A on the other images.   I don?t think there is any material loss of functionality to require that A is allocatable on all images if it is allocatable on any image. 

2) A is a pointer.  In this case, it is reasonable to require that the pointer be associated on all the images of the team.   The value of the target of A on image SOURCE_IMAGE gets copied to the targets of A on all the other images. 

3) A is a coarray.  If A is also allocatable, then it is already the case that if it is allocated on image image, it will be allocated on all the images.  Just broadcast the values from SOURCE_IMAGE if A is allocated (or if it is not allocatable), and do nothing if A allocatable but is not allocated. 

4) A is a derived type with an allocatable component.

   4.1) The allocatable component is a coarray.  If the coarray component is allocated on any image of the team, it will be allocated with the same shape on all of the images. This is a simple copy if it is allocated, and a no-op if not.

  4.2) The allocatable component is not a coarray.  This is processed the same way as (1) above.  In this case, the component will be allocatable on all images, since that is specified as part of the type definition and the types on all the images have to match.

5) A is a derived type with a pointer component. If we are really using intrinsic assignment rules, and the pointer component on SOURCE_IMAGE is associated with a target, then the corresponding pointer components have undefined association status, since the target of the SOURCE_IMAGE pointer is on a different image.  If the pointer component on image SOURCE_IMAGE has an association status of disassociated or undefined, the corresponding pointer components on the other images are given that association status. 

6) A is of a derived type with neither allocatable nor pointer components, or an intrinsic type that is not allocatable or a pointer.  Copy away.  Since the value of A on SOURCE_IMAGE is required, it is assumed to be defined there.

 
I think that?s it.

Cheers,
Bill



> 
> John.
> 
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3

Bill Long                                                                       longb at cray.com
Fortran Technical Suport  &                                  voice:  651-605-9024
Bioinformatics Software Development                     fax:  651-605-9142
Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101