Anton,
I must not be quite following the pieces here. The procedure where “it makes no difference whether …”, should easily be passed around with an explicit interface, as it does not use coarrays.
To the extent I understand your concern, you have a _small_ number of procedures that must do different things depending on whether you are in case (1) or case (2). This would otherwise be a poster-child for object-orientation with two subclasses, but here the fact that both subclasses must have the same interface becomes an issue. Unfortunately, I lack enough experience with co-arrays to know if there is a way out of this. But others in the list surely have enough experience with the overlap to comment. (Damian?)
- Tom
> On Mar 7, 2018, at 1:36 PM, Anton Shterenlikht <[log in to unmask]> wrote:
>
>> It might be of value if you could hint at _why_
>> you want to be able to detect whether variable is in fact a coarray.
>
> I have a choice in domain decomposition - I can either
> 1) use coarrays only for halos, or
> 2) use the whole model as a coarray variable.
>
> Both options have merits.
>
> Option (1) reduces demands for the amount of symmetric memory,
> but requires an extra step in halo exchange (HX) - copy non-coarray
> edges into coarray halos, then remote ops.
>
> Option (2) makes it easier to do primitive single writer coarray IO
> (because all model data, not just halos, is available to any image)
> + halo exchange takes 1 step less, but on some systems (Cray) one
> has to know in advance how much symmetric memory to ask for.
>
> However, after HX, for local calculations on every image,
> it makes no difference whether the image data is a coarray
> or a non-coarray variable.
> So this makes it attractive to have a single routine doing local
> processing and accepting both coarray and non-coarray actual arguments.
>
> However, this does not work as soon as you want to pass such a
> procedure to another procedure, because this requires explicit
> interface.
>
> I just wrote a module assuming option 1.
> Now I want to extend it to allow for option 2 as well.
> But it seems I have to replicate nearly the whole module
> because I now pass a coarray variable between routines.
>
> I was thinking of some sort of resolution, a bit
> like a generic resolution, based on whether a passed
> variable is a coarray or not.
>
> Do I make any sense?
>
> Anton
|