Found it!!! So, I did specify "PETSc" as the source of metis during compilation of libmesh (as I have been doing successfully for a while on my mac). However, for some reason, the compile options included the libmesh/contrib/metis and libmesh/contrib/parmetis as search paths.
As a result, the compiler was using metis.h from libmesh/contrib, but using libmetis.so and libparmetis.so library from petsc. The libmesh/contrib has a real width of 32, and uses "float" as scalar in parmetis_partitioner, while the petsc metis library was build with real width type of 64. I do not know why contrib stuff is still being used, but this mismatch was causing the error. On Fri, Mar 13, 2015 at 6:24 AM, Paul T. Bauman <[email protected]> wrote: > On Fri, Mar 13, 2015 at 12:52 AM, Manav Bhatia <[email protected]> > wrote: > >> Parmetis is quitting on me with segmentation faults. The code works >> just fine on other machines (both mac and some big intel based clusters). >> Before I spend more time debugging it, I wanted to get a quick check from >> others if they have had issues if parmetis. >> > > Make sure you use the configure option --with-metis=PETSc > > The libMesh and PETSc ParMetis installations can (and often do) collide > and that option will tell libMesh to use PETSc's. > ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
