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

PETSc.jl/src/mat.jl

Lines 191 to 195 in 73f12e0

	function destroy(nullspace::MatNullSpace{$PetscScalar})
	finalized($petsclib) ||
	@chk ccall((:MatNullSpaceDestroy, $libpetsc), PetscErrorCode, (Ptr{CMatNullSpace},), nullspace)
	return nothing
	end

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.