On Wed, 1 Feb 2012, John Peterson wrote:
On Wed, Feb 1, 2012 at 11:00 AM, Roy Stogner <royst...@ices.utexas.edu> wrote:
On Wed, 1 Feb 2012, John Peterson wrote:
We've had a request here to only print out the poor Newton convergence
info in FE::inverse_map() when in DEBUG mode (see attached patch).
Apparently they have an actual problem where some of the elements are
bad enough that this print-out gets triggered a lot...
It seems reasonable to me, but I can see the argument for keeping
those printouts in there in opt mode - it might alert you that
something untoward is going on in optimized mode that you wouldn't
otherwise see.
Anyway, unless you are opposed I will probably check it in...
Could you wrap it in a libmesh_do_once() in optimized mode? That way
users get a printout but don't get spammed with printouts.
I definitely could add that, but then you'd get one printout for the
entire mesh, not one printout per element which had trouble
converging.
To me that's more confusing than the current approach or the
all-in-debug/nothing-in-opt approach.
Perhaps. How about replicating the behavior of libmesh_do_once, but
with a static std::set<Elem*> (and corresponding mutex to avoid
threaded STL problems) rather than with a single static bool? Then
you get one printout per element which had trouble converging. In
AMR/C runs you might get a few false negatives (a newly-refined
distorted child element gets allocated at exactly the same memory
address as a different, previously-coarsened-away distorted child) or
false positives (a previously-coarsened-away distorted child gets
created by re-refining its parent, but gets allocated a new memory
address) but it's still probably a uniformly better solution.
On the heels of that patch comes another one (These are coming from
Ben Spencer, a guy we hired recently. He seems to enjoy going through
codebases and finding small inconsistencies...) this time in elem.C.
There is a hard-coded tolerance there of 1.e-4 that dates back to
r244... now that contains_point takes a tolerance, we should probably
use that there, no?
Hmm... I also dislike hardcoded magic numbers, but I want to be sure
we're not replacing apples with oranges...
The inverse_map tolerance there is a tolerance in reference element
space, as is the contains_point tol, so this is apples-to-apples, we
definitely want them to be of the same order. contains_point is
supposed to occasionally return false positives near element
boundaries but *never* return false negatives... and by using a lower
inverse_map tolerance than contains_point tol, it looks like we do
risk false negatives! Of course, even using inverse_map tolerance of
tol/2 wouldn't be *perfect*, since inverse_map just uses the newton
step length as a stopping criterion rather than guaranteeing that it
meets its tolerance, but tol/2 (or tol/10, to be paranoid) might just
fix a hidden bug in some corner cases we haven't happened to run into
yet.
Copying this whole thing to libmesh-devel; I'd be happy to get
additional opinions on either question.
---
Roy
------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
