From: Tim Kroeger <tim.kroeger@ce...>  20091029 14:28:35

Dear all, Is there any easy way to loop over all elems that are neighbors of a given elem accross either a face or an edge? As fas as I understand, Elem::neighbor() only cares about neighbors accross faces. On the other hand, Elem::find_point_neighbors() does too much. I think, it should be easy to implement a method Elem::find_edge_neighbors() analogously to Elem::find_point_neighbors(), where just each call to Elem::contains_vertex_of() is replaced with a call to Elem::contains_edge_of(), the latter is implemented analogously to Elem::contains_vertex_of() with the only difference that for returning true, it requires at least *two* vertices of the one element contained to be contained in the other. What do you guys think? If you agree that this would be correct, I'd be happy to do this (easy and straightforward) task. Best Regards, Tim  Dr. Tim Kroeger tim.kroeger@... Phone +494212187710 tim.kroeger@... Fax +494212184236 Fraunhofer MEVIS, Institute for Medical Image Computing Universitaetsallee 29, 28359 Bremen, Germany 
From: Tim Kroeger <tim.kroeger@ce...>  20091029 14:28:35

Dear all, Is there any easy way to loop over all elems that are neighbors of a given elem accross either a face or an edge? As fas as I understand, Elem::neighbor() only cares about neighbors accross faces. On the other hand, Elem::find_point_neighbors() does too much. I think, it should be easy to implement a method Elem::find_edge_neighbors() analogously to Elem::find_point_neighbors(), where just each call to Elem::contains_vertex_of() is replaced with a call to Elem::contains_edge_of(), the latter is implemented analogously to Elem::contains_vertex_of() with the only difference that for returning true, it requires at least *two* vertices of the one element contained to be contained in the other. What do you guys think? If you agree that this would be correct, I'd be happy to do this (easy and straightforward) task. Best Regards, Tim  Dr. Tim Kroeger tim.kroeger@... Phone +494212187710 tim.kroeger@... Fax +494212184236 Fraunhofer MEVIS, Institute for Medical Image Computing Universitaetsallee 29, 28359 Bremen, Germany 
From: Roy Stogner <roystgnr@ic...>  20091029 14:53:30

On Thu, 29 Oct 2009, Tim Kroeger wrote: > > Is there any easy way to loop over all elems that are neighbors of a > given elem accross either a face or an edge? As fas as I understand, > Elem::neighbor() only cares about neighbors accross faces. On the > other hand, Elem::find_point_neighbors() does too much. I think, it > should be easy to implement a method Elem::find_edge_neighbors() > analogously to Elem::find_point_neighbors(), where just each call to > Elem::contains_vertex_of() is replaced with a call to > Elem::contains_edge_of(), the latter is implemented analogously to > Elem::contains_vertex_of() with the only difference that for returning > true, it requires at least *two* vertices of the one element contained > to be contained in the other. What do you guys think? If you agree > that this would be correct, I'd be happy to do this (easy and > straightforward) task. Sounds good... Something that needs thought, though: there's a limitation in find_point_neighbors() which will become a more significant limitation in find_edge_neighbors(): behavior on adaptive meshes. With find_point_neighbors, an elem can share a point with its neighbor without sharing any nodes with its neighbor, for some firstorder elements two levels apart or some secondorder elements three levels apart. This is only a minor problem for our patch recovery estimator, which doesn't quite grow patches in the most optimal way, so I never worried about it. With find_edge_neighbors, an elem can share part of an edge with its neighbor without sharing a pair of nodes with its neighbor, this time for any firstorder elements one level apart or any secondorder elements two levels apart. I don't know what you'd be using find_edge_neighbors for, though, so I don't know if this is a problem.  Roy 
From: Tim Kroeger <tim.kroeger@ce...>  20091029 15:02:40

On Thu, 29 Oct 2009, Roy Stogner wrote: > On Thu, 29 Oct 2009, Tim Kroeger wrote: >> >> Is there any easy way to loop over all elems that are neighbors of a >> given elem accross either a face or an edge? As fas as I understand, >> Elem::neighbor() only cares about neighbors accross faces. On the >> other hand, Elem::find_point_neighbors() does too much. I think, it >> should be easy to implement a method Elem::find_edge_neighbors() >> analogously to Elem::find_point_neighbors(), where just each call to >> Elem::contains_vertex_of() is replaced with a call to >> Elem::contains_edge_of(), the latter is implemented analogously to >> Elem::contains_vertex_of() with the only difference that for returning >> true, it requires at least *two* vertices of the one element contained >> to be contained in the other. What do you guys think? If you agree >> that this would be correct, I'd be happy to do this (easy and >> straightforward) task. > > Sounds good... > > Something that needs thought, though: there's a limitation in > find_point_neighbors() which will become a more significant limitation > in find_edge_neighbors(): behavior on adaptive meshes. > > With find_point_neighbors, an elem can share a point with its neighbor > without sharing any nodes with its neighbor, for some firstorder elements > two levels apart or some secondorder elements three levels apart. > This is only a minor problem for our patch recovery estimator, which > doesn't quite grow patches in the most optimal way, so I never worried > about it. Hmm... There seems to be some misunderstanding either on my side or on yours. To check whether two elems (say, A and B) have a common point, Elem::find_point_neighbors calls A.contains_point(nB) for all nodes nB of B and B.contains_point(nA) for all nodes nA of A. The method Elem::contains_point(), however, does *not* check whether the given point is a node of the respective element; rather it uses an inverse map to check whether the point is contained in the element. Hence, if I understand correctly what you mean, these cases are caught correctly (and would be by Elem::find_edge_neighbors() the same way). Or did you mean something different? Best Regards, Tim  Dr. Tim Kroeger tim.kroeger@... Phone +494212187710 tim.kroeger@... Fax +494212184236 Fraunhofer MEVIS, Institute for Medical Image Computing Universitaetsallee 29, 28359 Bremen, Germany 
From: Roy Stogner <roystgnr@ic...>  20091029 15:08:51

On Thu, 29 Oct 2009, Tim Kroeger wrote: > On Thu, 29 Oct 2009, Roy Stogner wrote: > >> On Thu, 29 Oct 2009, Tim Kroeger wrote: >>> >>> Is there any easy way to loop over all elems that are neighbors of a >>> given elem accross either a face or an edge? As fas as I understand, >>> Elem::neighbor() only cares about neighbors accross faces. On the >>> other hand, Elem::find_point_neighbors() does too much. I think, it >>> should be easy to implement a method Elem::find_edge_neighbors() >>> analogously to Elem::find_point_neighbors(), where just each call to >>> Elem::contains_vertex_of() is replaced with a call to >>> Elem::contains_edge_of(), the latter is implemented analogously to >>> Elem::contains_vertex_of() with the only difference that for returning >>> true, it requires at least *two* vertices of the one element contained >>> to be contained in the other. What do you guys think? If you agree >>> that this would be correct, I'd be happy to do this (easy and >>> straightforward) task. >> >> Sounds good... >> >> Something that needs thought, though: there's a limitation in >> find_point_neighbors() which will become a more significant limitation >> in find_edge_neighbors(): behavior on adaptive meshes. >> >> With find_point_neighbors, an elem can share a point with its neighbor >> without sharing any nodes with its neighbor, for some firstorder elements >> two levels apart or some secondorder elements three levels apart. >> This is only a minor problem for our patch recovery estimator, which >> doesn't quite grow patches in the most optimal way, so I never worried >> about it. > > Hmm... There seems to be some misunderstanding either on my side or on yours. > To check whether two elems (say, A and B) have a common point, > Elem::find_point_neighbors calls A.contains_point(nB) for all nodes nB of B > and B.contains_point(nA) for all nodes nA of A. The method > Elem::contains_point(), however, does *not* check whether the given point is > a node of the respective element; rather it uses an inverse map to check > whether the point is contained in the element. Hence, if I understand > correctly what you mean, these cases are caught correctly (and would be by > Elem::find_edge_neighbors() the same way). Or did you mean something > different? Ah, you're right! It's been a while since I wrote find_point_neighbors; I thought it was just testing node sharing. The inverse_map based point test ought to work fine, both for it and for your proposed find_edge_neighbors.  Roy 
From: Tim Kroeger <tim.kroeger@ce...>  20091029 15:23:32
Attachments:
patch

On Thu, 29 Oct 2009, Roy Stogner wrote: > On Thu, 29 Oct 2009, Tim Kroeger wrote: > >> Hmm... There seems to be some misunderstanding either on my side or on >> yours. To check whether two elems (say, A and B) have a common point, >> Elem::find_point_neighbors calls A.contains_point(nB) for all nodes nB of B >> and B.contains_point(nA) for all nodes nA of A. The method >> Elem::contains_point(), however, does *not* check whether the given point >> is a node of the respective element; rather it uses an inverse map to check >> whether the point is contained in the element. Hence, if I understand >> correctly what you mean, these cases are caught correctly (and would be by >> Elem::find_edge_neighbors() the same way). Or did you mean something >> different? > > Ah, you're right! It's been a while since I wrote > find_point_neighbors; I thought it was just testing node sharing. The > inverse_map based point test ought to work fine, both for it and for > your proposed find_edge_neighbors. Alright, here's my patch. I'll test whether my application does the expected thing with this, and if it does (and nobody objects), I'll try to do my first commit on Monday. I'll let you know whether it worked. Best Regards, Tim  Dr. Tim Kroeger tim.kroeger@... Phone +494212187710 tim.kroeger@... Fax +494212184236 Fraunhofer MEVIS, Institute for Medical Image Computing Universitaetsallee 29, 28359 Bremen, Germany 
From: Tim Kroeger <tim.kroeger@ce...>  20091102 09:55:15

On Thu, 29 Oct 2009, Tim Kroeger wrote: > I'll try to do my first commit on Monday. I'll let you know whether > it worked. Checking in worked straight forward; however, it seems that the choice of my user name "sheep_tk" was somewhat disadvantageous because it might not be intuitive to everybody who that is. What do you think? Best Regards, Tim  Dr. Tim Kroeger tim.kroeger@... Phone +494212187710 tim.kroeger@... Fax +494212184236 Fraunhofer MEVIS, Institute for Medical Image Computing Universitaetsallee 29, 28359 Bremen, Germany 
From: Roy Stogner <roystgnr@ic...>  20091102 14:07:44

On Mon, 2 Nov 2009, Tim Kroeger wrote: > On Thu, 29 Oct 2009, Tim Kroeger wrote: > >> I'll try to do my first commit on Monday. I'll let you know whether it >> worked. > > Checking in worked straight forward; however, it seems that the choice of my > user name "sheep_tk" was somewhat disadvantageous because it might not be > intuitive to everybody who that is. What do you think? It's fine. You've got your full name visible on the sf.net pages, same as Derek "friedmud" Gaston.  Roy 
From: Tim Kroeger <tim.kroeger@ce...>  20091102 13:59:48

On Mon, 2 Nov 2009, Roy Stogner wrote: > On Mon, 2 Nov 2009, Tim Kroeger wrote: > >> Checking in worked straight forward; however, it seems that the choice of >> my user name "sheep_tk" was somewhat disadvantageous because it might not >> be intuitive to everybody who that is. What do you think? > > It's fine. You've got your full name visible on the sf.net pages, > same as Derek "friedmud" Gaston. Where do I find that page? I didn't know that exists, and I can't find it. Best Regards, Tim  Dr. Tim Kroeger tim.kroeger@... Phone +494212187710 tim.kroeger@... Fax +494212184236 Fraunhofer MEVIS, Institute for Medical Image Computing Universitaetsallee 29, 28359 Bremen, Germany 
From: Roy Stogner <roystgnr@ic...>  20091102 14:59:07

On Mon, 2 Nov 2009, Tim Kroeger wrote: > On Mon, 2 Nov 2009, Roy Stogner wrote: > >> On Mon, 2 Nov 2009, Tim Kroeger wrote: >> >>> Checking in worked straight forward; however, it seems that the choice of >>> my user name "sheep_tk" was somewhat disadvantageous because it might not >>> be intuitive to everybody who that is. What do you think? >> >> It's fine. You've got your full name visible on the sf.net pages, >> same as Derek "friedmud" Gaston. > > Where do I find that page? I didn't know that exists, and I can't find it. Maybe you have to be logged in? Anyway: http://sourceforge.net/project/memberlist.php?group_id=71130  Roy 
From: Tim Kroeger <tim.kroeger@ce...>  20091102 15:19:10

On Mon, 2 Nov 2009, Roy Stogner wrote: > On Mon, 2 Nov 2009, Tim Kroeger wrote: > > Maybe you have to be logged in? Anyway: > http://sourceforge.net/project/memberlist.php?group_id=71130 I see, thank you very much. It's difficult to find by clicking, but now that I know, I also managed it that way. Best Regards, Tim  Dr. Tim Kroeger tim.kroeger@... Phone +494212187710 tim.kroeger@... Fax +494212184236 Fraunhofer MEVIS, Institute for Medical Image Computing Universitaetsallee 29, 28359 Bremen, Germany 