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.
-Ben ----- Original Message ----- From: Roy Stogner <[email protected]> To: [email protected] <[email protected]>; [email protected] <[email protected]> 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? --- 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 ------------------------------------------------------------------------------ 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
