From: Kirk, Benjamin (JSC-EG311) <benjamin.kirk-1@na...> - 2009-12-05 01:22:18
We do this implictliy, I believe. We only initialize petsc if we initialize mpi, right? So if the user initializes petsc externally, mpi will be enabled and we will not initialize anything.
----- Original Message -----
From: Roy Stogner <roystgnr@...>
To: libmesh-users@... <libmesh-users@...>; libmesh-devel@... <libmesh-devel@...>
Sent: Fri Dec 04 13:59:46 2009
Subject: [Libmesh-users] Avoiding PETSc, SLEPc reinitialization
In the LibMeshInit constructor, we test MPI_Initialized() before
calling MPI_Init ourselves, so that if we're incorporated into a
larger MPI-using code we won't step on their toes.
We don't currently do the same for PETSc or SLEPc.
I'm going to wrap the PetscInitialize call in a similar
PetscInitialized test, so that we only initialize PETSc if nobody else
already has. This shouldn't break anyone's code, right?
I'm not sure what to do about SLEPc - there doesn't appear to be a
SlepcInitialized function. Is there some other way to test if
SlepcInitialize has been called? Is it safe to call SlepcInitialize
twice? Or do I need to pester slepc-maint with a feature request?
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
Libmesh-users mailing list
From: Roy Stogner <roystgnr@ic...> - 2009-12-09 18:04:44
On Fri, 4 Dec 2009, Kirk, Benjamin (JSC-EG311) wrote:
> We do this implictliy, I believe. We only initialize petsc if we
> initialize mpi, right? So if the user initializes petsc externally,
> mpi will be enabled and we will not initialize anything.
We only initialize PETSc if we're compiled with MPI, but we did
initialize PETSc ourselves regardless. That's good for the case where
we're called from a user code that initializes MPI regardless but
doesn't initialize PETSc (like QUESO, which first got me looking at
the problem), but we may get called from user codes that handle both.
Anyway, I've updated libmesh.C, and I think we're correct now. The
only obvious remaining bug is that LibMeshInit isn't thread-safe, but
if anyone wants to create two LibMeshInit objects in two different
threads then the obvious workaround is "don't do that!"