On Fri, 15 Oct 2010, Derek Gaston wrote:
> On Oct 15, 2010, at 7:32 AM, Tim Kroeger wrote:
>
>> 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.
>
> I think this is a vote _for_ my algorithm, not against!
Well, let's say, it's just a different purpose. I anyway only use it
for some visualization that I use for debugging (e.g. in the case
where the hanging node value is wrong and I want to analyze why that
happend). That is, it doesn't matter what the method does exactly, as
long as I know what it does. But intuitively, I would find it more
sensible to show the (possibly wrong) value of the hanging node only
on the right side of the separating line here.
> I like the general idea of these two functions... however I'm not
> sure how useful they would actually be. Like you start to get into
> here in this last paragraph... if you are doing this kind of thing
> then you want it to be highly optimized (for instance we've hand
> tuned these algorithms in our code to perfectly match our
> situation). Optimizing them for the general case can be tricky.
> My point is that when you get into this spatial search game and you
> are depending on it being fast... you are almost always going to
> need to write something yourself to cater to your particular needs.
I see...
> As for helping you out with the code... here is some pseudocode:
>
> get_nearest_node_to_point(point)
> {
> Node * closest_node;
> Real closest_distance = RealMax;
> for(cur_node in active_nodes)
> {
> Real cur_distance = (cur_node - point).size();
> if(cur_distance < closest_distance)
> {
> closest_node = cur_node;
> closest_distance = cur_distance;
> }
> }
> return closest_node;
> }
Thank you!
> There are a couple more things to think about here as well. This
> kind of algorithm will only work with SerialMesh. If you are using
> ParallelMesh then the closest node might be on another processor.
> In that case the whole algorithm gets a TON more complicated (you
> need to look for batches of closest nodes to keep down parallel
> communication). Also, like you mentioned you may want to somehow
> "cache" the closest node... however I would caution against doing
> that _in_ this function. Instead I would do it in your own code on
> the outside of this function. The reason for that is that the mesh
> might change and this function won't know it.
I see, I didn't think of ParallelMesh.
It really seems easier to me now not to put that into the library.
I'll wait whether Roy says something about this and then do something
on Tuesday, where "something" will most probably mean that I just use
your algorithm in my application code and put nothing into the
library.
Anyway, thank you very much for your help!
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
