[petsc-dev] Registration implicitly collective on COMM_WORLD

Jed Brown jedbrown at mcs.anl.gov
Mon Feb 4 23:08:21 CST 2013


On Mon, Feb 4, 2013 at 11:01 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:

>    Now we need to make several more decisions.
>
> 1) are PETSc package registrations collective? sys, vec, mat, dm, ksp,
> snes, ts
>      currently as Jed noted they are not except with dynamic loading of
> PETSc libs
>
> 2) are all PETSc packages registered upfront during PetscInitialize()?
>     currently only with dynamic loading of petsc libs
>

I don't like the reverse dependency that this implies.


> 2a) If all PETSc packages are registered up front what is the mechanism to
> turn off registering some? Thought Matt disagrees there is always some
> asshole who says, I don't use TS so I don't want it registered.
>

Can we make XXInitializePackage() collective on an explicit comm _and_ safe
to call on a communicator for which some ranks are already initialized?

I think this would make it possible to provide a deadlock-safe
implementation. A user should explicit call XXInitializePackage(comm) if
they ever encounterd IO performance issues (due to collective loads on many
small comms).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130204/46c0479c/attachment.html>


More information about the petsc-dev mailing list