Nisse,
Yes. You need to make sure that all the entries computed in your FormFunction() are correctly F_i(x) for 0 <= i < globalvectorlength!! The "zeros" will destroy the Newton convergence since the Jacobian will be singular, plus if the "zeros" are actually random "garbage" because the memory has not be initialized that will really screw things up.
Barry
On Mon, 20 Mar 2006, Nils Erik Svangård wrote:
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@xxxxxxxxx> 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@xxxxxxxxx> wrote:On 3/18/06, Barry Smith <bsmith@xxxxxxxxxxx> 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@xxxxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxxxx> 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@xxxxxxxxxxx> 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@xxxxxxxxx MSN: schweingaard@xxxxxxxxxxx Skype: schweingaard Mobil: +46-(0)70-3612178
-- Nils-Erik Svangård E-Mail: nilserik@xxxxxxxxx MSN: schweingaard@xxxxxxxxxxx Skype: schweingaard Mobil: +46-(0)70-3612178
-- Nils-Erik Svangård E-Mail: nilserik@xxxxxxxxx MSN: schweingaard@xxxxxxxxxxx Skype: schweingaard Mobil: +46-(0)70-3612178
-- Nils-Erik Svangård E-Mail: nilserik@xxxxxxxxx MSN: schweingaard@xxxxxxxxxxx Skype: schweingaard Mobil: +46-(0)70-3612178
-- Nils-Erik Svangård E-Mail: nilserik@xxxxxxxxx MSN: schweingaard@xxxxxxxxxxx Skype: schweingaard Mobil: +46-(0)70-3612178
-- Nils-Erik Svangård E-Mail: nilserik@xxxxxxxxx MSN: schweingaard@xxxxxxxxxxx Skype: schweingaard Mobil: +46-(0)70-3612178
-- Nils-Erik Svangård E-Mail: nilserik@xxxxxxxxx MSN: schweingaard@xxxxxxxxxxx Skype: schweingaard Mobil: +46-(0)70-3612178