From: Karen L. <kyl...@gm...> - 2010-06-21 17:00:34
|
I see. Thanks a lot for the tips Roy! I'm using Elem::contains_point(). I'm also wondering, at what point does libmesh start building the tree? Does it do so as it reads in the mesh? My program works with some test cases but not with the mesh I'm interested in solving... I realized that some of the nodes have the same coordinates. (It's a mesh that my collaborators obtained from MRI...) I'm wondering if this might cause a problem. With a program that does not involve a tree, a mesh of 20 times the number of elements (call this mesh A) took an hour in another program, but never quite finished in hours with my mesh. My program took about an hour to read in mesh A. Any suggestions to make this work would be appreciated Another question is, for my mesh size (with about 200 thousand nodes and almost a million elements) and the number of points to check (whether they're in these elements) is about 100 thousand, would a tree be better than a list? Thanks, Karen On Thu, Jun 10, 2010 at 11:32 AM, Roy Stogner <roy...@ic...>wrote: > > On Thu, 10 Jun 2010, Karen Lee wrote: > > There's PointLocatorTree and PointLocatorList to choose from >> that has the function I need implemented. Do you have any advice which one >> to stick to and some insight into how they differ? >> >> http://libmesh.sourceforge.net/doxygen/point__locator__base_8C_source.php#l00047 >> > > IIRC, Tree is O(N log N) to build, but O(log N) in lookup time. List > is cheap to build, but O(N) lookup time. Tree gets built by default > if you use MeshBase::point_locator() to request it. > > You also might want to look at Elem::contains_point(); if you're > looping through elements anyway to do some assembly then often you can > most efficiently check for points in those elements at the same time. > --- > Roy > |