SNES Problem

Nils Erik Svangård nilserik at gmail.com
Mon Mar 20 07:36:18 CST 2006


Hi again,
I thought that I would comment on the diff from last being 0.90 all
the time. That is because a error in calculation (by me).

 do IMESH=1,NMESH
     NMPL=NMP(IMESH)
     NIL = NI(IMESH)
     NJL = NJ(IMESH)
     NKL = NK(IMESH)
       do K=1,NKL-1
         do J=1,NJL-1
           do I=1,NIL-1
              L=I+NIL*(J-1)+NIL*NJL*(K-1)+NMPL
              count=count+1
              DRO(L)=magic()
           end do
         end do
      end do
  end do

count after a run is 8019 and L is 8899, so the vector containg the
solution also have a couple of zeros in the middle, could this effect
the SNES solver?

/nisse


On 3/20/06, Nils Erik Svangård <nilserik at gmail.com> wrote:
> Hi,
> The timestep doesnt change dramaticly just before the values get
> strange. The term diff from last is:
> a=new_value(L)/old_value(L)+a
> Diff from last=a/L
> To me it seems as something petsc does supplies strange values.
> The output berfore crashing:
>
>
>  Iterering:   667.000
>  H2T
>  Timestep:   1.000000000000000E-007
>  H1T
>  Diff from last:   0.901112485562141
>  AUXVR
>  ROMIN,ROMAX=   1.22541  1.22657
>  UMIN ,UMAX =  -4.016098E-02  0.278343
>  VMIN ,VMAX =  -1.853829E-03  3.289763E-02
>  WMIN ,WMAX =  -1.852430E-03  1.855088E-03
>  PMIN ,PMAX =   101283.  101416.
>  QMIN ,QMAX =   0.815285  0.816229
>  EMIN ,EMAX =   4.07643  4.08175
>  V3
>  Hello CONV4
>  RUS:   12.2556
>  V4
>  DIFF3
>  F3
>  Iterering:   668.000
>  H2T
>  Timestep:   1.000000000000000E-007
>  H1T
>  Diff from last:   0.901112485562141
>  AUXVR
>  ROMIN,ROMAX=   1.22541  1.22657
>  UMIN ,UMAX =  -4.016098E-02  0.278343
>  VMIN ,VMAX =  -1.853829E-03  3.289763E-02
>  WMIN ,WMAX =  -1.852430E-03  1.855088E-03
>  PMIN ,PMAX =   101283.  101416.
>  QMIN ,QMAX =   0.815285  0.816229
>  EMIN ,EMAX =   4.07643  4.08175
>  V3
>  Hello CONV4
>  RUS:   12.2556
>  V4
>  DIFF3
>  F3
>  Iterering:   669.000
>  H2T
>  Timestep:   1.000000000000000E-007
>  H1T
>  Diff from last:   1.785767662774350E-006
>  AUXVR
> --------------------------------------------------------------------------
> Petsc Release Version 2.3.0, Patch 32, April, 26, 2005
> See docs/changes/index.html for recent updates.
> See docs/faq.html for hints about trouble shooting.
> See docs/index.html for manual pages.
> -----------------------------------------------------------------------
> ./withrk on a linux-gnu named sethnx004.vac.com by yy26539 Mon Mar 20
> 10:17:33 2006
> Libraries linked from /home/yy26539/work/NISSE/petsc-2.3.0/lib/linux-gnu
> Configure run at Thu Oct 13 08:23:56 2005
> Configure options --with-cc=gcc --with-fc="f77 -N109"
> --download-mpich=1 --download-mpich-pm=gforker
> --download-f-blas-lapack=1 --with-shared=0
> -----------------------------------------------------------------------
> [0]PETSC ERROR: Caught signal number 8 FPE: Floating Point
> Exception,probably divide by zero
> [0]PETSC ERROR: Try option -start_in_debugger or -on_error_attach_debugger
> [0]PETSC ERROR: likely location of problem given in stack below
> [0]PETSC ERROR: --------------- Stack Frames ---------------
> [0]PETSC ERROR: Note: The EXACT line numbers in the stack are not available,
> [0]PETSC ERROR:       INSTEAD the line number of the start of the function
> [0]PETSC ERROR:       is given.
> [0]PETSC ERROR: [0] SNESComputeFunction line 788 src/snes/interface/snes.c
> [0]PETSC ERROR: [0] MatMult_MFFD line 235 src/snes/mf/snesmfj.c
> [0]PETSC ERROR: [0] MatMult line 1368 src/mat/interface/matrix.c
> [0]PETSC ERROR: [0] SNESLSCheckLocalMin_Private line 19 src/snes/impls/ls/ls.c
> [0]PETSC ERROR: [0] SNESSolve line 1656 src/snes/interface/snes.c
> [0]PETSC ERROR: --------------------------------------------
> [0]PETSC ERROR: User provided function() line 0 in unknown directory
> unknown file
> [0]PETSC ERROR: Signal received!
> [0]PETSC ERROR:  !
> aborting job:
> application called MPI_Abort(MPI_COMM_WORLD, 59) - process 0
>
>
> /nisse
>
> On 3/18/06, Nils Erik Svangård <nilserik at gmail.com> wrote:
> > On 3/18/06, Barry Smith <bsmith at mcs.anl.gov> wrote:
> > >
> > >    So you are saying that TS is feeding "reasonable" input
> > > for a while? That basically matches (in scale) the values feed in
> > > from the old rk code? Then SUDDENLY? it inputs values with a very
> > > different size?
> >
> > Yes.
> >
> > > Does the TS time-step size? also change dramatically at
> > > that point?
> > >
> >
> > No, I dont think so. However I'm not 100% sure what the timestep
> > hasent changed dramatically for the last iteration when it crashes
> > (but 95% sure). I can check that on monday.
> >
> > /nisse
> >
> > >     Barry
> > >
> > >
> > > On Sat, 18 Mar 2006, Nils Erik Svangård wrote:
> > >
> > > > On 3/17/06, Barry Smith <bsmith at mcs.anl.gov> wrote:
> > > >>
> > > >>    Based on my understanding. This is correct.
> > > >
> > > > I was almost hoping I had missed something fundamental.
> > > >
> > > >>
> > > >>    Suggest you run a TINY problem with your "old" code
> > > >> and the TS (and or SNES one). Print out everything. The
> > > >> current solution the result from calling Get_DRO() and
> > > >> compare the runs, when and why do they change? This will
> > > >> help understand what is going on.
> > > >
> > > > Well, Get_DRO() is exactly the same in the old and new code, and they
> > > > start with the same initial values. Get_DRO() is not producing strange
> > > > values, it is crashing because it get strange values fed into it.
> > > >
> > > > A normal run for the formfunction f(in,out) in TS would look something
> > > > like this if printed:
> > > > in=25560         <- Start value
> > > > out=0.0001     <-  du/dt
> > > > in=25560         <- Value fed into formfunction after some TS magic
> > > > out=0.0001      <- du/dt
> > > > ...                      <- (a couple iterations)
> > > > in=25451          <- Input value after a couple of iterations
> > > > out=0.0001      <- du/dt
> > > > in=0.23151       <- Value fed into formfunction decided by TS
> > > > Petscerror divide by zero...
> > > >
> > > > The problem seems to be that TS decides that the input values to
> > > > formfunction should be (in this case) 0.23151 which makes Get_DRO()
> > > > crash because of  for example sqrt(in-1).
> > > >
> > > > I have no idea how to fix this. The values from Get_DRO() in TS match
> > > > the values when running the old rk code.
> > > >
> > > > /nisse
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >>
> > > >>     Barry
> > > >>
> > > >>
> > > >> On Fri, 17 Mar 2006, Nils Erik Svangård wrote:
> > > >>
> > > >>> Ok, I managed to compile and link rk.c to my fortran program, I forgot
> > > >>> that in C you need a ;  in the end of every statement. (stupid mistake
> > > >>> ;) )
> > > >>>
> > > >>> I have just added one line to see if it works.
> > > >>>
> > > >>>  /* computing new dt */
> > > >>>     dt = dt * dt_fac;
> > > >>>
> > > >>>     /* Start Nisse stuff */
> > > >>>        ierr = PetscPrintf(PETSC_COMM_WORLD,"Nisse prints dt: %f\n",dt);
> > > >>>     /* End nisse stuff */
> > > >>>
> > > >>>
> > > >>>     if(ts->ptime+dt > ts->max_time){
> > > >>>        dt = ts->max_time - ts->ptime;
> > > >>>     }
> > > >>>
> > > >>> I just try to print the current timestep, however this is never
> > > >>> printed. And I'm not really sure that it is the timestep that is
> > > >>> causing the problems.
> > > >>>
> > > >>> I have used call TSGetTimeStep(ts,timestep,ierr) to monitor what
> > > >>> timestep TS uses and it seem ok. However after the first iteration of
> > > >>> FormFunction everything seems ok, but in start of the second iteration
> > > >>> all values are really strange.
> > > >>>
> > > >>> I see the same thing when using SNES and my back euler implementation,
> > > >>> it iterate many more times however, but all of a sudden the all "in"
> > > >>> values are in the range 0.2-0.7 (for all 7 equations) and my code
> > > >>> bombs because of the strange values.
> > > >>>
> > > >>> When using TS and  running with  -snes_mf -ts_type beuler -ksp_rtol
> > > >>> 1.e-10 this is what printed just before producing strange values:
> > > >>> KSP Object:
> > > >>>  type: gmres
> > > >>>    GMRES: restart=30, using Classical (unmodified) Gram-Schmidt
> > > >>> Orthogonalization with no iterative refinement
> > > >>>    GMRES: happy breakdown tolerance 1e-30
> > > >>>  maximum iterations=10000, initial guess is zero
> > > >>>  tolerances:  relative=1e-10, absolute=1e-50, divergence=10000
> > > >>>  left preconditioning
> > > >>> PC Object:
> > > >>>  type: none
> > > >>>  linear system matrix = precond matrix:
> > > >>>  Matrix Object:
> > > >>>    type=mffd, rows=70000, cols=70000
> > > >>>        SNES matrix-free approximation:
> > > >>>          err=1e-07 (relative error in function evaluation)
> > > >>>          Using wp compute h routine
> > > >>>          Computes normA
> > > >>>
> > > >>>
> > > >>> And just to make sure that I havent misunderstood how SNES and TS work:
> > > >>> If the original 3-stage RK uses (my numbering):
> > > >>> 1.  RO0(L)=RO(L)
> > > >>>     Get_DRO(RO(L))
> > > >>>     RO(L)=RO0(L)+CFL*DRO(L)
> > > >>> 2.  RO0(L)=.5*(RO0(L)+RO(L))
> > > >>>     Get_DRO(RO(L))
> > > >>>     RO(L)=RO0(L)+.5*CFL*DRO(L)
> > > >>> 3.  Get_DRO(RO(L))
> > > >>>     RO(L)=RO0(L)+.5*CFL*DRO(L)
> > > >>>
> > > >>> Then this should be in TS which should return du/dt which is DRO:
> > > >>>      RO(L)=xx(1,L)
> > > >>>      Get_DRO(RO(L))
> > > >>>      ff(1,L) = DRO(L)
> > > >>>
> > > >>> And in SNES with back euler:
> > > >>>      (Old RO from previous iteration ORO(L)
> > > >>>      RO(L)=xx(1,L)
> > > >>>      Get_DRO(RO(L))
> > > >>>      ff(1,L)= RO(L)-OLD(1,L)-TSF(L)*DRO(L)
> > > >>>
> > > >>>
> > > >>> This became a long mail, I hope this shows if I missed something vital.
> > > >>> /nisse
> > > >>> On 3/16/06, Nils Erik Svangård <nilserik at gmail.com> wrote:
> > > >>>> Barry,
> > > >>>> the problem is making the objectfile, but I'll try again when I have
> > > >>>> the code. I will check the makefile for the c-examples.
> > > >>>> /nisse
> > > >>>>
> > > >>>> On 3/16/06, Barry Smith <bsmith at mcs.anl.gov> wrote:
> > > >>>>>
> > > >>>>>    Nisse,
> > > >>>>>
> > > >>>>>      Just list it in your makefile with all your other object
> > > >>>>> files (that come from Fortran). Send the output if this fails.
> > > >>>>>
> > > >>>>>     Barry
> > > >>>>>
> > > >>>>>
> > > >>>>> On Thu, 16 Mar 2006, Nils Erik Svangård wrote:
> > > >>>>>
> > > >>>>>> I havent managed to get rk.c compiled with changes. how do I compile
> > > >>>>>> it in my working directory to get a object file. I just realised that
> > > >>>>>> I probably forgot to link it against $TSLIB but should I need to that
> > > >>>>>> when I dont do any linking, the linking is done when linking the
> > > >>>>>> fortran and the c code?
> > > >>>>>> Or what am I doing wrong (I not that good with C++ and linking).
> > > >>>>>> /nisse
> > > >>>>>>
> > > >>>>>> On 3/15/06, Barry Smith <bsmith at mcs.anl.gov> wrote:
> > > >>>>>>>
> > > >>>>>>>    Both
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>> On Wed, 15 Mar 2006, Nils Erik Svangård wrote:
> > > >>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>    Sorry, I forgot. Is the linear solver converging? If not, then that
> > > >>>>>>>>> is the problem? Use a tolerance like -ksp_rtol 1.e-10 and see if the
> > > >>>>>>>>> nonlinear solver converges.
> > > >>>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> I'll try that when I have access to the code. I havent checked if the
> > > >>>>>>>> linear solver converges is thera a -kspmonitor or -kspconvergedreason
> > > >>>>>>>> I should use?
> > > >>>>>>>>
> > > >>>>>>>> /nisse
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> --
> > > >>>>>> Nils-Erik Svangård
> > > >>>>>> E-Mail: nilserik at gmail.com
> > > >>>>>> MSN: schweingaard at hotmail.com
> > > >>>>>> Skype: schweingaard
> > > >>>>>> Mobil: +46-(0)70-3612178
> > > >>>>>>
> > > >>>>>>
> > > >>>>>
> > > >>>>
> > > >>>>
> > > >>>> --
> > > >>>> Nils-Erik Svangård
> > > >>>> E-Mail: nilserik at gmail.com
> > > >>>> MSN: schweingaard at hotmail.com
> > > >>>> Skype: schweingaard
> > > >>>> Mobil: +46-(0)70-3612178
> > > >>>>
> > > >>>
> > > >>>
> > > >>> --
> > > >>> Nils-Erik Svangård
> > > >>> E-Mail: nilserik at gmail.com
> > > >>> MSN: schweingaard at hotmail.com
> > > >>> Skype: schweingaard
> > > >>> Mobil: +46-(0)70-3612178
> > > >>>
> > > >>>
> > > >>
> > > >
> > > >
> > > > --
> > > > Nils-Erik Svangård
> > > > E-Mail: nilserik at gmail.com
> > > > MSN: schweingaard at hotmail.com
> > > > Skype: schweingaard
> > > > Mobil: +46-(0)70-3612178
> > > >
> > > >
> > >
> >
> >
> > --
> > Nils-Erik Svangård
> > E-Mail: nilserik at gmail.com
> > MSN: schweingaard at hotmail.com
> > Skype: schweingaard
> > Mobil: +46-(0)70-3612178
> >
>
>
> --
> Nils-Erik Svangård
> E-Mail: nilserik at gmail.com
> MSN: schweingaard at hotmail.com
> Skype: schweingaard
> Mobil: +46-(0)70-3612178
>


--
Nils-Erik Svangård
E-Mail: nilserik at gmail.com
MSN: schweingaard at hotmail.com
Skype: schweingaard
Mobil: +46-(0)70-3612178




More information about the petsc-users mailing list