On Mon, 9 Mar 2009, Tim Kroeger wrote: > Just to be curious: What is the most confusing code in the library then?
Matter of opinion, but in mine it's the FE<BLAH> base class structure. The standard Curiously Recurring Template Pattern is confusing enough, our version of it isn't quite the standard, and even though the weirdness is all there for optimization's sake, we'd have probably been much better optimized by just doing FE inits with fewer un-inlineable function calls in the middle of loops. Of course, this is also a personal grudge. My first contribution to libMesh was a new FE type - if the FE classes were more straight forward I would have abandoned my Matlab and deal.II-based (no offense to the latter fantastic library) codes and switched to libMesh earlier and faster. >> But wouldn't we be catching that with a libmesh_assert()? The >> preconditions on operator= in petsc_vector.C seem pretty thorough. > > But only in debug mode, right? Right. > The problem with that is that compiling in debug mode requires to > compile our institute's software package in debug mode as well since > they use the same debug macros. I try to avoid that because > it's a lot of work, so actually I never use debug-mode libmesh. Yikes! I'm having to work on a non-libMesh code without any debug mode right now, and the lack of proper precondition/postcondition testing (or even the less-than-proper test coverage in libMesh) is really painful. libMesh makes it easy enough to keep simultaneous debug and optimized builds around; IMHO every software package should do the same. > (Feature-request: Use LIBMESH_DEBUG rather than DEBUG.) Interesting idea. Maybe in the next version, when people have had some time to switch from assert() to libmesh_assert(); we wouldn't want to turn off user code debugging inadvertently. > The crash seems to happen somewhere in the element loop in > DofMap::enforce_constraints_exactly(). (Of course, the cause may be at a > different place.) More details to follow next time. Thanks! > Funnily enough, my slightly-off residuals get modified with your patch, but > still are slightly off, e.g.: > > without ghosted: 1.16561e-08 > with ghosted, without your patch: 1.16563e-08 > with ghosted, with your patch: 1.16558e-08 Without my patch the problem could be that your first solution iterate might have been effectively non-zero depending on what was in the allocated memory... but I've got no idea what the difference from "without ghosted" could be. --- Roy ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
