Re: [Libmesh-devel] Failure on call to mesh.sub_point_locator()

On Wed, Mar 11, 2015 at 12:29 PM, Roy Stogner wrote: > > > On Wed, 11 Mar 2015, Roy Stogner wrote: > > My idea for a fix. After we do the cheap bounding box test: >> Let's also do a contains_point test? >> > > Gah. This is a stupid idea. Do a contains_point test *with what > point*? If we ju

[Libmesh-devel] Failure on call to mesh.sub_point_locator()

I've attached a test code that freezes on the call to mesh.sub_point_locator(). You can get the mesh from here (I figured the list would strip the mesh attachment). The mesh is pretty messy (I didn't make it!) but still this seems like a

Re: [Libmesh-devel] Failure on call to mesh.sub_point_locator()

On Wed, Mar 11, 2015 at 1:31 PM, Roy Stogner wrote: > > On Wed, 11 Mar 2015, David Knezevic wrote: > > Changing "200" to "250" in: >> >> if (!is_planar_xy) >> _tree = new Trees::OctTree (this->_mesh, 250, _build_type); >> >> works for me. Would you be happy with a "hacky" fix like that in the

Re: [Libmesh-devel] Failure on call to mesh.sub_point_locator()

On Wed, 11 Mar 2015, David Knezevic wrote: Changing "200" to "250" in: if (!is_planar_xy)   _tree = new Trees::OctTree (this->_mesh, 250, _build_type); works for me. Would you be happy with a "hacky" fix like that in the short term? Or would you prefer to keep the code as-is until we have a m

Re: [Libmesh-devel] Failure on call to mesh.sub_point_locator()

On Wed, Mar 11, 2015 at 1:20 PM, Roy Stogner wrote: > > On Wed, 11 Mar 2015, Roy Stogner wrote: > > On Wed, 11 Mar 2015, David Knezevic wrote: >> >> On Wed, Mar 11, 2015 at 12:29 PM, Roy Stogner >>> wrote: >>> >>> We need some kind of fully general intersection test for cartesian >>>

Re: [Libmesh-devel] Failure on call to mesh.sub_point_locator()

On Wed, 11 Mar 2015, Roy Stogner wrote: > On Wed, 11 Mar 2015, David Knezevic wrote: > >> On Wed, Mar 11, 2015 at 12:29 PM, Roy Stogner >> wrote: >> >> We need some kind of fully general intersection test for cartesian >> boxes with libMesh elements... > >> Hmm, OK. Do you have an i

Re: [Libmesh-devel] Failure on call to mesh.sub_point_locator()

On Wed, 11 Mar 2015, David Knezevic wrote: > On Wed, Mar 11, 2015 at 12:29 PM, Roy Stogner > wrote: > > We need some kind of fully general intersection test for cartesian > boxes with libMesh elements... > Hmm, OK. Do you have an idea about how to implement that? I'll be happy to

Re: [Libmesh-devel] Failure on call to mesh.sub_point_locator()

On Wed, 11 Mar 2015, Roy Stogner wrote: > My idea for a fix. After we do the cheap bounding box test: > Let's also do a contains_point test? Gah. This is a stupid idea. Do a contains_point test *with what point*? If we just test the bounding box corners then we'll have the converse of the b

Re: [Libmesh-devel] Failure on call to mesh.sub_point_locator()

On Wed, 11 Mar 2015, David Knezevic wrote: On Wed, Mar 11, 2015 at 11:34 AM, Roy Stogner wrote: On Wed, 11 Mar 2015, David Knezevic wrote: The issue seems to be in TreeNode::insert(). In particular, it seems that the call to this->refine(); inside  TreeNode::in

Re: [Libmesh-devel] Failure on call to mesh.sub_point_locator()

On Wed, Mar 11, 2015 at 11:34 AM, Roy Stogner wrote: > > On Wed, 11 Mar 2015, David Knezevic wrote: > > The issue seems to be in TreeNode::insert(). >> >> In particular, it seems that the call to this->refine(); >> inside TreeNode::insert is causing an infinite loop. >> > > Yeah, next time a lit

Re: [Libmesh-devel] Failure on call to mesh.sub_point_locator()

On Wed, 11 Mar 2015, David Knezevic wrote: The issue seems to be in TreeNode::insert(). In particular, it seems that the call to this->refine(); inside  TreeNode::insert is causing an infinite loop. Yeah, next time a little more warning. "This seems to hang" and "this is going to suck up 27

Re: [Libmesh-devel] Failure on call to mesh.sub_point_locator()

> > > On Wed, Mar 11, 2015 at 10:55 AM, Roy Stogner > wrote: > >> >> On Wed, 11 Mar 2015, David Knezevic wrote: >> >> Let me know if anyone else can reproduce this? >>> >> >> How many processors are you running on? SerialMesh or ParallelMesh? >> > One processor. SerialMesh. > > The issue seems

Re: [Libmesh-devel] Failure on call to mesh.sub_point_locator()

On Wed, 11 Mar 2015, David Knezevic wrote: > Let me know if anyone else can reproduce this? How many processors are you running on? SerialMesh or ParallelMesh? --- Roy -- Dive into the World of Parallel Programming The

Re: [Libmesh-devel] Failure on call to mesh.sub_point_locator()

One processor. SerialMesh. The issue seems to be in TreeNode::insert(). On Wed, Mar 11, 2015 at 10:55 AM, Roy Stogner wrote: > > On Wed, 11 Mar 2015, David Knezevic wrote: > > Let me know if anyone else can reproduce this? >> > > How many processors are you running on? SerialMesh or Paralle