Matthew Knepley <[email protected]> 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.