[petsc-users] SNESSetConvergenceTest
Dharmendar Reddy
dharmareddy84 at gmail.com
Wed Jan 22 20:20:24 CST 2014
Hello,
I will try to f-blas-pack. later today.
I did some more digging of the code:
When i look at the snes object...I find the follwoing: I can see that
the ctx and residual and jacobian functions are set right. Where as
the fortran callbacks in the snes seem to be wrong..even though snes
says it has one fortran callback..am i reading this right ?
(idb) print (*snes).dm.dmsnes.fortrancallback[1][0]
$95 = {func = 0x7e9e7e <functionresidualwithdm>, ctx = 0x2b591f8}
(idb) print (*snes).dm.dmsnes.fortrancallback[1][1]
$96 = {func = 0x7e9bb8 <functionjacobianwithdm>, ctx = 0x2b591f8}
(idb) print (*snes).hdr
$97 = {classid = 1211230, bops = 0x53bc4d0, comm = -2080374784, type =
0, flops = 0, time = 0, mem = 1340, memchild
ren = 0, id = 67, refct = 1, tag = 1073741734, qlist = 0x0, olist =
0x0, class_name = 0x2b592d32b9fc "SNES", descri
ption = 0x2b592d32ba04 "Nonlinear solver", mansec = 0x2b592d32b9fc
"SNES", type_name = 0x5416040 "newtonls", parent
= 0x0, parentid = 0, name = 0x0, prefix = 0x54146b0 "ddm_", tablevel
= 0, cpp = 0x0, state = 0, int_idmax = 0, int
star_idmax = 0, intcomposedstate = 0x0, intstarcomposedstate = 0x0,
intcomposeddata = 0x0, intstarcomposeddata = 0x
0, real_idmax = 0, realstar_idmax = 0, realcomposedstate = 0x0,
realstarcomposedstate = 0x0, realcomposeddata = 0x0
, realstarcomposeddata = 0x0, scalar_idmax = 0, scalarstar_idmax = 0,
scalarcomposedstate = 0x0, scalarstarcomposed
state = 0x0, scalarcomposeddata = 0x0, scalarstarcomposeddata = 0x0,
fortran_func_pointers = 0x0, num_fortran_func_
pointers = 0, *fortrancallback = {0x54cd5e0, 0x0}, num_fortrancallback
= {1, 0}, python_context = 0x0, python_destr
oy = 0x0, noptionhandler = 0, (*optionhandler)(PetscObject, void *) =
{0x0, 0x0, 0x0, 0x0, 0x0}, (*optiondestroy)(P
etscObject, void *) = {0x0, 0x0, 0x0, 0x0, 0x0}, *optionctx = {0x0,
0x0, 0x0, 0x0, 0x0}, precision = PETSC_PRECISIO
N_DOUBLE, optionsprinted = PETSC_TRUE}
(idb) print (*snes).hdr.fortrancallback[0][0]
$98 = {func = 0x0, ctx = 0x0}
The call which sets the convergence test function is : You can see
that the cctx object has same address as the context set in
(*snes).dm.dmsnes.fortrancallback
Breakpoint 1, SOLVERUTILS_M::solve_solver (this=0x2b591f8,
ierr=-1070882422) at /home1/00924/Reddy135/projects/ut
gds/src/solver/Solver.F90:348
348 call SNESSetConvergenceTest(this%snes,
SNESConvergenceTest_snes, this,PETSC_NULL_FUNCTION, ierr);
CHKERRQ(ierr)
(idb) c
Continuing.
Breakpoint 4, snessetconvergencetest_ (snes=0x2b59210, func=0x7ea300
<snesconvergencetest_snes>, cctx=0x2b591f8,
destroy=0x0, ierr=0x7fffcd0c04f4) at
/home1/00924/Reddy135/LocalApps/petsc/src/snes/interface/ftn-custom/zsnesf.c
:254
The stack trace is..
(idb) bt
#0 0x00002b592ca05849 in SNESSolve_NEWTONLS (snes=0x53bba60) at
/home1/00924/Reddy135/LocalApps/petsc/src/snes/imp
ls/ls/ls.c:197
#1 0x00002b592caaf980 in SNESSolve (snes=0x53bba60, b=0x0,
x=0x53ddc00) at /home1/00924/Reddy135/LocalApps/petsc/s
rc/snes/interface/snes.c:3809
#2 0x00002b592cae975b in snessolve_ (snes=0x2b59210, b=0xe2f780,
x=0x2b59258, __ierr=0x7fffcd0c04f4) at /home1/009
24/Reddy135/LocalApps/petsc/src/snes/interface/ftn-custom/zsnesf.c:171
#3 0x00000000007ea68f in SOLVERUTILS_M::solve_solver (this=0x2b591f8,
ierr=0) at /home1/00924/Reddy135/projects/ut
gds/src/solver/Solver.F90:350
#4 0x00000000005b99d9 in FEMLIB_M::solve2_vp (this=0x2b58d60,
solinit={...}) at /home1/00924/Reddy135/projects/utg
ds/src/fem/VariationalProblemBoundProcedures.F90:793
#5 0x0000000000430277 in UTGDS_M::runsimulation_ddm
(this=0x7fffcd0c11f0) at /home1/00924/Reddy135/projects/utgds/
src/devicesimulator/runDDM.F90:39
#6 0x000000000042623e in UTGDS_M::runsimulation_device
(this=0x7fffcd0c11f0) at /home1/00924/Reddy135/projects/utg
ds/src/devicesimulator/UTGDSmod.F90:267
#7 0x000000000040840f in oneddgfetpoissonschrod () at
/home1/00924/Reddy135/projects/utgds/test/testDDM/RTDPoisTes
t.F90:13
#8 0x0000000000407e4c in main () in
/home1/00924/Reddy135/projects/utgds/test/testDDM/PoisTest
#9 0x000000390881ecdd in __libc_start_main () in /lib64/libc-2.12.so
Thanks
Reddy
On Wed, Jan 22, 2014 at 5:45 PM, Matthew Knepley <knepley at gmail.com> wrote:
> On Wed, Jan 22, 2014 at 5:37 PM, Dharmendar Reddy <dharmareddy84 at gmail.com>
> wrote:
>>
>> On Wed, Jan 22, 2014 at 5:33 PM, Matthew Knepley <knepley at gmail.com>
>> wrote:
>> >
>> > On Wed, Jan 22, 2014 at 4:50 PM, Dharmendar Reddy
>> > <dharmareddy84 at gmail.com>
>> > wrote:
>> >>
>> >> I take back my earlier email...
>> >
>> >
>> > Do you have the threadcomm stuff turned on?
>>
>> I do not know what this means. Is related to compile time flags for my
>> fortran code ? I link to mkl which is threaded. But otherwise, i
>> guess, the answer is no.
>
>
> The weird business looks like its in pthreads, so could you reconfigure
> without MKL?
>
> $PETSC_ARCH/conf/reconfigure-$PETSC_ARCH.py --download-f-blas-lapack
> --PETSC_ARCH=arch-testing
>
> It would not surprise me if this was the problem.
>
> Matt
>
>>
>>
>> >
>> > Matt
>> >
>> >>
>> >> I see the error irrespective of valgrind options. I did a clean
>> >> compile to test it few times now.
>> >> See the attached valgrind.log
>> >>
>> >> Now the difference between, ex5f90.F and my code is that i use
>> >> DMSNESSetFunctionLocal in the case where the code fails.
>> >>
>> >> I have also attached the solver.F90 which wraps the calls to snes, Now
>> >> the solver has to interface (1) for equations which are handled with a
>> >> DM and (2) for equation with out DM , here i use SNESSetFunction, and
>> >> this part of the code runs fine with the test case in the code which
>> >> can be compiled with -DTestSolver and standard petsc makefile
>> >>
>> >> The case with DM is linked deeply into my code, i am trying to get to
>> >> a test case for that.
>> >>
>> >> thanks
>> >> Reddy
>> >>
>> >> On Wed, Jan 22, 2014 at 4:30 PM, Barry Smith <bsmith at mcs.anl.gov>
>> >> wrote:
>> >> >
>> >> > The thing to use in valgrind is -q --tool=memcheck
>> >> >
>> >> > This checks for corrupted and illegally accessed memory,
>> >> > uninitialized memory etc It shows the exact lines that memory is
>> >> > used
>> >> > incorrectly so you can fix your code.
>> >> >
>> >> > Barry
>> >> >
>> >> > On Jan 22, 2014, at 4:02 PM, Dharmendar Reddy
>> >> > <dharmareddy84 at gmail.com>
>> >> > wrote:
>> >> >
>> >> >> Hello,
>> >> >> The code works fine if i run with valgrind --leak-check=yes
>> >> >> exename args
>> >> >> it fails if i run valgrind exename args
>> >> >>
>> >> >> Any suggestions on what to look for my code?
>> >> >>
>> >> >> Thanks
>> >> >> Reddy
>> >> >>
>> >> >> On Wed, Jan 22, 2014 at 3:31 PM, Dharmendar Reddy
>> >> >> <dharmareddy84 at gmail.com> wrote:
>> >> >>> Hello,
>> >> >>> I tried using the SNESSetConvergenceTest in ex5f90.F using
>> >> >>> my
>> >> >>> subroutine. Works as expected. I will try to run my code through
>> >> >>> valgrind.
>> >> >>>
>> >> >>> Thanks
>> >> >>> Reddy
>> >> >>>
>> >> >>> On Wed, Jan 22, 2014 at 2:33 PM, Dharmendar Reddy
>> >> >>> <dharmareddy84 at gmail.com> wrote:
>> >> >>>> Hello,
>> >> >>>> I will also try to create a stand alone test case.
>> >> >>>>
>> >> >>>> Thanks
>> >> >>>> Reddy
>> >> >>>>
>> >> >>>> On Wed, Jan 22, 2014 at 1:53 PM, Matthew Knepley
>> >> >>>> <knepley at gmail.com>
>> >> >>>> wrote:
>> >> >>>>> On Wed, Jan 22, 2014 at 1:52 PM, Barry Smith <bsmith at mcs.anl.gov>
>> >> >>>>> wrote:
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>> We need more information to track this down. Could you make a
>> >> >>>>>> simple
>> >> >>>>>> standalone code that reproduces the problem? Just creates a
>> >> >>>>>> this,
>> >> >>>>>> creates a
>> >> >>>>>> SNES, sets the function, sets the test code and then crashes
>> >> >>>>>> when
>> >> >>>>>> runs.
>> >> >>>>>>
>> >> >>>>>> But since it is not crashing in the SNESConvergenceTest_snes
>> >> >>>>>> routine I
>> >> >>>>>> suspect it may be memory corruption. Have you run your code
>> >> >>>>>> under
>> >> >>>>>> valgrind?
>> >> >>>>>> http://www.mcs.anl.gov/petsc/documentation/faq.html#valgrind
>> >> >>>>>
>> >> >>>>>
>> >> >>>>> I am putting his convergence test into ex5f right now. This can
>> >> >>>>> be
>> >> >>>>> valgrinded. I will send an update when it runs.
>> >> >>>>>
>> >> >>>>> Matt
>> >> >>>>>
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>> Barry
>> >> >>>>>>
>> >> >>>>>> On Jan 20, 2014, at 7:14 PM, Dharmendar Reddy
>> >> >>>>>> <dharmareddy84 at gmail.com>
>> >> >>>>>> wrote:
>> >> >>>>>>
>> >> >>>>>>> Hello,
>> >> >>>>>>> I am getting a segmentation fault when i use
>> >> >>>>>>> SNESSetConvergenceTest from Fortran.
>> >> >>>>>>>
>> >> >>>>>>> I use the following:
>> >> >>>>>>>
>> >> >>>>>>> call SNESSetConvergenceTest(this%snes,
>> >> >>>>>>> SNESConvergenceTest_snes,
>> >> >>>>>>> this,PETSC_NULL_FUNCTION, ierr) (Line 1)
>> >> >>>>>>>
>> >> >>>>>>> where the soubtoutine is
>> >> >>>>>>>
>> >> >>>>>>> subroutine
>> >> >>>>>>> SNESConvergenceTest_snes(snes,it,xnorm,gnorm,fnorm,reason,this,
>> >> >>>>>>> ierr)
>> >> >>>>>>> implicit none
>> >> >>>>>>> #include "finclude/petsc.h"
>> >> >>>>>>> ! IO Variables
>> >> >>>>>>> SNES :: snes
>> >> >>>>>>> integer :: it
>> >> >>>>>>> PetscReal :: xnorm
>> >> >>>>>>> PetscReal :: gnorm
>> >> >>>>>>> PetscReal :: fnorm
>> >> >>>>>>> SNESConvergedReason :: reason
>> >> >>>>>>> type(Solver_t) :: this
>> >> >>>>>>> PetscErrorCode :: ierr
>> >> >>>>>>> ! Local Variables
>> >> >>>>>>> Vec :: X, dX
>> >> >>>>>>> Vec :: F, W, G
>> >> >>>>>>> real(WP) :: lambda
>> >> >>>>>>> print*, 'Calling custom test',it,xnorm,fnorm,gnorm
>> >> >>>>>>> !call SNESLineSearchGetLambda(this%linesearch, lambda, ierr)
>> >> >>>>>>> !call SNESLineSearchGetVecs(this%linesearch, X, F, dX, W, G,
>> >> >>>>>>> ierr)
>> >> >>>>>>> !call this%SNESConvergenceTest(it, fnorm, lambda, X, dX,
>> >> >>>>>>> reason,
>> >> >>>>>>> ierr)
>> >> >>>>>>> reason = SNES_DIVERGED_FUNCTION_COUNT
>> >> >>>>>>> end subroutine SNESConvergenceTest_snes
>> >> >>>>>>>
>> >> >>>>>>> Code works fine if the call at Line 1 is commented i.e, if i
>> >> >>>>>>> donot
>> >> >>>>>>> set the convergencetest
>> >> >>>>>>>
>> >> >>>>>>> I have attached the stack trace when the code fails
>> >> >>>>>>> (traceFail.log)
>> >> >>>>>>> and stack trace of the code which runs well (tracePass.log).
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>>> Thanks
>> >> >>>>>>> Reddy
>> >> >>>>>>> <traceFail.log><tracePass.log>
>> >> >>>>>>
>> >> >>>>>
>> >> >>>>>
>> >> >>>>>
>> >> >>>>> --
>> >> >>>>> What most experimenters take for granted before they begin their
>> >> >>>>> experiments
>> >> >>>>> is infinitely more interesting than any results to which their
>> >> >>>>> experiments
>> >> >>>>> lead.
>> >> >>>>> -- Norbert Wiener
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>> --
>> >> >>>> -----------------------------------------------------
>> >> >>>> Dharmendar Reddy Palle
>> >> >>>> Graduate Student
>> >> >>>> Microelectronics Research center,
>> >> >>>> University of Texas at Austin,
>> >> >>>> 10100 Burnet Road, Bldg. 160
>> >> >>>> MER 2.608F, TX 78758-4445
>> >> >>>> e-mail: dharmareddy84 at gmail.com
>> >> >>>> Phone: +1-512-350-9082
>> >> >>>> United States of America.
>> >> >>>> Homepage: https://webspace.utexas.edu/~dpr342
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>> --
>> >> >>> -----------------------------------------------------
>> >> >>> Dharmendar Reddy Palle
>> >> >>> Graduate Student
>> >> >>> Microelectronics Research center,
>> >> >>> University of Texas at Austin,
>> >> >>> 10100 Burnet Road, Bldg. 160
>> >> >>> MER 2.608F, TX 78758-4445
>> >> >>> e-mail: dharmareddy84 at gmail.com
>> >> >>> Phone: +1-512-350-9082
>> >> >>> United States of America.
>> >> >>> Homepage: https://webspace.utexas.edu/~dpr342
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> -----------------------------------------------------
>> >> >> Dharmendar Reddy Palle
>> >> >> Graduate Student
>> >> >> Microelectronics Research center,
>> >> >> University of Texas at Austin,
>> >> >> 10100 Burnet Road, Bldg. 160
>> >> >> MER 2.608F, TX 78758-4445
>> >> >> e-mail: dharmareddy84 at gmail.com
>> >> >> Phone: +1-512-350-9082
>> >> >> United States of America.
>> >> >> Homepage: https://webspace.utexas.edu/~dpr342
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> -----------------------------------------------------
>> >> Dharmendar Reddy Palle
>> >> Graduate Student
>> >> Microelectronics Research center,
>> >> University of Texas at Austin,
>> >> 10100 Burnet Road, Bldg. 160
>> >> MER 2.608F, TX 78758-4445
>> >> e-mail: dharmareddy84 at gmail.com
>> >> Phone: +1-512-350-9082
>> >> United States of America.
>> >> Homepage: https://webspace.utexas.edu/~dpr342
>> >
>> >
>> >
>> >
>> > --
>> > What most experimenters take for granted before they begin their
>> > experiments
>> > is infinitely more interesting than any results to which their
>> > experiments
>> > lead.
>> > -- Norbert Wiener
>>
>>
>>
>> --
>> -----------------------------------------------------
>> Dharmendar Reddy Palle
>> Graduate Student
>> Microelectronics Research center,
>> University of Texas at Austin,
>> 10100 Burnet Road, Bldg. 160
>> MER 2.608F, TX 78758-4445
>> e-mail: dharmareddy84 at gmail.com
>> Phone: +1-512-350-9082
>> United States of America.
>> Homepage: https://webspace.utexas.edu/~dpr342
>
>
>
>
> --
> What most experimenters take for granted before they begin their experiments
> is infinitely more interesting than any results to which their experiments
> lead.
> -- Norbert Wiener
--
-----------------------------------------------------
Dharmendar Reddy Palle
Graduate Student
Microelectronics Research center,
University of Texas at Austin,
10100 Burnet Road, Bldg. 160
MER 2.608F, TX 78758-4445
e-mail: dharmareddy84 at gmail.com
Phone: +1-512-350-9082
United States of America.
Homepage: https://webspace.utexas.edu/~dpr342
More information about the petsc-users
mailing list