[petsc-dev] Registration implicitly collective on COMM_WORLD

[Barry Smith]

On Feb 5, 2013, at 7:28 AM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

> 
> On Mon, Feb 4, 2013 at 11:33 PM, Matthew Knepley <knepley at gmail.com> wrote:
> 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.
> 
> Okay, is this what you have in mind?
> 
> 1. XXInitializePackage() grows a comm argument
> 2. PetscFunctionListAdd() loses the comm argument

   Then we would need to remove the support for  [/path/libname[.so.1.0]:]functionname[()] where items in [] denote optional  from PetscFunctionListFind() so no more 

-ksp_type /Users/me/libmyksp.so:MyKSPCreate() 

Instead people would need to load the library in one collective call and then call the functionlistfind.

But I guess that is ok, no body uses this anyways.



> 3. XXCreate() stops calling XXInitializePackage() and instead just asserts XXPackageInitialized.
>