On Thu, 27 May 2010, Andrea Hawkins wrote: > I'm wondering though, does the inflow_ID and ouflow_ID correspond to > the same numbers as the edges of an element are numbered? i.e. 0 for > the bottom, 1 for the right side, 2 for the top, and 3 for the left > side?
The PeriodicBoundary ids are the same as the BoundaryInfo IDs. If you generated your domain with build_square, build_cube, etc. then I believe our convention is to use the same ordering as for a single element's sides. > I've tried the code above and get the following error: > > Assertion `!_b' failed. > [0] /h1/ahawkins/LIBRARIES/LIBMESH/libmesh-r3801/include/parallel/threads.h, > line 64, compiled Apr 29 2010 at 12:08:34 > terminate called after throwing an instance of 'libMesh::LogicError' > what(): Error in libMesh internal logic > > where the traceback is: > Stack frames: 10 > 0: print_trace(std::ostream&) > 1: _ZN7Threads11BoolAcquireC9ERb > 2: Threads::BoolAcquire::BoolAcquire(bool&) > 3: void Threads::parallel_reduce<StoredRange<MeshBase::const_node_iterator, > Node const*>, (anonymous > namespace)::FindBBox>(StoredRange<MeshBase::const_node_iterator, Node > const*> const&, (anonymous namespace)::FindBBox&) > 4: MeshTools::bounding_box(MeshBase const&) > 5: PointLocatorTree::init(Trees::BuildType) > 6: _ZN16PointLocatorTreeC9ERK8MeshBasePK16PointLocatorBase > 7: PointLocatorTree::PointLocatorTree(MeshBase const&, PointLocatorBase > const*) > 8: PointLocatorBase::build(MeshEnums::PointLocatorType, MeshBase > const&, PointLocatorBase const*) > 9: MeshBase::point_locator() const Damn; this is a bug whose correct fix I worked out but never found time to implement or test. Would you mind testing it for me? The fix should be in the SVN head (r3822) now. --- Roy ------------------------------------------------------------------------------ _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
