SNES Problem
Barry Smith
bsmith at mcs.anl.gov
Fri Mar 17 17:45:57 CST 2006
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? Does the TS time-step size? also change dramatically at
that point?
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
>
>
More information about the petsc-users
mailing list