[petsc-dev] Registration implicitly collective on COMM_WORLD

[Sean Farley]

On Tue, Feb 5, 2013 at 8:05 AM, Barry Smith <bsmith at mcs.anl.gov> wrote:
>
> 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.

That would mean we could free up the use of ":[]" for other command
line options, right?