Barry, I decided to use your PetscContainer solution and not change the API.
Thanks Stefano On Jul 23, 2016, at 12:58 PM, Barry Smith <[email protected]> wrote: > >> 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 > > > > > >> >
