On Fri, 4 Dec 2009, John Peterson wrote:
On Fri, Dec 4, 2009 at 1:59 PM, Roy Stogner <[email protected]> wrote: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?In the latest slepc (3.0.0-p7) there is an extern PetscTruth SlepcInitializeCalled; in include/slepc.h. Maybe we could check the value of that?
Sounds good. It looks like SlepcInitializeCalled was added in their r1409, which got it first into 2.3.3-p1, so I'll test SLEPC_VERSION_LESS_THAN(2,3,3) before using it. And thanks very much to Jed for reminding me about the problems of multiple finalizes; I'll add libmesh_initialized_petsc and libmesh_initialized_slepc variables for LibMeshInit to track. --- Roy
------------------------------------------------------------------------------ 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. http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
