Dear Roy, On Fri, 6 Mar 2009, Roy Stogner wrote:
>> It was the "solution" vector, not "current_local_solution". I don't know >> why it crashed there, but that was reproducible. Perhaps I did something >> else wrong. (In earlier times, when I didn't quite understand the >> difference between these two vectors, > > Don't feel bad about that. For my own part, I don't care too much > about serial vector memory usage - I'm mostly interested in getting > ghosted vectors working because I think the solution / > current_local_solution distinction is the second most confusing code > in the library, Just to be curious: What is the most confusing code in the library then? >> I think I sometimes cross-assigned one of them to the other in a >> different system. Perhaps such an assignment still exists somewhere >> hidden in my code.) > > That could be a serious problem, yes. > > 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? 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. (Feature-request: Use LIBMESH_DEBUG rather than DEBUG.) >> I'm still working on the track-down. The problem is that the application >> runs for more than 2 hours before it crashes, and I couldn't find a >> possibility to let it crash earlier. > > I hope your app has restart file capabilities! Each time I face a problem like the current one I think "Well, next time I'll implement it." (-: >> In particular, I noticed that the grid is successfully refined two or three >> times before the crash. But I won't capitulate. > > Thanks! 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. >>> On the other hand, here's something even more odd: I just realized >>> that I'm not properly matching the ghosted vector init() function >>> signature. The compiler must be deciding to convert GHOSTED to true >>> and then using the default AUTOMATIC for the fifth argument? That >>> wouldn't explain any crashes, but if we're fast-initializing vectors >>> we should be clearing, that might explain your slightly-off residuals. >>> I'll fix it in SVN. >> >> Did you fix that? "svn log" doesn't show anything from you later than >> 2009-03-04. > > Whoops! Fixed it, got distracted by other work, forgot to commit the > fix. I'll put in that (and your patch, which still looks good) today. 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 Best Regards, Tim -- Dr. Tim Kroeger tim.kroe...@mevis.fraunhofer.de Phone +49-421-218-7710 tim.kroe...@cevis.uni-bremen.de Fax +49-421-218-4236 Fraunhofer MEVIS, Institute for Medical Image Computing Universitaetsallee 29, 28359 Bremen, Germany ------------------------------------------------------------------------------ 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
