Dear Derek, On Fri, 15 Oct 2010, Derek Gaston wrote:
> Tim, we recently did something similar... and I think you can do this > much more efficiently another way. Instead of looking for what > element the point is in then finding the closest node.... just look > for the closest node directly then access the dof of the variable out > of the node and use that to index into the solution vector. I see, sounds good. However, it's not quite the same as what I meant. Consider the following situation (use a monospaced font to display this): A - - - - - - - B - - - C - - - D | | | | | | | | | * | | | | E - - - F - - - G | | | | | | | | | | | | H - - - - - - - I - - - J - - - K At the position indicated by "*", your algorithm would return the value at node E, but mine would return the value at node B because the element in which "*" is contained does not know about node E. On the other hand, for the purpose I need this for, this is actually not really too much of importance, so I might be satisfied with your algorithm. Anyway, if you have already implemented such a thing, why don't you just send it to me? Or, if it is clean enough, why don't you just check it in? > At the very least... The idea of checking the largest shape function > might not be right. There might be some shape functions where the > closest dof's shape function might not be the largest. I would just > loop through the nodes connected to the element and check their > distance to the point. Yes, I certainly should do this. This makes it even slower. I really think, I should use your method. Anyway, I think it would be nice to have such a thing in the library. What would be the correct API? I would propose Mesh::get_nearest_node_to(const Point& point); System::get_value_at_nearest_node_to(const Point& point, std::vector<Number>& values, unsigned int var=invalid_int); What do you think? BTW: I will be calling this function extremly often, and in succesive calls the points will often be close to each other, so that I think that the method should do some fast check to see whether the node might be the same as before. One possibility to do that would be that Mesh::get_nearest_node_to() will remember the Point and the node that was returend, as well as the difference between the distance to this node and the distance to the second-nearest node. Then, by the triangle inequality, the next call can be short-circuited if the distance of the new point and the remembered point is smaller than the remembered difference. The only thing is that I don't know how to figure out whether the mesh has changed since the last call, because then of course this fast check cannot be used. Anyway, I can implement this if we agree on the API. Also, if you send me your implementation, this would simplify things for me. Best Regards, Tim -- Dr. Tim Kroeger CeVis -- Center of Complex Systems and Visualization University of Bremen [email protected] Universitaetsallee 29 [email protected] D-28359 Bremen Phone +49-421-218-7710 Germany Fax +49-421-218-4236 ------------------------------------------------------------------------------ Download new Adobe(R) Flash(R) Builder(TM) 4 The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly Flex(R) Builder(TM)) enable the development of rich applications that run across multiple browsers and platforms. Download your free trials today! http://p.sf.net/sfu/adobe-dev2dev _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
