[petsc-dev] Registration implicitly collective on COMM_WORLD

[Matthew Knepley]

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

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

I see nothing wrong with those tradeoffs, its just beginning to sound
complicated to me (like the Fortran stuff I can never remember).
I would say, if you split the libraries, you have to do everything
manually, and we just error out if you don't. That is easy to remember,
and I think its harder for a user to have a working code that breaks
mysteriously when one thing changes, like the comm.


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

I think this sounds workable.

   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/3f1f1593/attachment.html>