[petsc-dev] The "type" field in PetscObject

[Barry Smith]

On Nov 26, 2010, at 12:32 PM, Jed Brown wrote:

> This seems to be equal to either 0 or -1 for every type in PETSc.  The comments for PetscHeaderCreate suggest that it no longer has any meaning, but we still have PetscCheckSameTypeAndComm.  What was the intent of this field?


     Originally types were ints; that field has hung around ever since then. It is not used and should be removed. Then replaced with something better.

>  Is it to have a faster way than strcmp to check whether two implementations match?

    Not currently. We have PetscClassId and class_name. We could also have PetscTypeId and type_name in the PetscObject struct. When XXXRegisterDynamic() is called it could create a new PetscTypeId for the string name. When an XXXSetType() is called it could determine the Id based on the string name of the type set in (how to do this efficiently, would it search through a list of strings?) I think we should think about this a bit before doing it. 

    For example, I don't like the fact that PetscClassIDRegister() is in the LOGGING stuff, since it is fundamental to PetscObject design and is not "only" logging.

> 
> I'm thinking about how to handle Vec operations of heterogeneous type which I don't think it is a short-term priority.

   I have some ideas on this that would not involve comparing types. But still needs lots of thought.

   Barry

> 
> Jed