[petsc-dev] Options setup logic is broken

[Barry Smith]

On Mar 30, 2014, at 8:43 PM, Jed Brown <jed at jedbrown.org> wrote:

> Matthew Knepley <knepley at gmail.com> writes:
> 
>> I have a PetscOptionsBegin/End() block. Inside, we create some contexts,
>> which
>> have PetscOptionsHead/Tail() blocks. This used to work fine, but I started
>> getting
>> a bizarre error.
>> 
>> It turned out that the part of the function after OptionsTail() had not
>> run. This was
>> because the PetscOptionsPublishCount was > 1. This happened because I had
>> moved the creation of a PetscObject inside the Begin/End block. This was the
>> first object created, so a ThreadComm communicator was created. This called
>> PetscThreadCommSetNThreads(), which called its own OptionsBegin/End block
>> which screwed up mine.
> 
> I've been bit by this lack of nesting on a few occasions.  The solution
> we discussed is to make it safe to nest.
> 
> I am not sure that the current implicit nature of ThreadComm is a good
> idea.  The way threadcomm interacts with the system is very different
> From all the normal PetscObjects, so it may make sense to handle it
> differently.\

   Paul will be starting in a month so start thinking about how you what threadcomm redesigned.

  Barry