[petsc-users] SNES Shell Problems

Gaetan Kenway kenway at utias.utoronto.ca
Mon Aug 27 23:13:39 CDT 2012 

Excellent!

It finally runs without segfaulting.  Now... to get it actually solve my
problem.... :)

Gaetan

On Mon, Aug 27, 2012 at 11:51 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

> 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/20120828/52a143ed/attachment-0001.html>

More information about the petsc-users mailing list