[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How come it is PetscEvent but all the routines that act on it are PetscLogEventXXXX()?

Barry,

I like the the suggestion to change PetscLogEvent* to PetscEvent*, but to be consistent with naming then I think we would also need to change PetscLogStage* to PetscStage*, etc.

Just my 0.5 cents.

--Richard

Barry Smith wrote: 

On May 5, 2008, at 7:39 PM, Matthew Knepley wrote:

Actually, I would argue that these methods do not actually act on PetscEvent
at all (which is just an integer), but rather on a PetscLog. That is why I named
them that way.

The namage has to be consistent with any normal Joe's thinking about the usage,
not based on some implementation issue that only you know about. Names are for
users, not for the guru developers. Guru developers could name their variables and
functions a1 to a2303 and have no problem maintaining the code.

I think the macro names should be changed to PetscEventBegin.... not
PetscLogEventBegin.... based on the policy in PETSc that "methods" on "objects"
start with the name of the objects: e.g. MatMult(Mat,....) The user shouldn't know
or care that PetscEvent is an int and not a PetscEvent or PetscLogEvent object.

   Barry

We could instead change PetscEvent to PetscLogEvent but I think PetscEvent
is clear enough without the Log in it.




 Matt

On Sat, May 3, 2008 at 6:26 PM, Barry Smith <bsmith@xxxxxxxxxxx> wrote: 

  Doesn't seem right.

  Barry





--
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which
their experiments lead.
-- Norbert Wiener




--
Richard Tran Mills, Ph.D.            |   E-mail: rmills@xxxxxxxxxxxxxxxx
Computational Scientist              |   Phone:  (865) 241-3198
Computational Earth Sciences Group   |   Fax:    (865) 574-0405
Oak Ridge National Laboratory        |   http://climate.ornl.gov/~rmills