From: <ti...@ce...> - 2007-09-14 06:49:05
|
Dear Lorenzo, On Thu, 13 Sep 2007, Lorenzo Botti wrote: > These are the files I'm using for my particle tracer... > The idea is to give to each tree node an extended bounding box containing > all the nodes of the elements it possesses. I see. That seems good to me. Perhaps someone should check it in? > The elements are inserted using the centroid (no multiple tree nodes with > the same element) so it needs point_locator_tree.C version 1.19 or version > 1.20 with ELEMENTS insertion method. How can you use the ELEMENTS method with version 1.20? That's exactly the point my original question was about: The 1.20 version of point_locator_tree.C uses the NODES version, but I want to use the ELEMENTS version -- without having to work with a patched version of the library. > Another thing... > Using the ELEMENTS insertion method with point_locator_tree.C 1.20 and > tree_node.C 1.22 (from cvs) a get segmentation fault when i decrease the max > number of elements in each tree node. I don't know where is the problem... See my posting in libmesh-devel dated August 23rd of last year, subject "Another problem with PointLocatorTree". However, with you modification, it should work (and does for my example). So, let us summarize the following two tasks for Roy and John: 1.) Check in your (Lorenzo's) modification of tree_node.*, if they like it. 2.) Allow the user in some way to revert to the ELEMENTS method in PointLocatorTree. I would be willing to implement this if we agree what is the best method to do this. I favor an optional variable that is passed through up to the constructor of MeshFunction. Best Regards, Tim -- Dr. Tim Kroeger Phone +49-421-218-7710 ti...@me..., ti...@ce... Fax +49-421-218-4236 MeVis Research GmbH, Universitaetsallee 29, D-28359 Bremen, Germany Amtsgericht Bremen HRB 16222 Geschaeftsfuehrer: Prof. Dr. H.-O. Peitgen |
From: Roy S. <roy...@ic...> - 2007-09-14 21:04:14
|
On Fri, 14 Sep 2007, Tim Kröger wrote: > So, let us summarize the following two tasks for Roy and John: > > 1.) Check in your (Lorenzo's) modification of tree_node.*, if they like it. I'm afraid I'm going to have to punt to Ben unless he's too busy; although I'm partly responsible for triggering our PointLocator changes by writing library code that overused PointLocator, he's the one who made the latest set of edits, and I've only looked at and tested the new code enough to make sure it wasn't breaking my periodic domain constraints. It'll probably be at least a week before I've got time to catch up on his changes and Lorenzo's. --- Roy |
From: Benjamin K. <ben...@na...> - 2007-09-20 16:05:12
|
OK, I'm looking at the patch now... Sorry for the delay. I've been in an annual peer review which is just now wrapping up. -Ben On 9/14/07 4:04 PM, "Roy Stogner" <roy...@ic...> wrote: > On Fri, 14 Sep 2007, Tim Kr=F6ger wrote: >=20 >> So, let us summarize the following two tasks for Roy and John: >>=20 >> 1.) Check in your (Lorenzo's) modification of tree_node.*, if they like = it. >=20 > I'm afraid I'm going to have to punt to Ben unless he's too busy; > although I'm partly responsible for triggering our PointLocator > changes by writing library code that overused PointLocator, he's the > one who made the latest set of edits, and I've only looked at and > tested the new code enough to make sure it wasn't breaking my periodic > domain constraints. It'll probably be at least a week before I've got > time to catch up on his changes and Lorenzo's. > --- > Roy |
From: <ti...@ce...> - 2007-10-22 09:41:18
|
Dear Ben, On Thu, 20 Sep 2007, Benjamin Kirk wrote: > OK, I'm looking at the patch now... Sorry for the delay. I've been in an > annual peer review which is just now wrapping up. I see... I know that deadlines and such tend to wrap up when you don't expect them. Nevertheless, I would like to ask you to attand to my request. Let me repeat what the main two points are: 1. (more important for me): In point_locator_tree.C, the user should have the possibility to use the 1.19 version functionality. I can implement that if we agree about the way how to do it (e.g. member variable that can be switched on, similar like out_of_mesh_mode). See my emails dated Sept-11 and Sept-13 for the reason why I need this. 2. (less important for me, but certainly useful for others): Have a look at Lorenzo's patch of tree_node.{h,C}. It makes things faster but uses more memory. Best Regards, Tim -- Dr. Tim Kroeger Phone +49-421-218-7710 ti...@me..., ti...@ce... Fax +49-421-218-4236 MeVis Research GmbH, Universitaetsallee 29, D-28359 Bremen, Germany Amtsgericht Bremen HRB 16222 Geschaeftsfuehrer: Prof. Dr. H.-O. Peitgen |