[petsc-dev] Behaviour of PetscLogEventGetId() and PetscLogStageGetId()
Dave May
dave.mayhem23 at gmail.com
Sun Jun 21 09:33:13 CDT 2015
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.
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?
Cheers,
Dave
> Barry
>
>
> >
> >
> > Cheers
> > Dave
> >
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20150621/438b528b/attachment.html>
More information about the petsc-dev
mailing list