From: <ti...@ce...> - 2006-08-04 20:50:46
|
Dear Roy, On Fri, 4 Aug 2006, Roy Stogner wrote: > On Fri, 4 Aug 2006, Tim Kr=F6ger wrote: > >> This could be fixed by letting Tree::Tree() loop over active elements on= ly. > > I don't think that's a complete fix. The problem with mesh refinement > / coarsening isn't just that the mesh is more complicated, it's that > the mesh keeps *changing*. Okay, I did not think about this. I don't use MeshFunction with=20 changing grids -- i.e., I rebuild the MeshFunction anyway each time=20 the mesh might change. > You'd be welcome (and thanked!) for the fixes. I'd like it if we > could figure out how to make fix 1 a little more robust, but even just > looping over active elements would be better than nothing. I'd rather > place a warning in the MeshFunction documentation than let this class > hold up a 0.6.0 release, and it would be better for that warning to > say "rebuild this object after every mesh change" and not "don't use > this object on a refined mesh". I did these changes now; see the attached patch. Please commit it to=20 the repository (provided that you are satisfied with it). I did set up a test scenario in which the old implementation gave=20 wrong results and the new one got it right. I also removed the fall-back linear search since in my opinion it is=20 not necessary any more. Anyway, if the linear search includes=20 non-active elements (as it did), it would again give wrong results,=20 and if not, it is very likely to crash, because the involved inverse=20 map seems to be very instable in the case that the point is very far=20 away from the element. At least, this is true (and not surprising)=20 for distortet HEX8 elements. Additionally, I added a function get_point_locator() to MeshFunction,=20 because in my application, I want to reuse the MeshFunction's=20 PointLocator for additional purposes. >> Another point is that I would like MeshFunction to be evaluable outside = the=20 >> mesh domain and return a used-defined constant there (instead of crashin= g).=20 >> I think I would be able to do these changes as well (using optional=20 >> parameters so that existing code will not change its behaviour). Any=20 >> comments on this? > Adding an optional parameter to the constructor would be fine. Adding > a method that sets that parameter might be better - although that's > kind of a matter of taste. I did not implement this yet, but I will probably do this later=20 (unless someone else does) because I am likely to need it. Best Regards, Tim |