On Wed, Feb 1, 2012 at 11:56 AM, Kirk, Benjamin (JSC-EG311) <benjamin.kir...@nasa.gov> wrote: > >>> 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. > > I strongly second that suggestion. > > But at a minimum I'd say leave the print as is unless NDEBUG is defined so > that devel mode continues to be noisy. And if the static bool case is > adopted then the error message might read something like > > "at least one element failed to converge... rerun without NDEBUG..."
Roy's suggestion seems way over-complicated and potentially buggy to me just to avoid some print statements! I prefer Ben's approach but note that these print statements are not actually about failure of the Newton scheme, just that it took more than 10 iterations to do so. If Newton actually fails to converge and secure==true (it is by default) then we error out regardless of opt/devel/dbg. -- John ------------------------------------------------------------------------------ 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
