SNES Problem

Fri Mar 17 18:05:29 CST 2006

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