[petsc-users] SNES Shell Problems

Jed Brown jedbrown at mcs.anl.gov
Mon Aug 27 22:51:16 CDT 2012 

I think these function pointers should not be copied over, at least not in
this way. I think Peter is working on a Fortran example to reproduce, but I
think that if you apply the patch below, your calling sequence will work.

diff --git a/src/snes/interface/snes.c b/src/snes/interface/snes.c
--- a/src/snes/interface/snes.c
+++ b/src/snes/interface/snes.c
@@ -2463,9 +2463,6 @@
     ierr = SNESSetApplicationContext(snes->pc,appctx);CHKERRQ(ierr);
     ierr = VecDestroy(&fpc);CHKERRQ(ierr);

-    /* copy the function pointers over */
-    ierr =
PetscObjectCopyFortranFunctionPointers((PetscObject)snes,(PetscObject)snes->pc);CHKERRQ(ierr);
-
      /* default to 1 iteration */
     ierr = SNESSetTolerances(snes->pc, 0.0, 0.0, 0.0, 1,
snes->pc->max_funcs);CHKERRQ(ierr);
     ierr = SNESSetNormType(snes->pc, SNES_NORM_FINAL_ONLY);CHKERRQ(ierr);


On Mon, Aug 27, 2012 at 10:44 PM, Gaetan Kenway <kenway at utias.utoronto.ca>wrote:

> Following your suggestion I changed by calling routines to:
>
>      call SNESCreate(SUMB_COMM_WORLD, outer_snes, ierr)
>      call SNESSetType(outer_snes, SNESNGMRES, ierr)
>      call SNESSetFunction(outer_snes, rVec, formFunction_snes, ctx2, ierr)
>      call snessetfromoptions(outer_snes, ierr)
>
>      call SNESGetPC(outer_snes, psnes, ierr)
>      call SNESSetType(psnes, SNESSHELL, ierr)
>      call SNESShellSetSolve(psnes, psnes_func, ierr)
>
> And the exact same errors occur. I'm pretty sure it has something to do
> with combing the two snes objects. Both work just fine by themselves. Do
> some pointers get accidentally overwritten somehow? I also tried creating
> the 'psnes' first (with a SNESCreate) , and then using the SNESSetPC()
> instead but the same error happens.
>
> Gaetan
>
>
> On Mon, Aug 27, 2012 at 11:21 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
>
>> On Mon, Aug 27, 2012 at 9:52 PM, Gaetan Kenway <kenway at utias.utoronto.ca>wrote:
>>
>>> I ran it though the debugger and came up with the following output:
>>> (gdb) backtrace
>>> #0  0x00000000 in ?? ()
>>> #1  0xb5fd2832 in oursnesshellsolve (snes=0xbb03d30, x=0xbb2a4f0) at
>>> /nfs/mica/home/kenway/Downloads/petsc-3.3/src/snes/impls/shell/ftn-custom/zsnesshellf.c:13
>>>
>>
>> How are you calling SNESShellSetSolve(). The usage we expected was that
>> you would
>>
>> call SNESSetFromOptions(snes,ierr)
>> call SNESGetPC(snes,snespc,ierr)
>> call SNESShellSetSolve(snespc,yourfunction,ierr)
>>
>>
>>> #2  0xb6017009 in SNESSolve_Shell (snes=0xbb03d30) at
>>> /nfs/mica/home/kenway/Downloads/petsc-3.3/src/snes/impls/shell/snesshell.c:169
>>> #3  0xb60032e8 in SNESSolve (snes=0xbb03d30, b=0xb8c0610, x=0xbb2a4f0)
>>> at /nfs/mica/home/kenway/Downloads/petsc-3.3/src/snes/interface/snes.c:3536
>>> #4  0xb6041547 in SNESSolve_NGMRES (snes=0xb8c1f70) at
>>> /nfs/mica/home/kenway/Downloads/petsc-3.3/src/snes/impls/ngmres/snesngmres.c:259
>>> #5  0xb60032e8 in SNESSolve (snes=0xb8c1f70, b=0xb8c0610, x=0xb8ba6f0)
>>> at /nfs/mica/home/kenway/Downloads/petsc-3.3/src/snes/interface/snes.c:3536
>>> #6  0xb5fd0e73 in snessolve_ (snes=0xb4d75a2c, b=0xb4d75c6c,
>>> x=0xb4d75c68, __ierr=0xbfffe338)
>>>     at
>>> /nfs/mica/home/kenway/Downloads/petsc-3.3/src/snes/interface/ftn-custom/zsnesf.c:181
>>> #7  0xb47791f3 in nksolver2 () at NKSolver2.F90:20
>>> #8  0xb46f8f68 in solvestate () at solveState.F90:485
>>> #9  0xb46f95c2 in solversteady () at solverSteady.f90:27
>>> #10 0xb46f9257 in solver () at solver.F90:102
>>> #11 0x0b8ba2c0 in ?? ()
>>> #12 0xb464a222 in f2py_rout_sumb_solver () from /tmp/tmpTaGWsk/sumb.so
>>> #13 0xb46454e5 in fortran_call () from /tmp/tmpTaGWsk/sumb.so
>>> #14 0x0805fd6a in PyObject_Call ()
>>> #15 0x080dd5b0 in PyEval_EvalFrameEx ()
>>> #16 0x080dfbb2 in PyEval_EvalCodeEx ()
>>> #17 0x08168f1f in ?? ()
>>> #18 0x0805fd6a in PyObject_Call ()
>>> #19 0x080dcbeb in PyEval_EvalFrameEx ()
>>> #20 0x080dfbb2 in PyEval_EvalCodeEx ()
>>> #21 0x08168e3c in ?? ()
>>> #22 0x0805fd6a in PyObject_Call ()
>>> #23 0x08067d5c in ?? ()
>>> #24 0x0805fd6a in PyObject_Call ()
>>> #25 0x080b3554 in ?? ()
>>> #26 0x0805fd6a in PyObject_Call ()
>>> #27 0x080dd5b0 in PyEval_EvalFrameEx ()
>>> #28 0x080dfbb2 in PyEval_EvalCodeEx ()
>>> #29 0x080dfca7 in PyEval_EvalCode ()
>>> #30 0x080fd956 in PyRun_FileExFlags ()
>>> #31 0x080fdbb2 in PyRun_SimpleFileExFlags ()
>>> #32 0x0805b6d3 in Py_Main ()
>>> #33 0x0805a8ab in main ()
>>>
>>> I'm also 99% certain that the function in set correctly since the shell
>>> snes works just fine when it is called directly. (see some of the earlier
>>> code snippits). Its only when I'm trying to use it as the preconditioner
>>> for the another snes object (ngmres) I have issues.
>>>
>>> Gaetan
>>>
>>> On Mon, Aug 27, 2012 at 10:34 PM, Jed Brown <jedbrown at mcs.anl.gov>wrote:
>>>
>>>> On Mon, Aug 27, 2012 at 7:31 PM, Gaetan Kenway <
>>>> kenway at utias.utoronto.ca> wrote:
>>>>
>>>>> Unfortunately I can run backtraces since the code is running from
>>>>> python and the -on_error_attach_debugger option has no effect when you're
>>>>> running from python.
>>>>>
>>>>
>>>> You can use -start_in_debugger, then type "c" (for "continue") at the
>>>> gdb prompt.
>>>>
>>>>
>>>>>
>>>>> The petsc4py is initialized with:
>>>>> import petsc4py
>>>>> petsc4py.init(args=sys.argv)
>>>>>
>>>>> so other options are passed in just fine.
>>>>>
>>>>> I ran it with valgrind and got the following:
>>>>>
>>>>> ==15046== Jump to the invalid address stated on the next line
>>>>> ==15046==    at 0x0: ???
>>>>> ==15046==    by 0x95EF008: SNESSolve_Shell (snesshell.c:169)
>>>>> ==15046==    by 0x95DB2E7: SNESSolve (snes.c:3536)
>>>>> ==15046==    by 0x9619546: SNESSolve_NGMRES (snesngmres.c:259)
>>>>> ==15046==    by 0x95DB2E7: SNESSolve (snes.c:3536)
>>>>> ==15046==    by 0x95A8E72: snessolve_ (zsnesf.c:181)
>>>>> ==15046==    by 0x9AEA302: nksolver2_ (NKSolver2.F90:20)
>>>>> ==15046==    by 0x9A6A077: solvestate_ (solveState.F90:485)
>>>>> ==15046==    by 0x9A6A6D1: solversteady_ (solverSteady.f90:27)
>>>>> ==15046==    by 0x99BB1C1: f2py_rout_sumb_solver (in
>>>>> /tmp/tmpGQGZda/sumb.so)
>>>>> ==15046==    by 0x99B6484: fortran_call (in /tmp/tmpGQGZda/sumb.so)
>>>>> ==15046==    by 0x805FD69: PyObject_Call (in /usr/bin/python2.6)
>>>>> ==15046==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
>>>>>
>>>>
>>>> This looks like SNESShellSetSolve() did not work. Are you sure that the
>>>> type was set (e.g. SNESSetType() or SNESSetFromOptions()) before you called
>>>> SNESShellSetSolve()?
>>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20120827/cc5cfb10/attachment.html>

More information about the petsc-users mailing list