Charm++ parallel programming system

[Jozsef Bakosi <jbakosi AT lanl.gov>]

On 10.27.2017 11:38, Jozsef Bakosi wrote:
> On 10.27.2017 11:02, Phil Miller wrote:
> >    We use an approach of creating bound 'shadow' arrays to act as
> >    independent reduction (sequencing) contexts to address this limitation.
> >    We've used this approach in a few places in our code, including the
> >    LiveViz in-situ visualization library and the collision detection
> >    library.
> >    In a little more detail, when constructing a chare array, it's possible
> >    to specify that it should be bound to another existing chare array.
> >    That means that elements of the same index will always live on the same
> >    PE. So, you can instantiate some auxiliary arrays, one per reduction
> >    stream, and bind them to your main computation arrays. Since elements
> >    with corresponding indices are guaranteed to be co-located, the main
> >    element can get a pointer to each auxiliary via a ckLocal() call, and
> >    then call aux->contribute(...) rather than implicitly
> >    this->contribute(). So, the setup code get a bit more complicated, and
> >    the code actually invoking the reductions get just a little more
> >    involved.
> >    Is that a clear description? Does that approach work for you?
> 
> I think that would work and I do use bound arrays for a different purpose.
> 
> So how would I have to use this? Here is what I think I need to do: I have 
> to
> identify all reductions that can happen in an order that is not necessarily
> guaranteed to be always the same and fire them from bound arrays instead 
> (each
> from a different chare array)?

Is there a way to tell which two reductions caused the "mis-matched client
callbacks in reduction messages" error? I do get a traceback from one, but 
can I
get one from the other one somehow so I know which reduction I have to 
initiate
from a shadow array?

Thanks,
J