initialize and finalize and destroy

[jkozdon]

Do we ever see a use case where we might have something like:

PETSc.initialize(petsclib)
# ... work....
PETSc.finalize(petsclib)

# start PETSc again...
PETSc.initialize(petsclib)

I ask because this can cause problems with the garbage collector in when it's used. For instance, if the garbage collector is run on a PETSc object allocated in the first chunk of work AFTER petsc has been re-initialized this is an error since the actual PETSc object doesn't exist anymore. The destroy has a check for whether PETSc is finalized, but this will not catch PETSc having been re-initialized.

[boriskaus]

I see no reason why this would be done. In the testing we do this but with a finalize at the end

[psanan]

PETSc supports this. It is done sometimes in practice because someone uses PETSc within a larger code and wants to encapsulate as much as possible, so they initialize and finalize PETSc for each solve.

Is it already an issue without the second initialize()? You aren't allowed to destroy PETSc objects after you finalize PETSc.

[jkozdon]

Is it already an issue without the second initialize()? You aren't allowed to destroy PETSc objects after you finalize PETSc.

That is true, but we catch it with a check to see if PETSc is finalized https://github.com/JuliaParallel/PETSc.jl/blob/73f12e0a12764f2f06a44d4f93e1f4302e1efa91/src/mat.jl#L191-L195

OK. I have a few ideas for how to work around this, so will leave the issue open. Some smarter people than me may weigh in as well.