On Thu, 8 Jul 2010 13:12:03 -0700, Barry Smith wrote:
>
> I will use Not Collective, Logically Collective, Neighbor-wise Collective
> and Collective
There are many places now where "Collective on X" appears in the
documentation, but there are actually further constraints about
communicators m
I have added #define PetscValidLogicalCollectiveScalar(a,b),
PetscValidLogicalCollectiveReal(a,b), PetscValidLogicalCollectiveInt(a,b)
More can be added and then they could be used where ever appropriate. Meant
to do this for years but never got around to it.
Barry
On Jul 8, 2010, a
I will use Not Collective, Logically Collective, Neighbor-wise Collective and
Collective
Barry
On Jul 8, 2010, at 1:12 AM, Matthew Knepley wrote:
> On Thu, Jul 8, 2010 at 2:11 AM, Barry Smith wrote:
>
> Ok, we need a clear well-defined set of terms for type of function call
> then.
>
On Thu, Jul 8, 2010 at 2:11 AM, Barry Smith wrote:
>
> Ok, we need a clear well-defined set of terms for type of function call
> then.
>
> 1) Any process can call it, without regard to other processes calling it,
> with any legal value. MatGetLocalSize()
>
Yep, Not Collective here.
> 2)
Ok, we need a clear well-defined set of terms for type of function call then.
1) Any process can call it, without regard to other processes calling it,
with any legal value. MatGetLocalSize()
2) All processes must call it with the same legal value for the operation to
make mathematical s
This is a different definition of collective I think. I thought we were
defining collective in the
operational sense, meaning requires synchronization. That is what users need
to know, since
they will not check the implementation. I believe users know the semantics
up front (why would
semantics cha
I consider that VecScale() has to be considered a collective that requires
all processors to pass the same value for the scalar in the same way that
VecAXPY() is a collective operation that requires the same value for alpha. The
reason is that though you can pass in different values on differ
