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

Reply via email to