> 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
> >
> >
> 
> 
> 

Reply via email to