On Fri, 2008-01-25 at 11:14 -0600, Wolfgang Bangerth wrote: > > The issue is that PETSc does everything on a per-MPI-process basis and, to > > the best of my knowledge, does not use threads itself to implement e.g. its > > matvec. And threaded BLAS will only take you so far... So you could > > assemble the system matrix with threads on 16 cores in a node, but when > > PETSc solves the linear system I think it will only be using one core. > > Yes, the PETSc people need to do some work there as well. > > > > Wolfgang's petsc flag was new to me and I'm gonna look into it, although > > this is not promising: > > http://www-unix.mcs.anl.gov/petsc/petsc-2/miscellaneous/petscthreads.html > > That page has been there for at least 4 years. My reading is that all it > says is that you can't call PETSc functions from different threads at the > same time. I don't think they want to say that PETSc can't internally use > threads to do its computations (and this is what we want them to do of > course). > > I'm going to see if I can't figure out what the flag's name was. I believe > it was still internal, and may only exist on PETSc dev. > We tried using PETSc in an OpenMP program and yes, it is *not* thread safe. PETSc maintains state in some global variables :-(. Cheers magnus
-- Dr Magnus Hagdorn Research Geophysicist OHM Ltd The Technology Centre Claymore Drive Aberdeen Science and Energy Park Aberdeen, AB23 8GD www.OHMsurveys.com +44.870.4296581 ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Libmesh-users mailing list Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
