[petsc-dev] sor smoothers

[Jed Brown]

Barry Smith <bsmith at mcs.anl.gov> writes:

>> An alternative would be to add a scalar parameter to MatMultAdd.
>
>    MatResidual() is an important enough case to merit its own
>    method. The odd ball scalar parameter that is not 1 or -1 is so
>    extremely rare as to lead to confusion instead of useful
>    generality.

Fine, but implementations might want to unify the add and subtract
kernels because it's half the code.

>> Perhaps PetscObjects should get a 64-bit unique ID assigned by a global
>
>    Why 64 bit? Surely we will never have more than 2 billion objects created?

It's not the number of objects in scope, but the cumulative number of
objects.  Some simulations take billions of time steps.  You might say
they should ensure that everything is reused over that period, but it's
hard to guarantee and this failure mode is just not worth allowing into
the realm of possibility.  If it were up to me, I would also make the
State integer 64-bit.  (You don't want to hand a Vec off to a stochastic
optimizer that does a million forward and adjoint simulations, each with
1000 time steps, and have a possibility of reusing some stale cache
once you get the solution vector back.)

>> counter, or even a slightly longer hash of information that should never
>> repeat.  Caching the pointer leaves the ABA problem.
>
>   We currently have 
>   h->id                    = idcnt++;
>   in PetscHeaderCreate_Private(). 
>
>    The id is not consistent across processes for a given object but I
>    don't think that matters. Why can't we just stash this value? I
>    think this value plus the Vec/Mat state uniquely define the values
>    in the Vec/Mat.

I forgot about that, but I think we should make it 64-bit.

> There is a possibility of some processes having the same state and
> others different ones and thus errors due to different functions being
> used; for example if one process called VecGetArrayWrite() but another
> one didn't. This is perverse so ….?

VecGetArray is documented to be logically collective.  There are some,
ahem, C++ libraries downstream that are dedicated to abusing the
interface with unstructured operator overloading.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130908/7db5f682/attachment.sig>