OK - I'll just mention that I'm getting really bizarre behavior with the debugger. I compiled with -g -O0 (and same for PETSc library, using COPTFLAGS, CXXOPTFLAGS, and FOPTFLAGS). The strange behavior includes:
I set a breakpoint in the Jacobian evaluation function, and when stepping with gdb, the executed line doesn't match the code at all. Instead, it jumps forwards and backwards. Variables which are assigned a value at the beginning of the routine are later set to zero. Variables defined outside of the routine (for example, variables pointed to by my external parameters ctx) remain correctly valued. When I run the code with -snes_test_display, many of the elements of the Jacobian show as zero in the hand-coded routine, while the finite difference shows correct values. When I step through the Jacobian evaluation function with the debugger, the corresponding values are calculated correctly, i.e. they match the values from the finite difference. To me this looks like a memory leak in the Jacobian evaluation routine, although valgrind doesn't catch anything and neither does gdb. I'll take your advice and upload the code to the maint list - thanks for all your help! On Mon, Aug 28, 2017 at 7:46 AM, Barry Smith <[email protected]> wrote: > > > On Aug 28, 2017, at 12:13 AM, zakaryah . <[email protected]> wrote: > > > > Any clues on what I should test with the debugger? Just running with > "-snes_type test -snes_test_display -start_in_debugger noxterm" the > debugger reports a PETSc error: > > > > MatSetValues_SeqAIJ(), Inserting a new nonzero at (7,0) in the matrix > > > > (7,0) is certainly within the allocated space, considering the call to > DMDACreate3d() that I sent before. I'm suspicious that the -snes_type test > is somehow incompatible with the DMDA, at least without somehow > initializing the Jacobian. > > No definitely not. We use it all the time in many tests and never have > problems with new nonzeros. Can you send your code to > [email protected] and we can run it? > > Barry > > >
