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

Reply via email to