From: Roy S. <roy...@ic...> - 2006-08-08 17:38:07
|
On Tue, 8 Aug 2006, Derek Gaston wrote: > Firstly about the newton iterations for inverse_map(). I ran into > this same bit of code a while ago... and through discussions with Roy > and John decided the best thing to do was to change the code so that > it returns a point that is definitely wrong when the newton iterations > aren't converging. Therefore I have something like this in my code: > > if (cnt > 10) > { > //Return a point that is definitely wrong > for(unsigned int i=0;i<Dim;i++) > p(i)=1e6; > return p; > } > > Now whether or not that's right or good... it does seem to work. I > just wanted to report what I was doing. You reported what you were doing weeks ago; but either you never sent me a patch or I never got it committed! Anyway, I'm changing fe_map.C now to put that behavior into CVS; double check it and make sure it works the way your current version does. > I am definitely up for trying out new point_locator stuff! Should I > try to apply the patches from 4 days ago give feedback? They should all be in CVS now; just doing a "cvs update" should get everything ready for you to test. > Since I am late to the discussion I'm still trying to figure out > what the latest state of the patches is. The PointLocatorTree (the default PointLocator implementation that MeshFunction uses) should be significantly more efficient now and should work correctly on refined meshes; that's all in CVS. There will be an new MeshFunction API (not yet in CVS) that will return a user-defined constant value when called on points outside the mesh. There's still a chance of the PointLocatorTree failing (and falling back on a slow linear search) if there are mesh elements with curved sides. Nobody knows how to fix that efficiently; we'll probably put in some hack to try and minimize the problem. --- Roy |