[petsc-users] no-debug-mode problem

[Satish Balay]

There could still be bugs in the code. Have you tried valgrind as suggested?

Satish

On Fri, 28 Jun 2013, Longxiang Chen wrote:

> I find that the fortran program cannot add optimization flag (-O2 or -O3)
> if I use gfortran-4.7.2 or ifort to compile.
> When I change the compiler to gfortran-4.4, now the --with-debug=0 (adding
> -O3) works.
> 
> Thank you all.
> 
> Best regards,
> Longxiang Chen
> 
> 
> 
> 
> On Fri, Jun 28, 2013 at 3:25 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
> 
> >
> >   Run both debugged and optimized versions with valgrind:
> > http://www.mcs.anl.gov/petsc/documentation/faq.html#valgrind
> >
> >    Barry
> >
> > On Jun 28, 2013, at 3:30 PM, Longxiang Chen <suifengls at gmail.com> wrote:
> >
> > > A is formed by three arrays IA[NZ], JA[NZ] and VA[NZ]
> > > IA[i] is row index, JA[i] is column index and VA[i] is the value in
> > (IA[i], JA[i]).
> > >
> > > For intel compiler:
> > > when I use --with-debugging=0, the VA[] is not correct. I don't know
> > what kind of optimization it does.
> > >
> > > A[0][0] = 1.000000e-25
> > > A[0][1] = 0.000000e+00
> > > A[0][2] = 0.000000e+00
> > > A[1][0] = 0.000000e+00
> > > A[1][1] = -3.479028e+02
> > > A[1][2] = 0.000000e+00
> > > A[2][0] = 0.000000e+00
> > > A[2][1] = 0.000000e+00
> > > A[2][2] = -3.479028e+02
> > > A[3][3] = 1.000000e-25
> > > ...
> > >
> > > CORRECT:
> > > A[0][0] = -2.961372e-07
> > > A[0][1] = 1.160201e+02
> > > A[0][2] = 2.744589e+02
> > > A[1][0] = 0.000000e+00
> > > A[1][1] = -3.479028e+02
> > > A[1][2] = 0.000000e+00
> > > A[2][0] = -8.332708e-08
> > > A[2][1] = 0.000000e+00
> > > A[2][2] = -3.479028e+02
> > > A[3][3] = -3.027917e-07
> > > ...
> > >
> > > For gcc-4.7.2:
> > > when I use --with-debugging=0, the fortran main function cannot read
> > input data before it starts the LOOP, the ksp_solver() is called inside the
> > loop.
> > > ===>
> > >  ERRONEOUS DATA INITIALIZATION            STOP EXECUTION---------
> > >
> > > Best regards,
> > > Longxiang Chen
> > >
> > > Do something everyday that gets you closer to being done.
> > >
> > >
> > >
> > > On Thu, Jun 27, 2013 at 6:42 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
> > >
> > > On Jun 27, 2013, at 2:23 PM, Tabrez Ali <stali at geology.wisc.edu> wrote:
> > >
> > > > Fortran can be tricky.
> > > >
> > > > Try to run the program in valgrind and/or recheck all your arguments.
> > I once forgot MatAssemblyType in the call to MatAssembly and the code still
> > ran fine on one machine but failed on other. It is better to test with at
> > least 2-3 compilers (GNU, Solaris and Open64 Fortran/C compilers are all
> > free on Linux).
> > > >
> > > > T
> > >
> > >    You can also run both versions with -snes_monitor -ksp_monitor and
> > see if they both start out the same way.
> > >
> > >    Barry
> > >
> > > >
> > > >
> > > > On 27.06.2013 14:52, Longxiang Chen wrote:
> > > >> Dear all,
> > > >>
> > > >> I use ksp_solver to solve Ax=b, where A is from an outer loop of PDE.
> > > >> Under debug mode(default), it solves the problem in about 4000
> > > >> iterations.
> > > >> And the final answer is correct (comparing to another solver).
> > > >>
> > > >> I use intel compiler.
> > > >> The program is in Fortran (by mpif90), except the solver is in c (by
> > > >> mpicc).
> > > >>
> > > >> However, when I re-configure with --with-debugging=0 (the only
> > > >> change),
> > > >> the program terminates in about 30 iterations with the wrong final
> > > >> solution.
> > > >>
> > > >> Thank you.
> > > >>
> > > >> Best regards,
> > > >> Longxiang Chen
> > > >>
> > > >> Do something everyday that gets you closer to being done.
> > > >
> > >
> > >
> >
> >
>