On Mon, Jun 4, 2012 at 8:22 AM, Kirk, Benjamin (JSC-EG311) <benjamin.kir...@nasa.gov> wrote: >>> OK, I'll see about making that change. But does this imply Metis runs >>> threaded by default and/or requires TLS to work correctly? >> >> I'll poke around - it is possible it is using OpenMP parallelism now, but if >> so then I would expect to have a __thread or similar function defined >> whenever OpenMP works. Perhaps there is a clash of compiler options or >> something... > > Sure enough: > > benkirk(18)$ grep pragma *.c > csr.c: #pragma omp parallel private(i, j, ncand, rsum, tsum, cand) > csr.c: #pragma omp for schedule(static) > csr.c: #pragma omp parallel private(i, j, ncand, rsum, tsum, cand) > csr.c: #pragma omp for schedule(static) > csr.c: #pragma omp parallel if (n > 100) > csr.c: #pragma omp single > csr.c: #pragma omp for schedule(static) > csr.c: #pragma omp parallel if (ptr[n] > OMPMINOPS) > csr.c: #pragma omp for private(j,sum) schedule(static) > csr.c: #pragma omp parallel if (ptr[n] > OMPMINOPS) > csr.c: #pragma omp for private(j,sum) schedule(static) > csr.c: #pragma omp parallel if (rowptr[nrows] > OMPMINOPS) > csr.c: #pragma omp for private(j, maxtf) schedule(static) > ... > > Looks like Metis is using OpenMP solely in the compressed row stroage > handling now. No equivalent directives in Parmetis.
I've attached a patch adding LIBMESH_TLS that gets libmesh to compile, but I now get a runtime error from one of the examples: Running: ./adaptivity_ex2-opt -read_solution -n_timesteps 25 -output_freq 10 -init_timestep 25 terminate called after throwing an instance of 'std::bad_cast' what(): std::bad_cast Here's the stack trace: 0: 0 libmesh.dylib 0x00000001006fdc1f libMesh::print_trace(std::ostream&) + 47 1: 1 libmesh.dylib 0x00000001006ed39b libMesh::libmesh_terminate_handler() + 955 2: 2 libstdc++.6.dylib 0x00007fff80f7cae1 _ZN10__cxxabiv111__terminateEPFvvE + 11 3: 3 libstdc++.6.dylib 0x00007fff80f7cb16 _ZN10__cxxabiv112__unexpectedEPFvvE + 0 4: 4 libstdc++.6.dylib 0x00007fff80f7cbfc _ZL23__gxx_exception_cleanup19_Unwind_Reason_CodeP17_Unwind_Exception + 0 5: 5 libstdc++.6.dylib 0x00007fff80f7be6e __cxa_call_terminate + 0 6: 6 libmesh.dylib 0x0000000100ae89f5 libMesh::Partitioner::set_node_processor_ids(libMesh::MeshBase&) + 4101 7: 7 libmesh.dylib 0x0000000100aa6fe5 libMesh::XdrIO::read(std::string const&) + 1397 8: 8 libmesh.dylib 0x0000000100a8d542 libMesh::UnstructuredMesh::read(std::string const&, libMesh::MeshData*, bool) + 4050 9: 9 adaptivity_ex2-opt 0x00000001000055e0 main + 1792 Probably not a coincidence that it dies in a call to the Partitioner? I'm compiling in DEBUG mode to get more information, but perhaps we should just revert r5654 (or move it to an unstable branch) if it didn't actually fix the problem of partitioning small meshes? -- John
0001-Adding-LIBMESH_TLS-in-Metis-where-appropriate.patch
Description: Binary data
------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
