Add a glance adding all these new complications to PETSc to chase an impossible overlap of communication and computation sounds fine :-) Barry Just nice clean uncomplicated code please :-) On Mar 18, 2012, at 11:29 AM, Jed Brown wrote:
On Sun, Mar 18, 2012 at 11:24, Matthew Knepley <[email protected]> wrote: This sounds fine to me. I think the acid test is to rewrite Bill's new CG in it.
Someone at ICERM knew the reference for that, right?
I do not understand this. What call creates the PetscSplitReduction struct?
PetscSplitReductionGet(MPI_Comm) gets it out of the attribute cache on the comm, creating it if it doesn't exist yet.
Is it the Begins? So after Begin, it is present in the Vec and the Comm.
Currently only in the Comm, and it's always accessed the same way.
Then when you call PetscCommSplitReductionBegin, it leaves the comm, and resides only in the Vec along with a Request. Then the End destroys it? So it lives in the Comm for aggregation purposes? That sounds fine to me.
Right, I want it to still live in the comm for aggregation purposes, but have a reference count and have the link from the comm dropped when the reduction starts.