Hmmm,
petscda.h:EXTERN PetscErrorCode PETSCDM_DLLEXPORT
DMGetColoring(DM,ISColoringType,const MatType,ISColoring*);
petscda.h:EXTERN PetscErrorCode PETSCDM_DLLEXPORT DMGetMatrix(DM, const
MatType,Mat*);
petscda.h:EXTERN PetscErrorCode PETSCDM_DLLEXPORT
DMGetInterpolation(DM,DM,Mat*,Vec*);
petscda.h:EXTERN PetscErrorCode PETSCDM_DLLEXPORT
DMGetInterpolationScale(DM,DM,Mat,Vec*);
petscda.h:EXTERN PetscErrorCode PETSCDM_DLLEXPORT DMGetAggregates(DM,DM,Mat*);
should all of these be Create?
In my mind usually Get means get something intrinsic to the underlying
object (some property of it for example); Create means generate a new thing
that while it may be associated with the DA is not "owned" or "controlled" by
the DA.
Another way to organize is Create() implies you later Destroy() that
object, while for things you Get you do something else (like restore).
I'm inclined to change all of these ones to Create() since they are all
Destroyed()
Barry
On Aug 27, 2010, at 11:10 AM, Jed Brown wrote:
> On Fri, 27 Aug 2010 12:00:32 -0400, Kai Germaschewski <kai.germaschewski at
> unh.edu> wrote:
>> And it also requires some more memory management framework which would
>> call upon caches to expire long-unused objects when memory is running
>> low.
>
> How would you detect this? Note that further allocation may be done
> external to PETSc, and perhaps even in a separate process. We're not in
> a managed environment, we can't get a reliable "time to GC". If we
> could get that sort of signal, then I would be for such caching at all
> times, but I don't think we can, in which case I still think
> managed/pooled access versus owned creation needs to be explicitly
> different.
>
> Jed
