[petsc-dev] PetscOptionsBegin etc all use global variables

[Barry Smith]

On Nov 3, 2013, at 5:53 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

> Barry Smith <bsmith at mcs.anl.gov> writes:
>>   What are “internal functions” in PETSc?
> 
> I mean functions marked "Level: advanced".
> 
>>   Why not just grab the appropriate global indexed by the thread as
>>   needed instead of “passing it to the “internal functions”? That is
>>   why do some functions “grab the thread local object” while other
>>   functions "take the thread local object as an argument explicitly”?
> 
> I think that if we offer it, there will be times where it will be useful
> to have multiple configurations, perhaps provided in different files,
> that are not based on threads.  In that setting, we could instantiate
> multiple PetscOptions objects and pass them around, perhaps setting them
> explicitly on a given object "consult this database when looking for
> your options".  Of course defaults are important and we don't want to
> force the ordinary user to deal with that, thus we need a
> global/thread-local variable where objects can get their databases.

    I don’t see how you are going to manage making them optional but allowing them to be passed around (since C has no optional arguments). If we want that route then I think we need to bit the bullet and just attach a PetscOptions thing to a PetscObject and if it has one it uses it to look for options, otherwise it looks in the “global” one. I don’t see how some PETSc routines can take a PetscOptions argument and others don’t.

  Barry

> 
>>   It also seems that there are two distinct decisions that do not have to be made together
>> 
>> 1)  Keep all global state in a single global object, instead of one for stack, one for options, one for …
>> 
>> 2) Index global objects by thread.
>> 
>>    We can do 1 and 2, 2,  or 1 (1 by itself would not support threads) 
>> 
>>    But regardless it seems like a bit of refactoring, not one day of
>>    work that we could be confident would work well as a long term
>>    solution?
> 
> I agree.
> 
>>    Is there anything good we can tell our current user Ed who wants to do something now?
> 
> Can he serialize the configuration step across his threads?  Does ho
> need to dynamically reconfigure at any old time?