The last issue I have left with pthreads is that 2 of our periodic boundary
condition tests are failing _periodically_ (pun! And also true...) when
running in threaded mode. 8 times out of 10 I can run them threaded and
they run fine - but those other 2 times they do this (in debug mode):
Assertion `this->contains_point(p)' failed.Assertion
`this->contains_point(p)' failed.
0] src/fe/fe_map.C, line 1188, compiled Jul 8 2013 at 13:13:47
WARNING: inverse_map of physical point (x,y,z)=(0.909091, 0,
0)is not on element.
Elem Information
id()=10, processor_id()=0
type()=QUAD4
dim()=2
n_nodes()=4
0 Node id()=20, processor_id()=0, Point=(x,y,z)=( 4.54545, 0,
0)
DoFs=(0/0/20)
1 Node id()=22, processor_id()=0, Point=(x,y,z)=( 5, 0,
0)
DoFs=(0/0/22)
2 Node id()=23, processor_id()=0, Point=(x,y,z)=( 4.77273, 0.393648,
0)
DoFs=(0/0/23)
3 Node id()=21, processor_id()=0, Point=(x,y,z)=( 4.31818, 0.393648,
0)
DoFs=(0/0/21)
n_sides()=4
neighbor(0)=NULL
neighbor(1)=NULL
neighbor(2)=21
neighbor(3)=9
hmin()=0.454545, hmax()=0.787296
volume()=0.178931
active()=1, ancestor()=0, subactive()=0, has_children()=0
parent()=NULL
level()=0, p_level()=0
refinement_flag()=DO_NOTHING
p_refinement_flag()=DO_NOTHING
DoFs=
Stack frames: 9
0: 0 libmesh_dbg.0.dylib 0x0000000101ef7d71
libMesh::print_trace(std::ostream&) + 49
1: 1 libmesh_dbg.0.dylib 0x00000001022c8645
libMesh::Elem::find_point_neighbors(libMesh::Point const&,
std::set<libMesh::Elem const*, std::less<libMesh::Elem const*>,
std::allocator<libMesh::Elem const*> >&) const + 149
2: 2 libmesh_dbg.0.dylib 0x000000010203583a (anonymous
namespace)::primary_boundary_point_neighbor(libMesh::Elem const*,
libMesh::Point const&, libMesh::BoundaryInfo const&, std::set<short,
std::less<short>, std::allocator<short> > const&) + 74
3: 3 libmesh_dbg.0.dylib 0x0000000102043d00
libMesh::FEGenericBase<double>::compute_periodic_constraints(libMesh::DofConstraints&,
libMesh::DofMap&, libMesh::PeriodicBoundaries const&, libMesh::MeshBase
const&, libMesh::PointLocatorBase const*, unsigned int, libMesh::Elem
const*) + 12608
4: 4 libmesh_dbg.0.dylib 0x000000010211f8bd
libMesh::FEInterface::compute_periodic_constraints(libMesh::DofConstraints&,
libMesh::DofMap&, libMesh::PeriodicBoundaries const&, libMesh::MeshBase
const&, libMesh::PointLocatorBase const*, unsigned int, libMesh::Elem
const*) + 77
5: 5 libmesh_dbg.0.dylib 0x0000000101eb5a80 (anonymous
namespace)::ComputeConstraints::operator()(libMesh::StoredRange<libMesh::MeshBase::const_element_iterator,
libMesh::Elem const*> const&) const + 720
6: 6 libmesh_dbg.0.dylib 0x0000000101eb5428 void*
libMesh::Threads::run_body<libMesh::StoredRange<libMesh::MeshBase::const_element_iterator,
libMesh::Elem const*>, (anonymous namespace)::ComputeConstraints>(void*) +
56
7: 7 libsystem_c.dylib 0x00007fff927968bf
_pthread_start + 335
8: 8 libsystem_c.dylib 0x00007fff92799b75 thread_start
+ 13
[0] src/geom/elem.C, line 545, compiled Jul 8 2013 at 13:13:54
terminate called after throwing an instance of 'libMesh::LogicError'
what(): Error in libMesh internal logic
It seems like there is something that still isn't thread safe in there.
Roy: Maybe you could take a look around there and see if anything rings a
bell. I'm betting that the reason we don't see this with TBB is that our
test is so small TBB isn't actually threading it... but with pthreads I
split the elements up no matter how many there are... so it is triggering
these two tests....
Other than that - with the hermite caching out of the way - the pthread
stuff is ready to be merged....
Derek
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
