[petsc-dev] Registration implicitly collective on COMM_WORLD

[Matthew Knepley]

On Tue, Feb 5, 2013 at 12:08 AM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

>
> 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.
>

This is not a real argument against, but I don't think this is the only
place we have this dependency.
For example, even with dynamic loading, we have a list of libraries to load
up front. I don't think this
is any different.


>  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).
>

This sounds really fragile to me, since all the logging stuff relies on it
and it collective.

   Matt

-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130205/8a2dbbd4/attachment.html>