On Jul 23, 2016, at 2:36 PM, Stefano Zampini <[email protected]> wrote:
I’m interfacing a FEM library with PETSc.
They already use Hypre and so they have a valid distributed CSR format (except for the diagonal entry of the diagonal block :-))
For efficiency reasons, I was thinking of using MatCreateMPIAIJWithSplitArrays and MatCreateSeqAIJWithArrays; However, If using these functions as they are now I will need to keep track of the allocated arrays, even with referencing objects, and this could be annoying and cumbersome.
A trivial fix would be to add an extra PetscCopyMode parameter to these routines, so that PETSc can take ownership of the arrays. Thoughts? Any objection?
Sounds reasonable except that PETSc uses PetscFree() which may not be a direct call to free() so that if the user used malloc() to obtain the space (which is more likely than PetscMalloc()) bad stuff will happen. One could introduce PETSC_OWN_RAWPOINTER which tells PETSc it should free the space with a regular free() instead of PetscFree() but then code get's more complicated since you'll need to keep a flag indicating this and call the appropriate free() based on it. Of course if you have control over the FEM library source you could change it to use PetscMalloc() to obtain the pointers. An alternative is for you to create a PetscContainer for each array pointer, provide a PetscContainerSetUserDestroy() that calls free on the pointer and then use PetscObjectCompose() to attach the containers to the matrix, now call PetscContainerDestroy() on all the containers. When the matrix is destroyed it will go through all the composed objects destroying each of them which will free up your space. No need to change PETSc source or APIs. Barry