On Jun 21, 2015, at 9:33 AM, Dave May <[email protected]> wrote:

Hi Barry,

Likely Matt had a few more beers between writing the first one and the second one.

Heh - thanks for providing the patch to make both functions behave in the same manner.

...

My use case is that within one of my custom preconditioners, I wanted to call PetscLogStageRegister() during the creation phase, but obviously I can only register the stage once. To enable multiple instances of the preconditioner to exist, I need to ensure that the stage is only registered once. Hence I would like to check for the existence of the stage prior to calling the register function.

Is there currently a way to check for the existence of a registered stage?

No, we don't recommend doing it this way. The way we do it in PETSc is to have a static global variable that contains the stage ID and simply check the value of that id to determine if it has been set (set it to -1 at compile time) so your test can then just be that it is not -1. The stage register stuff goes through string comparisons so it should not be called a bunch of times.

Okay, thanks for the advice on how best to do this. I did notice that typical usage in petsc was via a static global variable, but as a general rule, I try to not introduce global variables into my code base.

Good policy

Is the string comparison for an event/stage name really that bad a thing to do? I mean, can it be worse than processing the enormous list of command line arguments every time XXXSetFromOptions() is called?

The intention is that XXXSetFromOptions() should never be within the inner iterations, so for example, once TSSetFromOptions() is called the intention is that TSSolve() -> SNESSolve() -> KSPSolve() -> PCApply() should not pass through any XXXSetFromOptions(). Yes this is violated in places but over time we hope to organize our libraries so they remain simple but do not violate this rule. Barry

Cheers, Dave

Barry

...

Cheers Dave