Duplication of a list structure (with chain of pointers) from one coarray image to another.

[OP1]

I am wondering if there is any elegant solution to the following problem. How can one duplicate a list structure from one coarray image to another?

PROGRAM P
IMPLICIT NONE
TYPE T_NODE
    ! Some data.
    TYPE(T_NODE),POINTER :: NEXT => NULL()
END TYPE T_NODE
TYPE T_CONTAINER
    TYPE(T_NODE),POINTER :: ROOT => NULL()
END TYPE T_CONTAINER
TYPE(T_CONTAINER) :: C

IF (THIS_IMAGE()==2) THEN
    ! Initialize C with multiple linked nodes. Trivial.
END IF
SYNC ALL
IF (THIS_IMAGE()==1) THEN
    ! Create a copy of C[2] into local C. Not that trivial!
END IF
END PROGRAM P

[FortranFan]

If you have not done so already, you may want to post this query also on other forums, especially comp.lang.fortran and stackoverflow.com.

[OP1]

Thanks FortranFan - I may indeed do this to see what others can creatively come up.

Right now I have found two options. The first one is to have a loop with a bunch of SYNC ALL statements, where the remote image grabs the last node, put it in an other coarray, then the master image reads it - rinse and repeat. The other option is to have the slave image 'flatten' the list structure into a temporary coarray derived type variable with allocatable components (as many components as there are nodes) so that the master image can read it at once.

Both options are rather clumsy.

[Les_Neilson]

There is also a Google group specific to OpenCoarrys which may help

Les

[Michael_S_17]

Hi,

from my current experiences I'd say there is no elegant solution for Image-to-Image copying of nested objects. (I may be wrong with this). But that situation isn't uncommon in serial programming either, where a simple copy of a nested object results in a shallow copy (copy by reference). In serial programming we need to copy each nested part separately if we need a deep copy (copy by value). In parallel programming, since an image-to-image data transfer can't be a shallow copy (reference), we can't copy nested objects directly. Until recently I personally did focus on derived type coarrays with allocatable components to overcome that situation. But, since we can't allocate on a foreign image, the programming becomes rather cumbersome (but not impossible). Another drawback of derived type coarrays with allocatable components may be a loss of coarray efficiency, since they are non-symmetric. Now, I do focus on derived type coarrays with static array components. (This is currently suggested for OpenCoarrays since it does not support derived type coarrays with allocatable or pointer components yet). It wastes some PGAS memory because I make the static array components somewhat larger then required, but the programing now becomes very elegant. Also, since there is no need to care for allocations on foreign images, it gives more functionality to my coarrays because I can always and easily copy from and to any image desired. (As long as coarray correspondence is established). The waste of PGAS memory can be held in limits with the static array components kept rather small (or not overly large) in size. (Considering that the coarrays can be reused for further image-to-image data transfer if the data is getting larger than the static array component actually is). Further, for the image-to-image data transfer I do use only those parts of my static array components which do contain the data, in other words instead of the whole coarray use only a subobject of the coarray to avoid unnecessary large data transfer. I personally do implement my program logic in purely local memory (non-coarray variables) and do use coarrays only for the image-to-image data transfer and to set flags in PGAS memory (to avoid synchronizations).

best regards

michael

[jimdempseyatthecove]

What happens with the data on the recipient side of the copy after the copy?

a) is it used once and then discarded?
b) is it used multiple times without inserts or deletes?

If a) or b) then have the source allocate a coarray of the type (sans pointers), pack the array, then transfer in one sync. Note, you can also build the array, then use MPI to pass it to the controlling process (or anywhere you want).

However, if c) used with inserts or deletes, then

Allocate an array of the type (either part of the list size or all of the list size) and use MPI to pass the array to the other image (repete if necessary for entire list).

Passing linked list with links is not useful as the addresses will  not align up.

Note, if your source deals with the original data as allocated in an array, then establishes link pointer to reorganize the data, then change your type from using pointers to using indexes into the array. The array of this type is fully compatible with copying as rank of coarray. If you know the number of types (or can set an upper limit), then allocate an array of your types, and initialize the indexes to establish your free list of nodes.

Jim Dempsey

[Michael_S_17]

Regarding coarrays and nested objects see also Aleksandar Donev's 'Rationale for Co-Arrays in Fortran 2008' (N1702) paper, section 3.1.1, on page 6:

"...In effect, co-arrays are not hierarchically composable as are derived types (i.e., arrays of arrays). Co-arrays exist at the top level across all images. One can extend this view in future revisions but the gain is not obvious and the complications are great."

While this statement is made in the section of Co-Array Components (and the paper is somewhat dated now), I think this applies here.

Edit: Well, it does not really apply here, because it just says that coarrays can't contain coarray components.

best regards

Michael Siehl

[OP1]

Thanks for the responses - the solution I have implemented consists in having the slave image receive a 'signal' from the master image to flatten its local list structure into a array (itself a component of a coarray), which is in turn accessed by the master image when needed.

Regarding Michael's comments - yes it's possible to have coarrays based on derived types; actually it's a nice solution to manipulate data/arrays of different sizes, especially when the coarray images perform tasks that are quite different from each other.

Coarrays are an elegant solution for creating parallel code - the actual implementations in the currently available compilers are usually the limiting factor (bugs, features not implemented yet) right now. The Intel compiler is nearly there though, only a few kinks to iron out I think. If, as preliminary discussed by the Fortran standard committee, we get 'teams' and 'events', coarrays will become an even more powerful tool.