Dear Roy, On Thu, 5 Mar 2009, Roy Stogner wrote:
> On Thu, 5 Mar 2009, Tim Kroeger wrote: > >> Well, actually the crash was due to the missing a.close() between a=b >> and a.scale(). After adding that, but before my latest patch, it didn't >> crash any more, but it produced totally wrong results. That led me to the >> idea that PetscVector::scale() (and hence other methods) should use the >> local form. > > This is surprising. What were you calling scale() on? As of now the > only ghosted vectors are *supposed* to be current_local_solution and kin. 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, 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.) >> However, I how have another problem: After the first ~20 time steps of my >> application, it starts to refine the grid and -- crashes. I have no idea >> why, but I will try to track that down. > > Thanks. The ghosted vectors seem to do fine with our AMR/C examples > and with my apps, and without a test case demonstrating the bug I > don't know where I'd begin to fix it. 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. In particular, I noticed that the grid is successfully refined two or three times before the crash. But I won't capitulate. >> (Re-configuring takes a lot of time, you know.) > > Actually, I do all these big tests on a cluster with distcc set up. > "make -j 50" is *fantastic*. ;-) Good idea! I will keep that in mind for the next time. (distcc isn't installed, but the master node has several CPUs as well.) > Odd. How about with this vectest2.C? I can't even get problem (b) to > trigger with ghosted vectors! Nor can't I other than in my application. > 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. 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
