[petsc-dev] Registration implicitly collective on COMM_WORLD

[Jed Brown]

On Mon, Feb 4, 2013 at 11:10 PM, Matthew Knepley <knepley at gmail.com> wrote:

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

We still have --with-single-library=0 and I think it's good to keep
something like that working for low-memory environments. I would be willing
to have it called automatically for --with-single-library=1 and to require
the user to explicitly call XXInitializePackage(comm) when using split
libraries (instead of doing it automatically in XCreate, or only do it
automatically when the comm is COMM_WORLD, otherwise error), where XX can
be only the highest level package the user wants to interact with.


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

Yeah, the implementation is not especially simple so I'm happy to retract
this idea.

Does this withdrawing autoloads mean we should remove the third argument of
XXRegisterDynamic? Maybe autoloads should exist, but be registered
alongside a comm.


What do you think about having one registration implementation that would
use PetscClassId to index the PetscFunctionList? I think that could remove
a huge amount of copy/paste code.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130204/7107ccb3/attachment.html>