[petsc-dev] Options setup logic is broken

[Jed Brown]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20140330/6cd57cc4/attachment.sig>