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.
Writing a loop over all nodes (or all nodes in a sideset) that checks the distance to a point is a trivial exercise... and MUCH faster than calling is_in_elem(). The only time I could see the search algorithm in meshfunction winning is if you started off with a single element mesh and uniformly refined it 10 or more times (because then the built in search will be able to traverse the refinement tree and quickly hone in on the position). But this is rarely the case. 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. Derek Sent from my iPad On Oct 15, 2010, at 3:01 AM, Tim Kroeger <[email protected]> wrote: > Dear all, > > While I'm still on the subset stuff (I had to do a couple of other things in > the last weeks, but I'm on it again, and my application does not yet work as > expected), I'd suddenly like to be able to disable the interpolation in the > MeshFunction. That is, what I want is this: I pass a point to the > MeshFunction, and the MeshFunction finds the element in which this point is > and then finds the node of this element which is nearest to the point and > then returns the dof value of that node. > > I have implemented this, see attached patch. What I do is, I loop over all > dofs, but instead of multiplying the dof value with the value of the shape > function, I find out which shape function takes the largest value, and then I > return the corresponding dof's value. > > This does what I want in my situation. However, I would like to hear your > comments, in particular: > > * Would you like this functionality in the library? > > * Do you like the API? > > * Will this always do what I mean? (Actually, for me it is not really > important that it's definitely the nearest node's value what I get. Rather, > it suffices that in some reasonable neighborhood a node, I get that node's > value. Possible, the name of the mode should be changed then.) > > * What should this mode do to the gradient and the hessian? > > Best Regards, > > Tim > > PS: I won't be here on Monday. > > -- > 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 > <patch> > ------------------------------------------------------------------------------ > 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 ------------------------------------------------------------------------------ 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
