From bsmith at mcs.anl.gov Fri Mar 17 15:16:14 2006 From: bsmith at mcs.anl.gov (Barry Smith) Date: Fri, 17 Mar 2006 15:16:14 -0600 (CST) Subject: SNES Problem In-Reply-To: <82f936c20603170156p42b1d4ecucde71da67053e517@mail.gmail.com> References: <82f936c20602270607t775d7e03o6a37afa4c0b3d2a8@mail.gmail.com> <82f936c20603150847s4b0a027aw7a2077723f5e86c9@mail.gmail.com> <82f936c20603151431t45e675f4hf664822d91bd72af@mail.gmail.com> <82f936c20603151450u23910e93pe3c518eea288d216@mail.gmail.com> <82f936c20603161117j23c6997bt6ed179a82be12a17@mail.gmail.com> <82f936c20603161445i60f1ac8cvcdbf35c191d62603@mail.gmail.com> <82f936c20603170156p42b1d4ecucde71da67053e517@mail.gmail.com> Message-ID: Based on my understanding. This is correct. 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. 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 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 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 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 > > From billy at dem.uminho.pt Wed Mar 1 10:51:33 2006 From: billy at dem.uminho.pt (billy at dem.uminho.pt) Date: Wed, 1 Mar 2006 16:51:33 +0000 Subject: VecAssembly? Message-ID: <1141231893.4405d1150dbf8@serv-g1.ccom.uminho.pt> After setting values to a sequential vector, do I need to call VecAssmblyBegin(), VecAssemblyEnd()? Billy. From hzhang at mcs.anl.gov Wed Mar 1 11:14:34 2006 From: hzhang at mcs.anl.gov (Hong Zhang) Date: Wed, 1 Mar 2006 11:14:34 -0600 (CST) Subject: VecAssembly? In-Reply-To: <1141231893.4405d1150dbf8@serv-g1.ccom.uminho.pt> References: <1141231893.4405d1150dbf8@serv-g1.ccom.uminho.pt> Message-ID: On Wed, 1 Mar 2006 billy at dem.uminho.pt wrote: > > After setting values to a sequential vector, do I need to call > VecAssmblyBegin(), VecAssemblyEnd()? Yes. Hong From balay at mcs.anl.gov Wed Mar 1 11:19:46 2006 From: balay at mcs.anl.gov (Satish Balay) Date: Wed, 1 Mar 2006 11:19:46 -0600 (CST) Subject: VecAssembly? In-Reply-To: References: <1141231893.4405d1150dbf8@serv-g1.ccom.uminho.pt> Message-ID: On Wed, 1 Mar 2006, Hong Zhang wrote: > > > On Wed, 1 Mar 2006 billy at dem.uminho.pt wrote: > > > > > After setting values to a sequential vector, do I need to call > > VecAssmblyBegin(), VecAssemblyEnd()? > > Yes. Hong If you use VecSetValues() then yes VecAssmblyBegin()/End() need to be called. If you use VecGetArray() and change local values - you just need to call VecRestoreArray() [i.e VecAssemblyBegin/End() calls are not necessary] Satish From billy at dem.uminho.pt Wed Mar 1 13:54:24 2006 From: billy at dem.uminho.pt (billy at dem.uminho.pt) Date: Wed, 1 Mar 2006 19:54:24 +0000 Subject: Matrix solvers? Message-ID: <1141242864.4405fbf0eef9e@serv-g1.ccom.uminho.pt> Hi, I am using a single computer and several processes. I am using KSPGMRES for solving matrices. When I use increase the number of processes I have problems solving the matrix. Is there a more optimized solver for parallel processing? When I update ghost cells information with VecGhostUpdateBegin/End() do I need to call MPI_Barrier to assure that all ghost information is updated before proceeding or is this already done by the VecGhostUpdateBegin/End()? I have it almost working. Thanks for your help. Billy. From knepley at mcs.anl.gov Wed Mar 1 14:09:10 2006 From: knepley at mcs.anl.gov (Matthew Knepley) Date: Wed, 01 Mar 2006 14:09:10 -0600 Subject: Matrix solvers? In-Reply-To: <1141242864.4405fbf0eef9e@serv-g1.ccom.uminho.pt> (billy@dem.uminho.pt's message of "Wed, 1 Mar 2006 19:54:24 +0000") References: <1141242864.4405fbf0eef9e@serv-g1.ccom.uminho.pt> Message-ID: billy at dem.uminho.pt writes: > Hi, > > I am using a single computer and several processes. I am using KSPGMRES for > solving matrices. When I use increase the number of processes I have problems > solving the matrix. Is there a more optimized solver for parallel processing? Yes, you should investigate the DMMG examples. This is geometric multigrid for structured meshes. Since you have an unstructured mesh, it is more complicated. We are working on this,but it is not ready yet. However, you can try using ASM which should scale better. > When I update ghost cells information with VecGhostUpdateBegin/End() do I need > to call MPI_Barrier to assure that all ghost information is updated before > proceeding or is this already done by the VecGhostUpdateBegin/End()? No, that is in the End() call. Matt -- "Failure has a thousand explanations. Success doesn't need one" -- Sir Alec Guiness From nilserik at gmail.com Thu Mar 2 07:29:35 2006 From: nilserik at gmail.com (=?ISO-8859-1?Q?Nils_Erik_Svang=E5rd?=) Date: Thu, 2 Mar 2006 14:29:35 +0100 Subject: SNES Problem In-Reply-To: References: <82f936c20602270607t775d7e03o6a37afa4c0b3d2a8@mail.gmail.com> Message-ID: <82f936c20603020529j6d4181c8pc75c980357df9aa3@mail.gmail.com> Hi again, I realised that my implementation was a bit flawed so I have rewritten it again, the push and pop() functions dont seem to work, and they are keeping me from compiling the program, this is the main timestep loop: call VecCreateSeq(PETSC_COMM_SELF,N,x,ierr) call VecDuplicate(x,r,ierr) call VecDuplicate(x,xb,ierr) call SNESCreate(PETSC_COMM_SELF,snes,ierr) call SNESSetFunction(snes,r,FormFunction,PETSC_NULL_OBJECT,ierr) call SNESSetFromOptions(snes,ierr) call FormInitialGuess(x,ierr) call VecCopy(x,xb,ierr) write(6,*)zero,dt,tmax,i1000 step=0 timestep=dt C While loop 10 if (step .le. 100) then call PetscExceptionPush(87,ierr) call SNESSolve(snes,PETSC_NULL_OBJECT,x,ierr) call PetscExceptionPop(87,ierr2) call SNESGetConvergedReason(snes,reason,ierr) IF ( reason .LT. 0 ) THEN timestep=timestep/2 VecCopy(xb,x,ierr) write(6,*)"Solution diverged, trying with", . " smaller timestep: ",timestep ELSE IF ( ierr .EQ. 87) THEN timestep=timestep/2 VecCopy(xb,x,ierr) write(6,*) "No physical solution, trying", . " with smaller timestep: ",timestep ELSE timestep=dt step=step+1 VecCopy(x,xb,ierr) write(6,*) "Solve success, going for step: ",step ENDIF ENDIF goto 10 endif C End While loop And in my Formfunction I have added the following check: if (ET(L) .LT. 0) then ierr = 87 return endif PETSC_ERR_ARG_DOMAIN didnt work: error on line 6500 of SNESG3D2.F: data type is undefined for variable PETSC_ERR_ARG_DOMAIN Even thought I had petsc.h included. Can I do this check when I use TS also? I have the sameproblem with the values being negative when using TS. /nisse On 2/27/06, Barry Smith wrote: > > SNES works by computing p = -approxinv(J)*F(uold) and > then does a line search on unew = uold + lambda*p to get the > new u. First it uses a test value of 1 for lambda so it > tries to compute F(uold + p). It is possible that uold + p > has some "non-physical" values in it. There are two ways > you can try handling it: > > 1) Before doing the linesearch SNES calls a "precheck" function, > that can change the step if it decides there is a problem > with the step (like it is too long). You can provide your > own precheck function with SNESLineSearchSetPreCheck() it could, > for example, shrink the Newton direction to make it remain physical. > > or 2) when your form function detects an illegal value it calls > SETERRQ(PETSC_ERR_ARG_DOMAIN,"Nonphysical function input"); Note: > this is before it takes the square root of the negative number, > so check the number and call the error before calling SETERRQ(). > (If using Fortran then simply set ierr = PETSC_ERR_ARG_DOMAIN and > then immediately return). Then replace your call to SNESSolve with > ierr = PetscExceptionTry1(SNESSolve(snes,b,x),PETSC_ERR_ARG_DOMAIN); > if (PetscExceptionCaught(ierr,PETSC_ERR_ARG_DOMAIN)) { > /* this means your function found a non-physical value so > cut your time-step and continue through the loop again. */ > Put code to do this here. > } > If using fortran then do > call PetscExceptionPush(PETSC_ERR_ARG_DOMAIN,ierr) > call SNESSolve(snes,b,x,ierr) > call PetscExceptionPop(PETSC_ERR_ARG_DOMAIN,anotherierr) > if (ierr == PETSC_ERR_ARG_DOMAIN) then > non-physical value so cut the time-step and try again > else ! everything is normal so take the next time-step > > Barry > > The Fortran interface may be missing PetscExceptionPush() and Pop() > if so let us know and we'll provide the patch. > > On Mon, 27 Feb 2006, Nils Erik Svang?rd wrote: > > > Hi all, > > > > I have problems solving some CFD problems using SNES and my custom > > back-euler. I have 7 equations that I want to solve. > > > > First my FormFunction copies the values from the Vec that SNES uses to > > the variables that my code use: > > > > RO(L)=xx(1,L) > > RU(L)=xx(2,L) > > RV(L)=xx(3,L) > > RW(L)=xx(4,L) > > ET(L)=xx(5,L) > > RQ(L)= xx(6,L) > > REPS(L)=xx(7,L) > > > > Here I also print the values of ET(2) for debugging: > > > > write(6,*)"ET(2) = xx(5,2) : ",ET(2)," = ",xx(5,2) > > > > Then I get the fluxes by calling custom functions > > > > call AUXVR > > call VGRAD > > call FLUX > > call KESRC > > > > Then I perform back-euler save the new value to so that I can use it > > in the next iterationi (TSF(L) is Time step function, which is set by > > hand and is the same for all L): > > > > ff(1,L) = RO(L)-OLD(1,L)-TSF(L)*DRO(L) > > ff(2,L) = RU(L)-OLD(2,L)-TSF(L)*DRU(L) > > ff(3,L) = RV(L)-OLD(3,L)-TSF(L)*DRV(L) > > ff(4,L) = RW(L)-OLD(4,L)-TSF(L)*DRW(L) > > ff(5,L) = ET(L)-OLD(5,L)-TSF(L)*DET(L) > > ff(6,L) = RQ(L)-OLD(6,L)-TSF(L)*DRQ(L) > > ff(7,L) = REPS(L)-OLD(7,L)-TSF(L)*DREPS(L) > > > > And save the new value of RO-REPS to use in the next iteration of back-euler: > > > > OLD(1,L)=RO(L) > > OLD(2,L)=RU(L) > > OLD(3,L)=RV(L) > > OLD(4,L)=RW(L) > > OLD(5,L)=ET(L) > > OLD(6,L)=RQ(L) > > OLD(7,L)=REPS(L) > > > > Here I print the values of L=2 as above for debugging: > > > > write(6,*)ff(5,2)," = ",ET(2),"-",OLD(5,2),"-",TSF(2),"*",DET(2) > > > > > > > > The program exit abnormaly after 33 runs of the FormFunction. The > > cause of this is that AUXVR tries to perform sqrt(ET(2)) when ET(2) is > > negative, ET is the total energy and should never be negative. It > > seems that all of a sudden the PETSc SNES solver decides to supply the > > FormFunction with a negative ET value. I need help understanding why > > and how to fix it (if it is fixable). > > > > Here is the output of: > > write(6,*)"ET(2) = xx(5,2) : ",ET(2)," = ",xx(5,2) > > Which is in the beginning of my FormFunction. > > And: > > write(6,*)ff(5,2)," = ",ET(2),"-",OLD(5,2),"-",TSF(2),"*",DET(2) > > Which is in the end of my Formfunction. > > > > 1. ET(2) = xx(5,2) : 253250. = 253250.000000000 > > ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > > 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > > 2. ET(2) = xx(5,2) : 253250. = 253250.000010259 > > ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > > 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > > 3. ET(2) = xx(5,2) : 253250. = 253249.999999988 > > ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4132419437260 = > > 253250. - 253250.000000000 - 1.000000E-07 * -2.941324E+08 > > 4. ET(2) = xx(5,2) : 253250. = 253250.000048432 > > ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > > 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > > 5. ET(2) = xx(5,2) : 253250. = 253249.999999872 > > ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4177283437784 = > > 253250. - 253250.000000000 - 1.000000E-07 * -2.941773E+08 > > 6. ET(2) = xx(5,2) : 253250. = 253250.000071113 > > ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > > 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > > 7. ET(2) = xx(5,2) : 253250. = 253249.999980115 > > ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4453347441010 = > > 253250. - 253250.000000000 - 1.000000E-07 * -2.944533E+08 > > 8. ET(2) = xx(5,2) : 253250. = 253250.000037298 > > ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4082723436679 = > > 253250. - 253250.000000000 - 1.000000E-07 * -2.940827E+08 > > 9. ET(2) = xx(5,2) : 253250. = 253249.999942706 > > ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4082723436679 = > > 253250. - 253250.000000000 - 1.000000E-07 * -2.940827E+08 > > 10. ET(2) = xx(5,2) : 253250. = 253249.999948703 > > ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > > 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > > 11. ET(2) = xx(5,2) : 253250. = 253250.000007808 > > ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.7283811474088 = > > 253250. - 253250.000000000 - 1.000000E-07 * -2.972838E+08 > > 12. ET(2) = xx(5,2) : 253250. = 253250.000018146 > > ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > > 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > > 13. ET(2) = xx(5,2) : 253250. = 253250.000001865 > > ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 28.3742819315846 = > > 253250. - 253250.000000000 - 1.000000E-07 * -2.837428E+08 > > 14. ET(2) = xx(5,2) : 253250. = 253249.999997296 > > ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > > 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > > 15. ET(2) = xx(5,2) : 253250. = 253250.000000049 > > ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 30.6548963582361 = > > 253250. - 253250.000000000 - 1.000000E-07 * -3.065490E+08 > > 16. ET(2) = xx(5,2) : 253250. = 253250.000022870 > > ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > > 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > > 17. ET(2) = xx(5,2) : 253250. = 253249.999999716 > > ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.5326051451209 = > > 253250. - 253250.000000000 - 1.000000E-07 * -2.953260E+08 > > 18. ET(2) = xx(5,2) : 253250. = 253250.000074328 > > ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4165187437643 = > > 253250. - 253250.000000000 - 1.000000E-07 * -2.941652E+08 > > 19. ET(2) = xx(5,2) : 253250. = 253250.000049809 > > ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4085059436707 = > > 253250. - 253250.000000000 - 1.000000E-07 * -2.940851E+08 > > 20. ET(2) = xx(5,2) : 253250. = 253250.000019253 > > ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > > 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > > 21. ET(2) = xx(5,2) : 253250. = 253250.000000189 > > ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.8851075492403 = > > 253250. - 253250.000000000 - 1.000000E-07 * -2.988511E+08 > > 22. ET(2) = xx(5,2) : 253250. = 253249.999997897 > > ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4085059436707 = > > 253250. - 253250.000000000 - 1.000000E-07 * -2.940851E+08 > > 23. ET(2) = xx(5,2) : 253250. = 253249.999975142 > > ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.3961539435263 = > > 253250. - 253250.000000000 - 1.000000E-07 * -2.939615E+08 > > 24. ET(2) = xx(5,2) : 253250. = 253250.000018324 > > ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4085059436707 = > > 253250. - 253250.000000000 - 1.000000E-07 * -2.940851E+08 > > 25. ET(2) = xx(5,2) : 253250. = 253249.999987073 > > ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4165187437643 = > > 253250. - 253250.000000000 - 1.000000E-07 * -2.941652E+08 > > 26. ET(2) = xx(5,2) : 253250. = 253249.999980982 > > ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4165187437643 = > > 253250. - 253250.000000000 - 1.000000E-07 * -2.941652E+08 > > 27. ET(2) = xx(5,2) : 253250. = 253249.999994645 > > ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > > 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > > 28. ET(2) = xx(5,2) : 253250. = 253249.999962364 > > ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4165187437643 = > > 253250. - 253250.000000000 - 1.000000E-07 * -2.941652E+08 > > 29. ET(2) = xx(5,2) : 253250. = 253249.999999921 > > ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > > 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > > 30. ET(2) = xx(5,2) : 253250. = 253250.000000058 > > ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 28.4019971319085 = > > 253250. - 253250.000000000 - 1.000000E-07 * -2.840200E+08 > > 31. ET(2) = xx(5,2) : 253250. = 253250.000040348 > > ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4085059436707 = > > 253250. - 253250.000000000 - 1.000000E-07 * -2.940851E+08 > > 32. ET(2) = xx(5,2) : 253250. = 253250.000005245 > > ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > > 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > > 33. ET(2) = xx(5,2) : 253250. = 253250.000005245 > > ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > > 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > > 34. ET(2) = xx(5,2) : -848141. = -848141.388090847 > > -------------------------------------------------------------------------- > > 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. > > ----------------------------------------------------------------------- > > ./SNESG3D2 on a linux-gnu named sethnx004.vac.com by yy26539 Mon Feb > > 27 14:21:13 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] SNES user function line 0 unknownunknown > > [0]PETSC ERROR: [0] SNESComputeFunction line 788 src/snes/interface/snes.c > > [0]PETSC ERROR: [0] SNESLineSearchCubic line 514 src/snes/impls/ls/ls.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: ! > > > > > > Suggestions and tips are very welcome! > > /nisse > > > > > > -- > > Nils-Erik Svang???rd > > MSN: schweingaard at hotmail.com > > Skype: schweingaard > > > > > -- Nils-Erik Svang?rd MSN: schweingaard at hotmail.com Skype: schweingaard From bsmith at mcs.anl.gov Thu Mar 2 09:29:35 2006 From: bsmith at mcs.anl.gov (Barry Smith) Date: Thu, 2 Mar 2006 09:29:35 -0600 (CST) Subject: reorganization in parallel vector scatters Message-ID: I have reorganized the code for the parallel vector scatters in preparation for future optimizations; be on the look out for subtle bugs appearing. Barry From billy at dem.uminho.pt Thu Mar 2 11:43:02 2006 From: billy at dem.uminho.pt (billy at dem.uminho.pt) Date: Thu, 2 Mar 2006 17:43:02 +0000 Subject: Matrix convergence. Message-ID: <1141321382.44072ea6da75b@serv-g1.ccom.uminho.pt> Hi, I have been testing my parallel implementation with a 2D case. I have used the following grids with 2 and 4 processes: 4x4, 10x10, 16x16 and 18x18. It works for the first three (max. number of iterations to converge aprox. 70) but when I increase to 18x18 the matrix does not converge. I have increased the maximum number of iterations and I have used GMRES, BiCGSTAB with preconditioners ASM, JACOBI, etc. With KSPType = GMRES and PCType = ASM: Number of iterations: 500 Residual: +1.420471E-01 With KSPType = GMRES and PCType = JACOBI: Number of iterations: 500 Residual: +2.351882E-02 With KSPType = BCGS and PCType = ASM: Number of iterations: 136 Residual: +3.911446E+04 With KSPType = BCGS and PCType = NULL: Number of iterations: 157 Residual: +3.254728E+03 Is it normal that the convergence detiorates so much with such a slight increase in the dimension of the matrix? Is there any optimization parameter that I may be missing? Billy. From knepley at mcs.anl.gov Thu Mar 2 12:51:11 2006 From: knepley at mcs.anl.gov (Matthew Knepley) Date: Thu, 02 Mar 2006 12:51:11 -0600 Subject: Matrix convergence. In-Reply-To: <1141321382.44072ea6da75b@serv-g1.ccom.uminho.pt> (billy@dem.uminho.pt's message of "Thu, 2 Mar 2006 17:43:02 +0000") References: <1141321382.44072ea6da75b@serv-g1.ccom.uminho.pt> Message-ID: billy at dem.uminho.pt writes: Its definitely possible. Usually you need to know something about your system in order to precondition and solve it effectively. For instance, is it the discretization of an elliptic operator? Matt > Hi, > > > I have been testing my parallel implementation with a 2D case. I have used the > following grids with 2 and 4 processes: 4x4, 10x10, 16x16 and 18x18. > > It works for the first three (max. number of iterations to converge aprox. 70) > but when I increase to 18x18 the matrix does not converge. I have increased the > maximum number of iterations and I have used GMRES, BiCGSTAB with > preconditioners ASM, JACOBI, etc. > > With KSPType = GMRES and PCType = ASM: > Number of iterations: 500 Residual: +1.420471E-01 > > With KSPType = GMRES and PCType = JACOBI: > Number of iterations: 500 Residual: +2.351882E-02 > > With KSPType = BCGS and PCType = ASM: > Number of iterations: 136 Residual: +3.911446E+04 > > With KSPType = BCGS and PCType = NULL: > Number of iterations: 157 Residual: +3.254728E+03 > > Is it normal that the convergence detiorates so much with such a slight increase > in the dimension of the matrix? Is there any optimization parameter that I may > be missing? > > > Billy. > > > -- "Failure has a thousand explanations. Success doesn't need one" -- Sir Alec Guiness From billy at dem.uminho.pt Thu Mar 2 14:43:41 2006 From: billy at dem.uminho.pt (billy at dem.uminho.pt) Date: Thu, 2 Mar 2006 20:43:41 +0000 Subject: petsc to matlab Message-ID: <1141332221.440758fd61da9@serv-g1.ccom.uminho.pt> How can I save the matrix in PETSc and load it in matlab? I tried this but it does not work: PetscViewer view; PetscViewerCreate (PETSC_COMM_WORLD, &view); PetscViewerSetFormat (view, PETSC_VIEWER_ASCII_MATLAB); PetscViewerAsciiOpen(PETSC_COMM_WORLD, "matrix.mat", &view); MatView(A, view); PetscViewerDestroy(view); Billy. From knepley at mcs.anl.gov Thu Mar 2 14:56:04 2006 From: knepley at mcs.anl.gov (Matthew Knepley) Date: Thu, 02 Mar 2006 14:56:04 -0600 Subject: petsc to matlab In-Reply-To: <1141332221.440758fd61da9@serv-g1.ccom.uminho.pt> (billy@dem.uminho.pt's message of "Thu, 2 Mar 2006 20:43:41 +0000") References: <1141332221.440758fd61da9@serv-g1.ccom.uminho.pt> Message-ID: billy at dem.uminho.pt writes: What goes wrong? Matt > How can I save the matrix in PETSc and load it in matlab? > > I tried this but it does not work: > > > PetscViewer view; > > PetscViewerCreate (PETSC_COMM_WORLD, &view); > > PetscViewerSetFormat (view, PETSC_VIEWER_ASCII_MATLAB); > > PetscViewerAsciiOpen(PETSC_COMM_WORLD, "matrix.mat", &view); > > MatView(A, view); > > PetscViewerDestroy(view); > > > > Billy. > > > -- "Failure has a thousand explanations. Success doesn't need one" -- Sir Alec Guiness From billy at dem.uminho.pt Thu Mar 2 15:08:53 2006 From: billy at dem.uminho.pt (billy at dem.uminho.pt) Date: Thu, 2 Mar 2006 21:08:53 +0000 Subject: petsc to matlab In-Reply-To: References: <1141332221.440758fd61da9@serv-g1.ccom.uminho.pt> Message-ID: <1141333733.44075ee588eb2@serv-g1.ccom.uminho.pt> It creates a file with the following format and I don't know how to import this data into matlab. row 0: (0, -0.939141) (1, 0.234784) (98, 0.234784) (288, 0.234786) (297, 0.234786) row 1: (0, 0.234784) (1, -0.939141) (2, 0.234786) (3, 0.234786) (107, 0.234784) row 2: (1, 0.234786) (2, -0.939134) (4, 0.234782) (297, 0.23478) (305, 0.234786) ... Billy. Quoting Matthew Knepley : > billy at dem.uminho.pt writes: > > What goes wrong? > > Matt > > > How can I save the matrix in PETSc and load it in matlab? > > > > I tried this but it does not work: > > > > > > PetscViewer view; > > > > PetscViewerCreate (PETSC_COMM_WORLD, &view); > > > > PetscViewerSetFormat (view, PETSC_VIEWER_ASCII_MATLAB); > > > > PetscViewerAsciiOpen(PETSC_COMM_WORLD, "matrix.mat", &view); > > > > MatView(A, view); > > > > PetscViewerDestroy(view); > > > > > > > > Billy. > > > > > > > > -- > "Failure has a thousand explanations. Success doesn't need one" -- Sir Alec > Guiness > > From knepley at mcs.anl.gov Thu Mar 2 15:16:18 2006 From: knepley at mcs.anl.gov (Matthew Knepley) Date: Thu, 02 Mar 2006 15:16:18 -0600 Subject: petsc to matlab In-Reply-To: <1141333733.44075ee588eb2@serv-g1.ccom.uminho.pt> (billy@dem.uminho.pt's message of "Thu, 2 Mar 2006 21:08:53 +0000") References: <1141332221.440758fd61da9@serv-g1.ccom.uminho.pt> <1141333733.44075ee588eb2@serv-g1.ccom.uminho.pt> Message-ID: billy at dem.uminho.pt writes: You can save in PETSc binary format and then use $PETSC_DIR/bin/matlab/PetscBinaryRead.m to read it in. This is the preferred way I think. Matt > It creates a file with the following format and I don't know how to import this > data into matlab. > > row 0: (0, -0.939141) (1, 0.234784) (98, 0.234784) (288, 0.234786) (297, > 0.234786) > row 1: (0, 0.234784) (1, -0.939141) (2, 0.234786) (3, 0.234786) (107, 0.234784) > row 2: (1, 0.234786) (2, -0.939134) (4, 0.234782) (297, 0.23478) (305, > 0.234786) > ... > > Billy. > > Quoting Matthew Knepley : > >> billy at dem.uminho.pt writes: >> >> What goes wrong? >> >> Matt >> >> > How can I save the matrix in PETSc and load it in matlab? >> > >> > I tried this but it does not work: >> > >> > >> > PetscViewer view; >> > >> > PetscViewerCreate (PETSC_COMM_WORLD, &view); >> > >> > PetscViewerSetFormat (view, PETSC_VIEWER_ASCII_MATLAB); >> > >> > PetscViewerAsciiOpen(PETSC_COMM_WORLD, "matrix.mat", &view); >> > >> > MatView(A, view); >> > >> > PetscViewerDestroy(view); >> > >> > >> > >> > Billy. >> > >> > >> > >> >> -- >> "Failure has a thousand explanations. Success doesn't need one" -- Sir Alec >> Guiness >> >> > > > > -- "Failure has a thousand explanations. Success doesn't need one" -- Sir Alec Guiness From billy at dem.uminho.pt Thu Mar 2 16:17:02 2006 From: billy at dem.uminho.pt (billy at dem.uminho.pt) Date: Thu, 2 Mar 2006 22:17:02 +0000 Subject: Matrix convergence. In-Reply-To: References: <1141321382.44072ea6da75b@serv-g1.ccom.uminho.pt> Message-ID: <1141337822.44076ede3164e@serv-g1.ccom.uminho.pt> Yes, it is elliptic. Quoting Matthew Knepley : > billy at dem.uminho.pt writes: > > Its definitely possible. Usually you need to know something about > your system in order to precondition and solve it effectively. For > instance, > is it the discretization of an elliptic operator? > > Matt > > > Hi, > > > > > > I have been testing my parallel implementation with a 2D case. I have used > the > > following grids with 2 and 4 processes: 4x4, 10x10, 16x16 and 18x18. > > > > It works for the first three (max. number of iterations to converge aprox. > 70) > > but when I increase to 18x18 the matrix does not converge. I have increased > the > > maximum number of iterations and I have used GMRES, BiCGSTAB with > > preconditioners ASM, JACOBI, etc. > > > > With KSPType = GMRES and PCType = ASM: > > Number of iterations: 500 Residual: +1.420471E-01 > > > > With KSPType = GMRES and PCType = JACOBI: > > Number of iterations: 500 Residual: +2.351882E-02 > > > > With KSPType = BCGS and PCType = ASM: > > Number of iterations: 136 Residual: +3.911446E+04 > > > > With KSPType = BCGS and PCType = NULL: > > Number of iterations: 157 Residual: +3.254728E+03 > > > > Is it normal that the convergence detiorates so much with such a slight > increase > > in the dimension of the matrix? Is there any optimization parameter that I > may > > be missing? > > > > > > Billy. > > > > > > > > -- > "Failure has a thousand explanations. Success doesn't need one" -- Sir Alec > Guiness > > From knepley at mcs.anl.gov Thu Mar 2 16:22:04 2006 From: knepley at mcs.anl.gov (Matthew Knepley) Date: Thu, 02 Mar 2006 16:22:04 -0600 Subject: Matrix convergence. In-Reply-To: <1141337822.44076ede3164e@serv-g1.ccom.uminho.pt> (billy@dem.uminho.pt's message of "Thu, 2 Mar 2006 22:17:02 +0000") References: <1141321382.44072ea6da75b@serv-g1.ccom.uminho.pt> <1141337822.44076ede3164e@serv-g1.ccom.uminho.pt> Message-ID: billy at dem.uminho.pt writes: > Yes, it is elliptic. Then this does not make a lot of sense. However, it looks like it is nonsymmetrix, so maybe severe non-normality is screwing up the solve. I would export to Matlab and plot the spectrum of both the operator and the preconditioned operator since the matrix is small enough. Matt > Quoting Matthew Knepley : > >> billy at dem.uminho.pt writes: >> >> Its definitely possible. Usually you need to know something about >> your system in order to precondition and solve it effectively. For >> instance, >> is it the discretization of an elliptic operator? >> >> Matt >> >> > Hi, >> > >> > >> > I have been testing my parallel implementation with a 2D case. I have used >> the >> > following grids with 2 and 4 processes: 4x4, 10x10, 16x16 and 18x18. >> > >> > It works for the first three (max. number of iterations to converge aprox. >> 70) >> > but when I increase to 18x18 the matrix does not converge. I have increased >> the >> > maximum number of iterations and I have used GMRES, BiCGSTAB with >> > preconditioners ASM, JACOBI, etc. >> > >> > With KSPType = GMRES and PCType = ASM: >> > Number of iterations: 500 Residual: +1.420471E-01 >> > >> > With KSPType = GMRES and PCType = JACOBI: >> > Number of iterations: 500 Residual: +2.351882E-02 >> > >> > With KSPType = BCGS and PCType = ASM: >> > Number of iterations: 136 Residual: +3.911446E+04 >> > >> > With KSPType = BCGS and PCType = NULL: >> > Number of iterations: 157 Residual: +3.254728E+03 >> > >> > Is it normal that the convergence detiorates so much with such a slight >> increase >> > in the dimension of the matrix? Is there any optimization parameter that I >> may >> > be missing? >> > >> > >> > Billy. >> > >> > >> > >> >> -- >> "Failure has a thousand explanations. Success doesn't need one" -- Sir Alec >> Guiness >> >> > > > > -- "Failure has a thousand explanations. Success doesn't need one" -- Sir Alec Guiness From billy at dem.uminho.pt Thu Mar 2 16:31:29 2006 From: billy at dem.uminho.pt (billy at dem.uminho.pt) Date: Thu, 2 Mar 2006 22:31:29 +0000 Subject: Matrix convergence. In-Reply-To: References: <1141321382.44072ea6da75b@serv-g1.ccom.uminho.pt> <1141337822.44076ede3164e@serv-g1.ccom.uminho.pt> Message-ID: <1141338689.44077241c61b4@serv-g1.ccom.uminho.pt> Yes, it is non-symmetric. Should I optimize the renumbering of the cells to someway reduce the bandwidth of the matrix? Billy. Quoting Matthew Knepley : > billy at dem.uminho.pt writes: > > > Yes, it is elliptic. > > Then this does not make a lot of sense. However, it looks like > it is nonsymmetrix, so maybe severe non-normality is screwing up > the solve. I would export to Matlab and plot the spectrum of both > the operator and the preconditioned operator since the matrix is > small enough. > > Matt > > > Quoting Matthew Knepley : > > > >> billy at dem.uminho.pt writes: > >> > >> Its definitely possible. Usually you need to know something about > >> your system in order to precondition and solve it effectively. For > >> instance, > >> is it the discretization of an elliptic operator? > >> > >> Matt > >> > >> > Hi, > >> > > >> > > >> > I have been testing my parallel implementation with a 2D case. I have > used > >> the > >> > following grids with 2 and 4 processes: 4x4, 10x10, 16x16 and 18x18. > >> > > >> > It works for the first three (max. number of iterations to converge > aprox. > >> 70) > >> > but when I increase to 18x18 the matrix does not converge. I have > increased > >> the > >> > maximum number of iterations and I have used GMRES, BiCGSTAB with > >> > preconditioners ASM, JACOBI, etc. > >> > > >> > With KSPType = GMRES and PCType = ASM: > >> > Number of iterations: 500 Residual: +1.420471E-01 > >> > > >> > With KSPType = GMRES and PCType = JACOBI: > >> > Number of iterations: 500 Residual: +2.351882E-02 > >> > > >> > With KSPType = BCGS and PCType = ASM: > >> > Number of iterations: 136 Residual: +3.911446E+04 > >> > > >> > With KSPType = BCGS and PCType = NULL: > >> > Number of iterations: 157 Residual: +3.254728E+03 > >> > > >> > Is it normal that the convergence detiorates so much with such a > slight > >> increase > >> > in the dimension of the matrix? Is there any optimization parameter that > I > >> may > >> > be missing? > >> > > >> > > >> > Billy. > >> > > >> > > >> > > >> > >> -- > >> "Failure has a thousand explanations. Success doesn't need one" -- Sir > Alec > >> Guiness > >> > >> > > > > > > > > > > -- > "Failure has a thousand explanations. Success doesn't need one" -- Sir Alec > Guiness > > From bsmith at mcs.anl.gov Thu Mar 2 16:43:57 2006 From: bsmith at mcs.anl.gov (Barry Smith) Date: Thu, 2 Mar 2006 16:43:57 -0600 (CST) Subject: Matrix convergence. In-Reply-To: <1141321382.44072ea6da75b@serv-g1.ccom.uminho.pt> References: <1141321382.44072ea6da75b@serv-g1.ccom.uminho.pt> Message-ID: Billy, Most likely there is something wrong with the matrix being generated. I would first look at the matrix entries and make sure they make sense. Then I would solve the linear systems with a direct solver -pc_type lu (on one processor and make sure the solutions are reasonable and your simulation has "correct" answers). It is possible the parallel matrix generation is wrong, Barry On Thu, 2 Mar 2006, billy at dem.uminho.pt wrote: > > Hi, > > > I have been testing my parallel implementation with a 2D case. I have used the > following grids with 2 and 4 processes: 4x4, 10x10, 16x16 and 18x18. > > It works for the first three (max. number of iterations to converge aprox. 70) > but when I increase to 18x18 the matrix does not converge. I have increased the > maximum number of iterations and I have used GMRES, BiCGSTAB with > preconditioners ASM, JACOBI, etc. > > With KSPType = GMRES and PCType = ASM: > Number of iterations: 500 Residual: +1.420471E-01 > > With KSPType = GMRES and PCType = JACOBI: > Number of iterations: 500 Residual: +2.351882E-02 > > With KSPType = BCGS and PCType = ASM: > Number of iterations: 136 Residual: +3.911446E+04 > > With KSPType = BCGS and PCType = NULL: > Number of iterations: 157 Residual: +3.254728E+03 > > Is it normal that the convergence detiorates so much with such a slight increase > in the dimension of the matrix? Is there any optimization parameter that I may > be missing? > > > Billy. > > From bsmith at mcs.anl.gov Thu Mar 2 19:24:21 2006 From: bsmith at mcs.anl.gov (Barry Smith) Date: Thu, 2 Mar 2006 19:24:21 -0600 (CST) Subject: SNES Problem In-Reply-To: <82f936c20603020529j6d4181c8pc75c980357df9aa3@mail.gmail.com> References: <82f936c20602270607t775d7e03o6a37afa4c0b3d2a8@mail.gmail.com> <82f936c20603020529j6d4181c8pc75c980357df9aa3@mail.gmail.com> Message-ID: > it again, the push and pop() functions dont seem to work, and they are > keeping me from compiling the program, this is the main timestep loop: > PETSC_ERR_ARG_DOMAIN didnt work: error on line 6500 of SNESG3D2.F: > data type is undefined for variable PETSC_ERR_ARG_DOMAIN > Even thought I had petsc.h included. Is it just not compiling because PETSC_ERR_ARG_DOMAIN is not defined? Or does it still not work even when you have put the number in? What is the error? Or did you get it all working with SNES? It may work automatically with TS; you would just set TS with a smaller timestep and call TSSolve again? Barry I'm adding a petscerror.h for Fortran that includes these values Sorry I forgot we hadn't given them for Fortran. On Thu, 2 Mar 2006, Nils Erik Svang?rd wrote: > Hi again, > I realised that my implementation was a bit flawed so I have rewritten > it again, the push and pop() functions dont seem to work, and they are > keeping me from compiling the program, this is the main timestep loop: > > call VecCreateSeq(PETSC_COMM_SELF,N,x,ierr) > call VecDuplicate(x,r,ierr) > call VecDuplicate(x,xb,ierr) > call SNESCreate(PETSC_COMM_SELF,snes,ierr) > call SNESSetFunction(snes,r,FormFunction,PETSC_NULL_OBJECT,ierr) > call SNESSetFromOptions(snes,ierr) > call FormInitialGuess(x,ierr) > call VecCopy(x,xb,ierr) > write(6,*)zero,dt,tmax,i1000 > step=0 > timestep=dt > C While loop > 10 if (step .le. 100) then > call PetscExceptionPush(87,ierr) > call SNESSolve(snes,PETSC_NULL_OBJECT,x,ierr) > call PetscExceptionPop(87,ierr2) > > call SNESGetConvergedReason(snes,reason,ierr) > IF ( reason .LT. 0 ) THEN > timestep=timestep/2 > VecCopy(xb,x,ierr) > write(6,*)"Solution diverged, trying with", > . " smaller timestep: ",timestep > ELSE > IF ( ierr .EQ. 87) THEN > timestep=timestep/2 > VecCopy(xb,x,ierr) > write(6,*) "No physical solution, trying", > . " with smaller timestep: ",timestep > ELSE > timestep=dt > step=step+1 > VecCopy(x,xb,ierr) > write(6,*) "Solve success, going for step: ",step > ENDIF > ENDIF > goto 10 > endif > C End While loop > > And in my Formfunction I have added the following check: > if (ET(L) .LT. 0) then > ierr = 87 > return > endif > > PETSC_ERR_ARG_DOMAIN didnt work: error on line 6500 of SNESG3D2.F: > data type is undefined for variable PETSC_ERR_ARG_DOMAIN > Even thought I had petsc.h included. > > Can I do this check when I use TS also? I have the sameproblem with > the values being negative when using TS. > > > /nisse > > > On 2/27/06, Barry Smith wrote: >> >> SNES works by computing p = -approxinv(J)*F(uold) and >> then does a line search on unew = uold + lambda*p to get the >> new u. First it uses a test value of 1 for lambda so it >> tries to compute F(uold + p). It is possible that uold + p >> has some "non-physical" values in it. There are two ways >> you can try handling it: >> >> 1) Before doing the linesearch SNES calls a "precheck" function, >> that can change the step if it decides there is a problem >> with the step (like it is too long). You can provide your >> own precheck function with SNESLineSearchSetPreCheck() it could, >> for example, shrink the Newton direction to make it remain physical. >> >> or 2) when your form function detects an illegal value it calls >> SETERRQ(PETSC_ERR_ARG_DOMAIN,"Nonphysical function input"); Note: >> this is before it takes the square root of the negative number, >> so check the number and call the error before calling SETERRQ(). >> (If using Fortran then simply set ierr = PETSC_ERR_ARG_DOMAIN and >> then immediately return). Then replace your call to SNESSolve with >> ierr = PetscExceptionTry1(SNESSolve(snes,b,x),PETSC_ERR_ARG_DOMAIN); >> if (PetscExceptionCaught(ierr,PETSC_ERR_ARG_DOMAIN)) { >> /* this means your function found a non-physical value so >> cut your time-step and continue through the loop again. */ >> Put code to do this here. >> } >> If using fortran then do >> call PetscExceptionPush(PETSC_ERR_ARG_DOMAIN,ierr) >> call SNESSolve(snes,b,x,ierr) >> call PetscExceptionPop(PETSC_ERR_ARG_DOMAIN,anotherierr) >> if (ierr == PETSC_ERR_ARG_DOMAIN) then >> non-physical value so cut the time-step and try again >> else ! everything is normal so take the next time-step >> >> Barry >> >> The Fortran interface may be missing PetscExceptionPush() and Pop() >> if so let us know and we'll provide the patch. >> >> On Mon, 27 Feb 2006, Nils Erik Svang?rd wrote: >> >>> Hi all, >>> >>> I have problems solving some CFD problems using SNES and my custom >>> back-euler. I have 7 equations that I want to solve. >>> >>> First my FormFunction copies the values from the Vec that SNES uses to >>> the variables that my code use: >>> >>> RO(L)=xx(1,L) >>> RU(L)=xx(2,L) >>> RV(L)=xx(3,L) >>> RW(L)=xx(4,L) >>> ET(L)=xx(5,L) >>> RQ(L)= xx(6,L) >>> REPS(L)=xx(7,L) >>> >>> Here I also print the values of ET(2) for debugging: >>> >>> write(6,*)"ET(2) = xx(5,2) : ",ET(2)," = ",xx(5,2) >>> >>> Then I get the fluxes by calling custom functions >>> >>> call AUXVR >>> call VGRAD >>> call FLUX >>> call KESRC >>> >>> Then I perform back-euler save the new value to so that I can use it >>> in the next iterationi (TSF(L) is Time step function, which is set by >>> hand and is the same for all L): >>> >>> ff(1,L) = RO(L)-OLD(1,L)-TSF(L)*DRO(L) >>> ff(2,L) = RU(L)-OLD(2,L)-TSF(L)*DRU(L) >>> ff(3,L) = RV(L)-OLD(3,L)-TSF(L)*DRV(L) >>> ff(4,L) = RW(L)-OLD(4,L)-TSF(L)*DRW(L) >>> ff(5,L) = ET(L)-OLD(5,L)-TSF(L)*DET(L) >>> ff(6,L) = RQ(L)-OLD(6,L)-TSF(L)*DRQ(L) >>> ff(7,L) = REPS(L)-OLD(7,L)-TSF(L)*DREPS(L) >>> >>> And save the new value of RO-REPS to use in the next iteration of back-euler: >>> >>> OLD(1,L)=RO(L) >>> OLD(2,L)=RU(L) >>> OLD(3,L)=RV(L) >>> OLD(4,L)=RW(L) >>> OLD(5,L)=ET(L) >>> OLD(6,L)=RQ(L) >>> OLD(7,L)=REPS(L) >>> >>> Here I print the values of L=2 as above for debugging: >>> >>> write(6,*)ff(5,2)," = ",ET(2),"-",OLD(5,2),"-",TSF(2),"*",DET(2) >>> >>> >>> >>> The program exit abnormaly after 33 runs of the FormFunction. The >>> cause of this is that AUXVR tries to perform sqrt(ET(2)) when ET(2) is >>> negative, ET is the total energy and should never be negative. It >>> seems that all of a sudden the PETSc SNES solver decides to supply the >>> FormFunction with a negative ET value. I need help understanding why >>> and how to fix it (if it is fixable). >>> >>> Here is the output of: >>> write(6,*)"ET(2) = xx(5,2) : ",ET(2)," = ",xx(5,2) >>> Which is in the beginning of my FormFunction. >>> And: >>> write(6,*)ff(5,2)," = ",ET(2),"-",OLD(5,2),"-",TSF(2),"*",DET(2) >>> Which is in the end of my Formfunction. >>> >>> 1. ET(2) = xx(5,2) : 253250. = 253250.000000000 >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>> 2. ET(2) = xx(5,2) : 253250. = 253250.000010259 >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>> 3. ET(2) = xx(5,2) : 253250. = 253249.999999988 >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4132419437260 = >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941324E+08 >>> 4. ET(2) = xx(5,2) : 253250. = 253250.000048432 >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>> 5. ET(2) = xx(5,2) : 253250. = 253249.999999872 >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4177283437784 = >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941773E+08 >>> 6. ET(2) = xx(5,2) : 253250. = 253250.000071113 >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>> 7. ET(2) = xx(5,2) : 253250. = 253249.999980115 >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4453347441010 = >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.944533E+08 >>> 8. ET(2) = xx(5,2) : 253250. = 253250.000037298 >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4082723436679 = >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940827E+08 >>> 9. ET(2) = xx(5,2) : 253250. = 253249.999942706 >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4082723436679 = >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940827E+08 >>> 10. ET(2) = xx(5,2) : 253250. = 253249.999948703 >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>> 11. ET(2) = xx(5,2) : 253250. = 253250.000007808 >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.7283811474088 = >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.972838E+08 >>> 12. ET(2) = xx(5,2) : 253250. = 253250.000018146 >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>> 13. ET(2) = xx(5,2) : 253250. = 253250.000001865 >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 28.3742819315846 = >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.837428E+08 >>> 14. ET(2) = xx(5,2) : 253250. = 253249.999997296 >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>> 15. ET(2) = xx(5,2) : 253250. = 253250.000000049 >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 30.6548963582361 = >>> 253250. - 253250.000000000 - 1.000000E-07 * -3.065490E+08 >>> 16. ET(2) = xx(5,2) : 253250. = 253250.000022870 >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>> 17. ET(2) = xx(5,2) : 253250. = 253249.999999716 >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.5326051451209 = >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.953260E+08 >>> 18. ET(2) = xx(5,2) : 253250. = 253250.000074328 >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4165187437643 = >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941652E+08 >>> 19. ET(2) = xx(5,2) : 253250. = 253250.000049809 >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4085059436707 = >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940851E+08 >>> 20. ET(2) = xx(5,2) : 253250. = 253250.000019253 >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>> 21. ET(2) = xx(5,2) : 253250. = 253250.000000189 >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.8851075492403 = >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.988511E+08 >>> 22. ET(2) = xx(5,2) : 253250. = 253249.999997897 >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4085059436707 = >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940851E+08 >>> 23. ET(2) = xx(5,2) : 253250. = 253249.999975142 >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.3961539435263 = >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.939615E+08 >>> 24. ET(2) = xx(5,2) : 253250. = 253250.000018324 >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4085059436707 = >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940851E+08 >>> 25. ET(2) = xx(5,2) : 253250. = 253249.999987073 >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4165187437643 = >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941652E+08 >>> 26. ET(2) = xx(5,2) : 253250. = 253249.999980982 >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4165187437643 = >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941652E+08 >>> 27. ET(2) = xx(5,2) : 253250. = 253249.999994645 >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>> 28. ET(2) = xx(5,2) : 253250. = 253249.999962364 >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4165187437643 = >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941652E+08 >>> 29. ET(2) = xx(5,2) : 253250. = 253249.999999921 >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>> 30. ET(2) = xx(5,2) : 253250. = 253250.000000058 >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 28.4019971319085 = >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.840200E+08 >>> 31. ET(2) = xx(5,2) : 253250. = 253250.000040348 >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4085059436707 = >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940851E+08 >>> 32. ET(2) = xx(5,2) : 253250. = 253250.000005245 >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>> 33. ET(2) = xx(5,2) : 253250. = 253250.000005245 >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>> 34. ET(2) = xx(5,2) : -848141. = -848141.388090847 >>> -------------------------------------------------------------------------- >>> 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. >>> ----------------------------------------------------------------------- >>> ./SNESG3D2 on a linux-gnu named sethnx004.vac.com by yy26539 Mon Feb >>> 27 14:21:13 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] SNES user function line 0 unknownunknown >>> [0]PETSC ERROR: [0] SNESComputeFunction line 788 src/snes/interface/snes.c >>> [0]PETSC ERROR: [0] SNESLineSearchCubic line 514 src/snes/impls/ls/ls.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: ! >>> >>> >>> Suggestions and tips are very welcome! >>> /nisse >>> >>> >>> -- >>> Nils-Erik Svang???rd >>> MSN: schweingaard at hotmail.com >>> Skype: schweingaard >>> >>> >> > > > -- > Nils-Erik Svang?rd > MSN: schweingaard at hotmail.com > Skype: schweingaard > > From nilserik at gmail.com Fri Mar 3 02:47:26 2006 From: nilserik at gmail.com (=?ISO-8859-1?Q?Nils_Erik_Svang=E5rd?=) Date: Fri, 3 Mar 2006 09:47:26 +0100 Subject: SNES Problem In-Reply-To: References: <82f936c20602270607t775d7e03o6a37afa4c0b3d2a8@mail.gmail.com> <82f936c20603020529j6d4181c8pc75c980357df9aa3@mail.gmail.com> Message-ID: <82f936c20603030047m5f64406n1435ca60f306fa98@mail.gmail.com> Hello again, > Is it just not compiling because PETSC_ERR_ARG_DOMAIN is not > defined? Or does it still not work even when you have put the number in? > What is the error? Or did you get it all working with SNES? > It is not compiling because PETSC_ERR_ARG_DOMAIN is not defined: error on line 585 of SNESG3D2.F: data type is undefined for variable PETSC_ERR_ARG_DOMAIN I tried putting a number in, then it compiles but complains while linking that the Push() and Pop() functions is not defined. I made a workaround by adding a variable in a common block and setting it before returning from a non physical value in the FormFunction. Now I can compile and when there is a non-physical value it returns and resumes with a smaller timestep. SNES still give non physical values which are hard to add checks for in the program (e.g sqrt(RO(L)-RO(L+1))). Did I understand correctly that SNES does a linesearch and probably goes for a solution which isnt the one I looking for? Does SNES use the linesearch algorithm when I use -snes_mf (which I use)? > It may work automatically with TS; you would just set TS with a > smaller timestep and call TSSolve again? > OK, I'll add a check and put TSSolve in a while loop. My SNESSolve loop looks like this right now: call VecCreateSeq(PETSC_COMM_SELF,N,x,ierr) call VecDuplicate(x,r,ierr) call VecDuplicate(x,xb,ierr) call SNESCreate(PETSC_COMM_SELF,snes,ierr) call SNESSetFunction(snes,r,FormFunction,PETSC_NULL_OBJECT,ierr) call SNESSetFromOptions(snes,ierr) call FormInitialGuess(x,ierr) call VecCopy(x,xb,ierr) write(6,*)zero,dt,tmax,i1000 step=0 timestep=dt bang=0 C While loop 10 if (step .le. 100) then C call PetscExceptionPush(87,ierr) C call PetscExceptionPush(PETSC_ERR_ARG_DOMAIN,ierr) call SNESSolve(snes,PETSC_NULL_OBJECT,x,ierr) ierr=bang C call PetscExceptionPop(87,ierr2) IF ( ierr .EQ. 87) THEN timestep=timestep/2 call VecCopy(xb,x,ierr) write(6,*) "No physical solution, trying", . " with smaller timestep: ",timestep bang=0 ELSE call SNESGetConvergedReason(snes,reason,ierr) IF ( reason .LT. 0 ) THEN timestep=timestep/2 call VecCopy(xb,x,ierr) write(6,*)"Solution diverged, trying with", . " smaller timestep: ",timestep ELSE timestep=dt step=step+1 call VecCopy(x,xb,ierr) write(6,*) "Solve success, going for step: ",step write(6,*) "Reason: ",reason," ierr: ",ierr reason=0 ierr=0 ENDIF ENDIF goto 10 endif C End While loop And the check in the FormFunction: if (ET(L) .LT. 0) then ierr = 87 bang = 87 C SETERRQ(87,"Non physical value!",ierr) return elseif ( RO(L) .LT. 0 ) then ierr = 87 bang = 87 return endif /nisse > Barry > > I'm adding a petscerror.h for Fortran that includes these values > Sorry I forgot we hadn't given them for Fortran. > > On Thu, 2 Mar 2006, Nils Erik Svang?rd wrote: > > > Hi again, > > I realised that my implementation was a bit flawed so I have rewritten > > it again, the push and pop() functions dont seem to work, and they are > > keeping me from compiling the program, this is the main timestep loop: > > > > call VecCreateSeq(PETSC_COMM_SELF,N,x,ierr) > > call VecDuplicate(x,r,ierr) > > call VecDuplicate(x,xb,ierr) > > call SNESCreate(PETSC_COMM_SELF,snes,ierr) > > call SNESSetFunction(snes,r,FormFunction,PETSC_NULL_OBJECT,ierr) > > call SNESSetFromOptions(snes,ierr) > > call FormInitialGuess(x,ierr) > > call VecCopy(x,xb,ierr) > > write(6,*)zero,dt,tmax,i1000 > > step=0 > > timestep=dt > > C While loop > > 10 if (step .le. 100) then > > call PetscExceptionPush(87,ierr) > > call SNESSolve(snes,PETSC_NULL_OBJECT,x,ierr) > > call PetscExceptionPop(87,ierr2) > > > > call SNESGetConvergedReason(snes,reason,ierr) > > IF ( reason .LT. 0 ) THEN > > timestep=timestep/2 > > VecCopy(xb,x,ierr) > > write(6,*)"Solution diverged, trying with", > > . " smaller timestep: ",timestep > > ELSE > > IF ( ierr .EQ. 87) THEN > > timestep=timestep/2 > > VecCopy(xb,x,ierr) > > write(6,*) "No physical solution, trying", > > . " with smaller timestep: ",timestep > > ELSE > > timestep=dt > > step=step+1 > > VecCopy(x,xb,ierr) > > write(6,*) "Solve success, going for step: ",step > > ENDIF > > ENDIF > > goto 10 > > endif > > C End While loop > > > > And in my Formfunction I have added the following check: > > if (ET(L) .LT. 0) then > > ierr = 87 > > return > > endif > > > > PETSC_ERR_ARG_DOMAIN didnt work: error on line 6500 of SNESG3D2.F: > > data type is undefined for variable PETSC_ERR_ARG_DOMAIN > > Even thought I had petsc.h included. > > > > Can I do this check when I use TS also? I have the sameproblem with > > the values being negative when using TS. > > > > > > /nisse > > > > > > On 2/27/06, Barry Smith wrote: > >> > >> SNES works by computing p = -approxinv(J)*F(uold) and > >> then does a line search on unew = uold + lambda*p to get the > >> new u. First it uses a test value of 1 for lambda so it > >> tries to compute F(uold + p). It is possible that uold + p > >> has some "non-physical" values in it. There are two ways > >> you can try handling it: > >> > >> 1) Before doing the linesearch SNES calls a "precheck" function, > >> that can change the step if it decides there is a problem > >> with the step (like it is too long). You can provide your > >> own precheck function with SNESLineSearchSetPreCheck() it could, > >> for example, shrink the Newton direction to make it remain physical. > >> > >> or 2) when your form function detects an illegal value it calls > >> SETERRQ(PETSC_ERR_ARG_DOMAIN,"Nonphysical function input"); Note: > >> this is before it takes the square root of the negative number, > >> so check the number and call the error before calling SETERRQ(). > >> (If using Fortran then simply set ierr = PETSC_ERR_ARG_DOMAIN and > >> then immediately return). Then replace your call to SNESSolve with > >> ierr = PetscExceptionTry1(SNESSolve(snes,b,x),PETSC_ERR_ARG_DOMAIN); > >> if (PetscExceptionCaught(ierr,PETSC_ERR_ARG_DOMAIN)) { > >> /* this means your function found a non-physical value so > >> cut your time-step and continue through the loop again. */ > >> Put code to do this here. > >> } > >> If using fortran then do > >> call PetscExceptionPush(PETSC_ERR_ARG_DOMAIN,ierr) > >> call SNESSolve(snes,b,x,ierr) > >> call PetscExceptionPop(PETSC_ERR_ARG_DOMAIN,anotherierr) > >> if (ierr == PETSC_ERR_ARG_DOMAIN) then > >> non-physical value so cut the time-step and try again > >> else ! everything is normal so take the next time-step > >> > >> Barry > >> > >> The Fortran interface may be missing PetscExceptionPush() and Pop() > >> if so let us know and we'll provide the patch. > >> > >> On Mon, 27 Feb 2006, Nils Erik Svang?rd wrote: > >> > >>> Hi all, > >>> > >>> I have problems solving some CFD problems using SNES and my custom > >>> back-euler. I have 7 equations that I want to solve. > >>> > >>> First my FormFunction copies the values from the Vec that SNES uses to > >>> the variables that my code use: > >>> > >>> RO(L)=xx(1,L) > >>> RU(L)=xx(2,L) > >>> RV(L)=xx(3,L) > >>> RW(L)=xx(4,L) > >>> ET(L)=xx(5,L) > >>> RQ(L)= xx(6,L) > >>> REPS(L)=xx(7,L) > >>> > >>> Here I also print the values of ET(2) for debugging: > >>> > >>> write(6,*)"ET(2) = xx(5,2) : ",ET(2)," = ",xx(5,2) > >>> > >>> Then I get the fluxes by calling custom functions > >>> > >>> call AUXVR > >>> call VGRAD > >>> call FLUX > >>> call KESRC > >>> > >>> Then I perform back-euler save the new value to so that I can use it > >>> in the next iterationi (TSF(L) is Time step function, which is set by > >>> hand and is the same for all L): > >>> > >>> ff(1,L) = RO(L)-OLD(1,L)-TSF(L)*DRO(L) > >>> ff(2,L) = RU(L)-OLD(2,L)-TSF(L)*DRU(L) > >>> ff(3,L) = RV(L)-OLD(3,L)-TSF(L)*DRV(L) > >>> ff(4,L) = RW(L)-OLD(4,L)-TSF(L)*DRW(L) > >>> ff(5,L) = ET(L)-OLD(5,L)-TSF(L)*DET(L) > >>> ff(6,L) = RQ(L)-OLD(6,L)-TSF(L)*DRQ(L) > >>> ff(7,L) = REPS(L)-OLD(7,L)-TSF(L)*DREPS(L) > >>> > >>> And save the new value of RO-REPS to use in the next iteration of back-euler: > >>> > >>> OLD(1,L)=RO(L) > >>> OLD(2,L)=RU(L) > >>> OLD(3,L)=RV(L) > >>> OLD(4,L)=RW(L) > >>> OLD(5,L)=ET(L) > >>> OLD(6,L)=RQ(L) > >>> OLD(7,L)=REPS(L) > >>> > >>> Here I print the values of L=2 as above for debugging: > >>> > >>> write(6,*)ff(5,2)," = ",ET(2),"-",OLD(5,2),"-",TSF(2),"*",DET(2) > >>> > >>> > >>> > >>> The program exit abnormaly after 33 runs of the FormFunction. The > >>> cause of this is that AUXVR tries to perform sqrt(ET(2)) when ET(2) is > >>> negative, ET is the total energy and should never be negative. It > >>> seems that all of a sudden the PETSc SNES solver decides to supply the > >>> FormFunction with a negative ET value. I need help understanding why > >>> and how to fix it (if it is fixable). > >>> > >>> Here is the output of: > >>> write(6,*)"ET(2) = xx(5,2) : ",ET(2)," = ",xx(5,2) > >>> Which is in the beginning of my FormFunction. > >>> And: > >>> write(6,*)ff(5,2)," = ",ET(2),"-",OLD(5,2),"-",TSF(2),"*",DET(2) > >>> Which is in the end of my Formfunction. > >>> > >>> 1. ET(2) = xx(5,2) : 253250. = 253250.000000000 > >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > >>> 2. ET(2) = xx(5,2) : 253250. = 253250.000010259 > >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > >>> 3. ET(2) = xx(5,2) : 253250. = 253249.999999988 > >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4132419437260 = > >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941324E+08 > >>> 4. ET(2) = xx(5,2) : 253250. = 253250.000048432 > >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > >>> 5. ET(2) = xx(5,2) : 253250. = 253249.999999872 > >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4177283437784 = > >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941773E+08 > >>> 6. ET(2) = xx(5,2) : 253250. = 253250.000071113 > >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > >>> 7. ET(2) = xx(5,2) : 253250. = 253249.999980115 > >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4453347441010 = > >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.944533E+08 > >>> 8. ET(2) = xx(5,2) : 253250. = 253250.000037298 > >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4082723436679 = > >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940827E+08 > >>> 9. ET(2) = xx(5,2) : 253250. = 253249.999942706 > >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4082723436679 = > >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940827E+08 > >>> 10. ET(2) = xx(5,2) : 253250. = 253249.999948703 > >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > >>> 11. ET(2) = xx(5,2) : 253250. = 253250.000007808 > >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.7283811474088 = > >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.972838E+08 > >>> 12. ET(2) = xx(5,2) : 253250. = 253250.000018146 > >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > >>> 13. ET(2) = xx(5,2) : 253250. = 253250.000001865 > >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 28.3742819315846 = > >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.837428E+08 > >>> 14. ET(2) = xx(5,2) : 253250. = 253249.999997296 > >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > >>> 15. ET(2) = xx(5,2) : 253250. = 253250.000000049 > >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 30.6548963582361 = > >>> 253250. - 253250.000000000 - 1.000000E-07 * -3.065490E+08 > >>> 16. ET(2) = xx(5,2) : 253250. = 253250.000022870 > >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > >>> 17. ET(2) = xx(5,2) : 253250. = 253249.999999716 > >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.5326051451209 = > >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.953260E+08 > >>> 18. ET(2) = xx(5,2) : 253250. = 253250.000074328 > >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4165187437643 = > >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941652E+08 > >>> 19. ET(2) = xx(5,2) : 253250. = 253250.000049809 > >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4085059436707 = > >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940851E+08 > >>> 20. ET(2) = xx(5,2) : 253250. = 253250.000019253 > >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > >>> 21. ET(2) = xx(5,2) : 253250. = 253250.000000189 > >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.8851075492403 = > >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.988511E+08 > >>> 22. ET(2) = xx(5,2) : 253250. = 253249.999997897 > >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4085059436707 = > >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940851E+08 > >>> 23. ET(2) = xx(5,2) : 253250. = 253249.999975142 > >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.3961539435263 = > >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.939615E+08 > >>> 24. ET(2) = xx(5,2) : 253250. = 253250.000018324 > >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4085059436707 = > >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940851E+08 > >>> 25. ET(2) = xx(5,2) : 253250. = 253249.999987073 > >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4165187437643 = > >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941652E+08 > >>> 26. ET(2) = xx(5,2) : 253250. = 253249.999980982 > >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4165187437643 = > >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941652E+08 > >>> 27. ET(2) = xx(5,2) : 253250. = 253249.999994645 > >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > >>> 28. ET(2) = xx(5,2) : 253250. = 253249.999962364 > >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4165187437643 = > >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941652E+08 > >>> 29. ET(2) = xx(5,2) : 253250. = 253249.999999921 > >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > >>> 30. ET(2) = xx(5,2) : 253250. = 253250.000000058 > >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 28.4019971319085 = > >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.840200E+08 > >>> 31. ET(2) = xx(5,2) : 253250. = 253250.000040348 > >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4085059436707 = > >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940851E+08 > >>> 32. ET(2) = xx(5,2) : 253250. = 253250.000005245 > >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > >>> 33. ET(2) = xx(5,2) : 253250. = 253250.000005245 > >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > >>> 34. ET(2) = xx(5,2) : -848141. = -848141.388090847 > >>> -------------------------------------------------------------------------- > >>> 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. > >>> ----------------------------------------------------------------------- > >>> ./SNESG3D2 on a linux-gnu named sethnx004.vac.com by yy26539 Mon Feb > >>> 27 14:21:13 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] SNES user function line 0 unknownunknown > >>> [0]PETSC ERROR: [0] SNESComputeFunction line 788 src/snes/interface/snes.c > >>> [0]PETSC ERROR: [0] SNESLineSearchCubic line 514 src/snes/impls/ls/ls.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: ! > >>> > >>> > >>> Suggestions and tips are very welcome! > >>> /nisse > >>> > >>> > >>> -- > >>> Nils-Erik Svang???rd > >>> MSN: schweingaard at hotmail.com > >>> Skype: schweingaard > >>> > >>> > >> > > > > > > -- > > Nils-Erik Svang?rd > > MSN: schweingaard at hotmail.com > > Skype: schweingaard > > > > > -- Nils-Erik Svang?rd E-Mail: nilserik at gmail.com MSN: schweingaard at hotmail.com Skype: schweingaard Mobil: +46-(0)70-3612178 From nilserik at gmail.com Fri Mar 3 03:58:27 2006 From: nilserik at gmail.com (=?ISO-8859-1?Q?Nils_Erik_Svang=E5rd?=) Date: Fri, 3 Mar 2006 10:58:27 +0100 Subject: SNES Problem In-Reply-To: <82f936c20603030047m5f64406n1435ca60f306fa98@mail.gmail.com> References: <82f936c20602270607t775d7e03o6a37afa4c0b3d2a8@mail.gmail.com> <82f936c20603020529j6d4181c8pc75c980357df9aa3@mail.gmail.com> <82f936c20603030047m5f64406n1435ca60f306fa98@mail.gmail.com> Message-ID: <82f936c20603030158u33722ff0q3c50839df14841@mail.gmail.com> A interesting thing is when I change TS_BEULER to TS_RUNGE_KUTTA the solver exits fast due to the non physical values. My original solver is a 3-step Runge-Kutta which works flawlessly. The error when running RK: ./ImplicitG3D on a linux-gnu named sethnx004.vac.com by yy26539 Fri Mar 3 10:31:27 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] TS user right-hand-side function line 0 unknownunknown [0]PETSC ERROR: [0] TSComputeRHSFunction line 282 src/ts/interface/ts.c [0]PETSC ERROR: [0] TSRkqs line 256 src/ts/impls/explicit/rk/rk.c [0]PETSC ERROR: [0] TSStep_Rk line 322 src/ts/impls/explicit/rk/rk.c [0]PETSC ERROR: [0] TSStep line 1520 src/ts/interface/ts.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 On 3/3/06, Nils Erik Svang?rd wrote: > Hello again, > > > Is it just not compiling because PETSC_ERR_ARG_DOMAIN is not > > defined? Or does it still not work even when you have put the number in? > > What is the error? Or did you get it all working with SNES? > > > > > It is not compiling because PETSC_ERR_ARG_DOMAIN is not defined: > > error on line 585 of SNESG3D2.F: data type is undefined for variable > PETSC_ERR_ARG_DOMAIN > > I tried putting a number in, then it compiles but complains while > linking that the Push() and Pop() functions is not defined. I made a > workaround by adding a variable in a common block and setting it > before returning from a non physical value in the FormFunction. Now I > can compile and when there is a non-physical value it returns and > resumes with a smaller timestep. > SNES still give non physical values which are hard to add checks for > in the program (e.g sqrt(RO(L)-RO(L+1))). > > Did I understand correctly that SNES does a linesearch and probably > goes for a solution which isnt the one I looking for? Does SNES use > the linesearch algorithm when I use -snes_mf (which I use)? > > > It may work automatically with TS; you would just set TS with a > > smaller timestep and call TSSolve again? > > > > OK, I'll add a check and put TSSolve in a while loop. > > My SNESSolve loop looks like this right now: > call VecCreateSeq(PETSC_COMM_SELF,N,x,ierr) > call VecDuplicate(x,r,ierr) > call VecDuplicate(x,xb,ierr) > call SNESCreate(PETSC_COMM_SELF,snes,ierr) > call SNESSetFunction(snes,r,FormFunction,PETSC_NULL_OBJECT,ierr) > call SNESSetFromOptions(snes,ierr) > call FormInitialGuess(x,ierr) > call VecCopy(x,xb,ierr) > write(6,*)zero,dt,tmax,i1000 > step=0 > timestep=dt > bang=0 > C While loop > 10 if (step .le. 100) then > C call PetscExceptionPush(87,ierr) > C call PetscExceptionPush(PETSC_ERR_ARG_DOMAIN,ierr) > call SNESSolve(snes,PETSC_NULL_OBJECT,x,ierr) > ierr=bang > C call PetscExceptionPop(87,ierr2) > IF ( ierr .EQ. 87) THEN > timestep=timestep/2 > call VecCopy(xb,x,ierr) > write(6,*) "No physical solution, trying", > . " with smaller timestep: ",timestep > bang=0 > ELSE > call SNESGetConvergedReason(snes,reason,ierr) > IF ( reason .LT. 0 ) THEN > timestep=timestep/2 > call VecCopy(xb,x,ierr) > write(6,*)"Solution diverged, trying with", > . " smaller timestep: ",timestep > ELSE > timestep=dt > step=step+1 > call VecCopy(x,xb,ierr) > write(6,*) "Solve success, going for step: ",step > write(6,*) "Reason: ",reason," ierr: ",ierr > reason=0 > ierr=0 > ENDIF > ENDIF > goto 10 > endif > C End While loop > > And the check in the FormFunction: > > if (ET(L) .LT. 0) then > ierr = 87 > bang = 87 > C SETERRQ(87,"Non physical value!",ierr) > return > elseif ( RO(L) .LT. 0 ) then > ierr = 87 > bang = 87 > return > endif > > > /nisse > > > > > Barry > > > > I'm adding a petscerror.h for Fortran that includes these values > > Sorry I forgot we hadn't given them for Fortran. > > > > On Thu, 2 Mar 2006, Nils Erik Svang?rd wrote: > > > > > Hi again, > > > I realised that my implementation was a bit flawed so I have rewritten > > > it again, the push and pop() functions dont seem to work, and they are > > > keeping me from compiling the program, this is the main timestep loop: > > > > > > call VecCreateSeq(PETSC_COMM_SELF,N,x,ierr) > > > call VecDuplicate(x,r,ierr) > > > call VecDuplicate(x,xb,ierr) > > > call SNESCreate(PETSC_COMM_SELF,snes,ierr) > > > call SNESSetFunction(snes,r,FormFunction,PETSC_NULL_OBJECT,ierr) > > > call SNESSetFromOptions(snes,ierr) > > > call FormInitialGuess(x,ierr) > > > call VecCopy(x,xb,ierr) > > > write(6,*)zero,dt,tmax,i1000 > > > step=0 > > > timestep=dt > > > C While loop > > > 10 if (step .le. 100) then > > > call PetscExceptionPush(87,ierr) > > > call SNESSolve(snes,PETSC_NULL_OBJECT,x,ierr) > > > call PetscExceptionPop(87,ierr2) > > > > > > call SNESGetConvergedReason(snes,reason,ierr) > > > IF ( reason .LT. 0 ) THEN > > > timestep=timestep/2 > > > VecCopy(xb,x,ierr) > > > write(6,*)"Solution diverged, trying with", > > > . " smaller timestep: ",timestep > > > ELSE > > > IF ( ierr .EQ. 87) THEN > > > timestep=timestep/2 > > > VecCopy(xb,x,ierr) > > > write(6,*) "No physical solution, trying", > > > . " with smaller timestep: ",timestep > > > ELSE > > > timestep=dt > > > step=step+1 > > > VecCopy(x,xb,ierr) > > > write(6,*) "Solve success, going for step: ",step > > > ENDIF > > > ENDIF > > > goto 10 > > > endif > > > C End While loop > > > > > > And in my Formfunction I have added the following check: > > > if (ET(L) .LT. 0) then > > > ierr = 87 > > > return > > > endif > > > > > > PETSC_ERR_ARG_DOMAIN didnt work: error on line 6500 of SNESG3D2.F: > > > data type is undefined for variable PETSC_ERR_ARG_DOMAIN > > > Even thought I had petsc.h included. > > > > > > Can I do this check when I use TS also? I have the sameproblem with > > > the values being negative when using TS. > > > > > > > > > /nisse > > > > > > > > > On 2/27/06, Barry Smith wrote: > > >> > > >> SNES works by computing p = -approxinv(J)*F(uold) and > > >> then does a line search on unew = uold + lambda*p to get the > > >> new u. First it uses a test value of 1 for lambda so it > > >> tries to compute F(uold + p). It is possible that uold + p > > >> has some "non-physical" values in it. There are two ways > > >> you can try handling it: > > >> > > >> 1) Before doing the linesearch SNES calls a "precheck" function, > > >> that can change the step if it decides there is a problem > > >> with the step (like it is too long). You can provide your > > >> own precheck function with SNESLineSearchSetPreCheck() it could, > > >> for example, shrink the Newton direction to make it remain physical. > > >> > > >> or 2) when your form function detects an illegal value it calls > > >> SETERRQ(PETSC_ERR_ARG_DOMAIN,"Nonphysical function input"); Note: > > >> this is before it takes the square root of the negative number, > > >> so check the number and call the error before calling SETERRQ(). > > >> (If using Fortran then simply set ierr = PETSC_ERR_ARG_DOMAIN and > > >> then immediately return). Then replace your call to SNESSolve with > > >> ierr = PetscExceptionTry1(SNESSolve(snes,b,x),PETSC_ERR_ARG_DOMAIN); > > >> if (PetscExceptionCaught(ierr,PETSC_ERR_ARG_DOMAIN)) { > > >> /* this means your function found a non-physical value so > > >> cut your time-step and continue through the loop again. */ > > >> Put code to do this here. > > >> } > > >> If using fortran then do > > >> call PetscExceptionPush(PETSC_ERR_ARG_DOMAIN,ierr) > > >> call SNESSolve(snes,b,x,ierr) > > >> call PetscExceptionPop(PETSC_ERR_ARG_DOMAIN,anotherierr) > > >> if (ierr == PETSC_ERR_ARG_DOMAIN) then > > >> non-physical value so cut the time-step and try again > > >> else ! everything is normal so take the next time-step > > >> > > >> Barry > > >> > > >> The Fortran interface may be missing PetscExceptionPush() and Pop() > > >> if so let us know and we'll provide the patch. > > >> > > >> On Mon, 27 Feb 2006, Nils Erik Svang?rd wrote: > > >> > > >>> Hi all, > > >>> > > >>> I have problems solving some CFD problems using SNES and my custom > > >>> back-euler. I have 7 equations that I want to solve. > > >>> > > >>> First my FormFunction copies the values from the Vec that SNES uses to > > >>> the variables that my code use: > > >>> > > >>> RO(L)=xx(1,L) > > >>> RU(L)=xx(2,L) > > >>> RV(L)=xx(3,L) > > >>> RW(L)=xx(4,L) > > >>> ET(L)=xx(5,L) > > >>> RQ(L)= xx(6,L) > > >>> REPS(L)=xx(7,L) > > >>> > > >>> Here I also print the values of ET(2) for debugging: > > >>> > > >>> write(6,*)"ET(2) = xx(5,2) : ",ET(2)," = ",xx(5,2) > > >>> > > >>> Then I get the fluxes by calling custom functions > > >>> > > >>> call AUXVR > > >>> call VGRAD > > >>> call FLUX > > >>> call KESRC > > >>> > > >>> Then I perform back-euler save the new value to so that I can use it > > >>> in the next iterationi (TSF(L) is Time step function, which is set by > > >>> hand and is the same for all L): > > >>> > > >>> ff(1,L) = RO(L)-OLD(1,L)-TSF(L)*DRO(L) > > >>> ff(2,L) = RU(L)-OLD(2,L)-TSF(L)*DRU(L) > > >>> ff(3,L) = RV(L)-OLD(3,L)-TSF(L)*DRV(L) > > >>> ff(4,L) = RW(L)-OLD(4,L)-TSF(L)*DRW(L) > > >>> ff(5,L) = ET(L)-OLD(5,L)-TSF(L)*DET(L) > > >>> ff(6,L) = RQ(L)-OLD(6,L)-TSF(L)*DRQ(L) > > >>> ff(7,L) = REPS(L)-OLD(7,L)-TSF(L)*DREPS(L) > > >>> > > >>> And save the new value of RO-REPS to use in the next iteration of back-euler: > > >>> > > >>> OLD(1,L)=RO(L) > > >>> OLD(2,L)=RU(L) > > >>> OLD(3,L)=RV(L) > > >>> OLD(4,L)=RW(L) > > >>> OLD(5,L)=ET(L) > > >>> OLD(6,L)=RQ(L) > > >>> OLD(7,L)=REPS(L) > > >>> > > >>> Here I print the values of L=2 as above for debugging: > > >>> > > >>> write(6,*)ff(5,2)," = ",ET(2),"-",OLD(5,2),"-",TSF(2),"*",DET(2) > > >>> > > >>> > > >>> > > >>> The program exit abnormaly after 33 runs of the FormFunction. The > > >>> cause of this is that AUXVR tries to perform sqrt(ET(2)) when ET(2) is > > >>> negative, ET is the total energy and should never be negative. It > > >>> seems that all of a sudden the PETSc SNES solver decides to supply the > > >>> FormFunction with a negative ET value. I need help understanding why > > >>> and how to fix it (if it is fixable). > > >>> > > >>> Here is the output of: > > >>> write(6,*)"ET(2) = xx(5,2) : ",ET(2)," = ",xx(5,2) > > >>> Which is in the beginning of my FormFunction. > > >>> And: > > >>> write(6,*)ff(5,2)," = ",ET(2),"-",OLD(5,2),"-",TSF(2),"*",DET(2) > > >>> Which is in the end of my Formfunction. > > >>> > > >>> 1. ET(2) = xx(5,2) : 253250. = 253250.000000000 > > >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > > >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > > >>> 2. ET(2) = xx(5,2) : 253250. = 253250.000010259 > > >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > > >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > > >>> 3. ET(2) = xx(5,2) : 253250. = 253249.999999988 > > >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4132419437260 = > > >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941324E+08 > > >>> 4. ET(2) = xx(5,2) : 253250. = 253250.000048432 > > >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > > >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > > >>> 5. ET(2) = xx(5,2) : 253250. = 253249.999999872 > > >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4177283437784 = > > >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941773E+08 > > >>> 6. ET(2) = xx(5,2) : 253250. = 253250.000071113 > > >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > > >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > > >>> 7. ET(2) = xx(5,2) : 253250. = 253249.999980115 > > >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4453347441010 = > > >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.944533E+08 > > >>> 8. ET(2) = xx(5,2) : 253250. = 253250.000037298 > > >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4082723436679 = > > >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940827E+08 > > >>> 9. ET(2) = xx(5,2) : 253250. = 253249.999942706 > > >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4082723436679 = > > >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940827E+08 > > >>> 10. ET(2) = xx(5,2) : 253250. = 253249.999948703 > > >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > > >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > > >>> 11. ET(2) = xx(5,2) : 253250. = 253250.000007808 > > >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.7283811474088 = > > >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.972838E+08 > > >>> 12. ET(2) = xx(5,2) : 253250. = 253250.000018146 > > >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > > >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > > >>> 13. ET(2) = xx(5,2) : 253250. = 253250.000001865 > > >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 28.3742819315846 = > > >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.837428E+08 > > >>> 14. ET(2) = xx(5,2) : 253250. = 253249.999997296 > > >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > > >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > > >>> 15. ET(2) = xx(5,2) : 253250. = 253250.000000049 > > >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 30.6548963582361 = > > >>> 253250. - 253250.000000000 - 1.000000E-07 * -3.065490E+08 > > >>> 16. ET(2) = xx(5,2) : 253250. = 253250.000022870 > > >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > > >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > > >>> 17. ET(2) = xx(5,2) : 253250. = 253249.999999716 > > >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.5326051451209 = > > >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.953260E+08 > > >>> 18. ET(2) = xx(5,2) : 253250. = 253250.000074328 > > >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4165187437643 = > > >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941652E+08 > > >>> 19. ET(2) = xx(5,2) : 253250. = 253250.000049809 > > >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4085059436707 = > > >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940851E+08 > > >>> 20. ET(2) = xx(5,2) : 253250. = 253250.000019253 > > >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > > >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > > >>> 21. ET(2) = xx(5,2) : 253250. = 253250.000000189 > > >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.8851075492403 = > > >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.988511E+08 > > >>> 22. ET(2) = xx(5,2) : 253250. = 253249.999997897 > > >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4085059436707 = > > >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940851E+08 > > >>> 23. ET(2) = xx(5,2) : 253250. = 253249.999975142 > > >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.3961539435263 = > > >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.939615E+08 > > >>> 24. ET(2) = xx(5,2) : 253250. = 253250.000018324 > > >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4085059436707 = > > >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940851E+08 > > >>> 25. ET(2) = xx(5,2) : 253250. = 253249.999987073 > > >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4165187437643 = > > >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941652E+08 > > >>> 26. ET(2) = xx(5,2) : 253250. = 253249.999980982 > > >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4165187437643 = > > >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941652E+08 > > >>> 27. ET(2) = xx(5,2) : 253250. = 253249.999994645 > > >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > > >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > > >>> 28. ET(2) = xx(5,2) : 253250. = 253249.999962364 > > >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4165187437643 = > > >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941652E+08 > > >>> 29. ET(2) = xx(5,2) : 253250. = 253249.999999921 > > >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > > >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > > >>> 30. ET(2) = xx(5,2) : 253250. = 253250.000000058 > > >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 28.4019971319085 = > > >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.840200E+08 > > >>> 31. ET(2) = xx(5,2) : 253250. = 253250.000040348 > > >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4085059436707 = > > >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940851E+08 > > >>> 32. ET(2) = xx(5,2) : 253250. = 253250.000005245 > > >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > > >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > > >>> 33. ET(2) = xx(5,2) : 253250. = 253250.000005245 > > >>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > > >>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > > >>> 34. ET(2) = xx(5,2) : -848141. = -848141.388090847 > > >>> -------------------------------------------------------------------------- > > >>> 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. > > >>> ----------------------------------------------------------------------- > > >>> ./SNESG3D2 on a linux-gnu named sethnx004.vac.com by yy26539 Mon Feb > > >>> 27 14:21:13 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] SNES user function line 0 unknownunknown > > >>> [0]PETSC ERROR: [0] SNESComputeFunction line 788 src/snes/interface/snes.c > > >>> [0]PETSC ERROR: [0] SNESLineSearchCubic line 514 src/snes/impls/ls/ls.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: ! > > >>> > > >>> > > >>> Suggestions and tips are very welcome! > > >>> /nisse > > >>> > > >>> > > >>> -- > > >>> Nils-Erik Svang???rd > > >>> MSN: schweingaard at hotmail.com > > >>> Skype: schweingaard > > >>> > > >>> > > >> > > > > > > > > > -- > > > Nils-Erik Svang?rd > > > MSN: schweingaard at hotmail.com > > > Skype: schweingaard > > > > > > > > > > > -- > 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 From billy at dem.uminho.pt Fri Mar 3 10:41:47 2006 From: billy at dem.uminho.pt (billy at dem.uminho.pt) Date: Fri, 3 Mar 2006 16:41:47 +0000 Subject: Matrix convergence. In-Reply-To: References: <1141321382.44072ea6da75b@serv-g1.ccom.uminho.pt> Message-ID: <1141404107.440871cb0f016@serv-g1.ccom.uminho.pt> Hi, I tried to solve the 18x18 matrix with laspack and the results are the following: Solver: GMRES, Preconditioning: NULL, Iterations: 500, Residual: 6.16E-2 Solver: GMRES, Preconditioning: SSOR, Iterations: 500, Residual: 6.57E-2 Solver: GMRES, Preconditioning: ILU, ERROR Solver: BiCGSTAB, Preconditioning: NULL, Iterations: 101, Residual: 8.88E-7 Solver: BiCGSTAB, Preconditioning: SSOR, Iterations: 36, Residual: 9.87E-7 Solver: BiCGSTAB, Preconditioning: ILU, ERROR Billy. Quoting Barry Smith : > > Billy, > > Most likely there is something wrong with the matrix being > generated. I would first look at the matrix entries and make > sure they make sense. Then I would solve the linear systems > with a direct solver -pc_type lu (on one processor and make > sure the solutions are reasonable and your simulation has > "correct" answers). > > It is possible the parallel matrix generation is wrong, > > Barry > > > On Thu, 2 Mar 2006, billy at dem.uminho.pt wrote: > > > > > Hi, > > > > > > I have been testing my parallel implementation with a 2D case. I have used > the > > following grids with 2 and 4 processes: 4x4, 10x10, 16x16 and 18x18. > > > > It works for the first three (max. number of iterations to converge aprox. > 70) > > but when I increase to 18x18 the matrix does not converge. I have increased > the > > maximum number of iterations and I have used GMRES, BiCGSTAB with > > preconditioners ASM, JACOBI, etc. > > > > With KSPType = GMRES and PCType = ASM: > > Number of iterations: 500 Residual: +1.420471E-01 > > > > With KSPType = GMRES and PCType = JACOBI: > > Number of iterations: 500 Residual: +2.351882E-02 > > > > With KSPType = BCGS and PCType = ASM: > > Number of iterations: 136 Residual: +3.911446E+04 > > > > With KSPType = BCGS and PCType = NULL: > > Number of iterations: 157 Residual: +3.254728E+03 > > > > Is it normal that the convergence detiorates so much with such a slight > increase > > in the dimension of the matrix? Is there any optimization parameter that I > may > > be missing? > > > > > > Billy. > > > > > > From bsmith at mcs.anl.gov Fri Mar 3 11:38:43 2006 From: bsmith at mcs.anl.gov (Barry Smith) Date: Fri, 3 Mar 2006 11:38:43 -0600 (CST) Subject: Matrix convergence. In-Reply-To: <1141404107.440871cb0f016@serv-g1.ccom.uminho.pt> References: <1141321382.44072ea6da75b@serv-g1.ccom.uminho.pt> <1141404107.440871cb0f016@serv-g1.ccom.uminho.pt> Message-ID: Run the parallel PETSc job with -ksp_type gmres -ksp_gmres_restart 200 -sub_pc_type lu On Fri, 3 Mar 2006, billy at dem.uminho.pt wrote: > Hi, > > I tried to solve the 18x18 matrix with laspack and the results are the following: > > Solver: GMRES, Preconditioning: NULL, Iterations: 500, Residual: 6.16E-2 > Solver: GMRES, Preconditioning: SSOR, Iterations: 500, Residual: 6.57E-2 > Solver: GMRES, Preconditioning: ILU, ERROR > > Solver: BiCGSTAB, Preconditioning: NULL, Iterations: 101, Residual: 8.88E-7 > Solver: BiCGSTAB, Preconditioning: SSOR, Iterations: 36, Residual: 9.87E-7 > Solver: BiCGSTAB, Preconditioning: ILU, ERROR > > > Billy. > > > Quoting Barry Smith : > >> >> Billy, >> >> Most likely there is something wrong with the matrix being >> generated. I would first look at the matrix entries and make >> sure they make sense. Then I would solve the linear systems >> with a direct solver -pc_type lu (on one processor and make >> sure the solutions are reasonable and your simulation has >> "correct" answers). >> >> It is possible the parallel matrix generation is wrong, >> >> Barry >> >> >> On Thu, 2 Mar 2006, billy at dem.uminho.pt wrote: >> >>> >>> Hi, >>> >>> >>> I have been testing my parallel implementation with a 2D case. I have used >> the >>> following grids with 2 and 4 processes: 4x4, 10x10, 16x16 and 18x18. >>> >>> It works for the first three (max. number of iterations to converge aprox. >> 70) >>> but when I increase to 18x18 the matrix does not converge. I have increased >> the >>> maximum number of iterations and I have used GMRES, BiCGSTAB with >>> preconditioners ASM, JACOBI, etc. >>> >>> With KSPType = GMRES and PCType = ASM: >>> Number of iterations: 500 Residual: +1.420471E-01 >>> >>> With KSPType = GMRES and PCType = JACOBI: >>> Number of iterations: 500 Residual: +2.351882E-02 >>> >>> With KSPType = BCGS and PCType = ASM: >>> Number of iterations: 136 Residual: +3.911446E+04 >>> >>> With KSPType = BCGS and PCType = NULL: >>> Number of iterations: 157 Residual: +3.254728E+03 >>> >>> Is it normal that the convergence detiorates so much with such a slight >> increase >>> in the dimension of the matrix? Is there any optimization parameter that I >> may >>> be missing? >>> >>> >>> Billy. >>> >>> >> >> > > > From knepley at mcs.anl.gov Fri Mar 3 11:40:08 2006 From: knepley at mcs.anl.gov (Matthew Knepley) Date: Fri, 03 Mar 2006 11:40:08 -0600 Subject: Matrix convergence. In-Reply-To: <1141404107.440871cb0f016@serv-g1.ccom.uminho.pt> (billy@dem.uminho.pt's message of "Fri, 3 Mar 2006 16:41:47 +0000") References: <1141321382.44072ea6da75b@serv-g1.ccom.uminho.pt> <1141404107.440871cb0f016@serv-g1.ccom.uminho.pt> Message-ID: billy at dem.uminho.pt writes: I don't understand. LAPACK does not have these iterative methods? Matt > Hi, > > I tried to solve the 18x18 matrix with laspack and the results are the following: > > Solver: GMRES, Preconditioning: NULL, Iterations: 500, Residual: 6.16E-2 > Solver: GMRES, Preconditioning: SSOR, Iterations: 500, Residual: 6.57E-2 > Solver: GMRES, Preconditioning: ILU, ERROR > > Solver: BiCGSTAB, Preconditioning: NULL, Iterations: 101, Residual: 8.88E-7 > Solver: BiCGSTAB, Preconditioning: SSOR, Iterations: 36, Residual: 9.87E-7 > Solver: BiCGSTAB, Preconditioning: ILU, ERROR > > > Billy. > > > Quoting Barry Smith : > >> >> Billy, >> >> Most likely there is something wrong with the matrix being >> generated. I would first look at the matrix entries and make >> sure they make sense. Then I would solve the linear systems >> with a direct solver -pc_type lu (on one processor and make >> sure the solutions are reasonable and your simulation has >> "correct" answers). >> >> It is possible the parallel matrix generation is wrong, >> >> Barry >> >> >> On Thu, 2 Mar 2006, billy at dem.uminho.pt wrote: >> >> > >> > Hi, >> > >> > >> > I have been testing my parallel implementation with a 2D case. I have used >> the >> > following grids with 2 and 4 processes: 4x4, 10x10, 16x16 and 18x18. >> > >> > It works for the first three (max. number of iterations to converge aprox. >> 70) >> > but when I increase to 18x18 the matrix does not converge. I have increased >> the >> > maximum number of iterations and I have used GMRES, BiCGSTAB with >> > preconditioners ASM, JACOBI, etc. >> > >> > With KSPType = GMRES and PCType = ASM: >> > Number of iterations: 500 Residual: +1.420471E-01 >> > >> > With KSPType = GMRES and PCType = JACOBI: >> > Number of iterations: 500 Residual: +2.351882E-02 >> > >> > With KSPType = BCGS and PCType = ASM: >> > Number of iterations: 136 Residual: +3.911446E+04 >> > >> > With KSPType = BCGS and PCType = NULL: >> > Number of iterations: 157 Residual: +3.254728E+03 >> > >> > Is it normal that the convergence detiorates so much with such a slight >> increase >> > in the dimension of the matrix? Is there any optimization parameter that I >> may >> > be missing? >> > >> > >> > Billy. >> > >> > >> >> > > > > -- "Failure has a thousand explanations. Success doesn't need one" -- Sir Alec Guiness From bsmith at mcs.anl.gov Fri Mar 3 11:48:03 2006 From: bsmith at mcs.anl.gov (Barry Smith) Date: Fri, 3 Mar 2006 11:48:03 -0600 (CST) Subject: Matrix convergence. In-Reply-To: References: <1141321382.44072ea6da75b@serv-g1.ccom.uminho.pt> <1141404107.440871cb0f016@serv-g1.ccom.uminho.pt> Message-ID: Matt, Learn how to read! Barry On Fri, 3 Mar 2006, Matthew Knepley wrote: > billy at dem.uminho.pt writes: > > I don't understand. LAPACK does not have these iterative methods? > > Matt > >> Hi, >> >> I tried to solve the 18x18 matrix with laspack and the results are the following: >> >> Solver: GMRES, Preconditioning: NULL, Iterations: 500, Residual: 6.16E-2 >> Solver: GMRES, Preconditioning: SSOR, Iterations: 500, Residual: 6.57E-2 >> Solver: GMRES, Preconditioning: ILU, ERROR >> >> Solver: BiCGSTAB, Preconditioning: NULL, Iterations: 101, Residual: 8.88E-7 >> Solver: BiCGSTAB, Preconditioning: SSOR, Iterations: 36, Residual: 9.87E-7 >> Solver: BiCGSTAB, Preconditioning: ILU, ERROR >> >> >> Billy. >> >> >> Quoting Barry Smith : >> >>> >>> Billy, >>> >>> Most likely there is something wrong with the matrix being >>> generated. I would first look at the matrix entries and make >>> sure they make sense. Then I would solve the linear systems >>> with a direct solver -pc_type lu (on one processor and make >>> sure the solutions are reasonable and your simulation has >>> "correct" answers). >>> >>> It is possible the parallel matrix generation is wrong, >>> >>> Barry >>> >>> >>> On Thu, 2 Mar 2006, billy at dem.uminho.pt wrote: >>> >>>> >>>> Hi, >>>> >>>> >>>> I have been testing my parallel implementation with a 2D case. I have used >>> the >>>> following grids with 2 and 4 processes: 4x4, 10x10, 16x16 and 18x18. >>>> >>>> It works for the first three (max. number of iterations to converge aprox. >>> 70) >>>> but when I increase to 18x18 the matrix does not converge. I have increased >>> the >>>> maximum number of iterations and I have used GMRES, BiCGSTAB with >>>> preconditioners ASM, JACOBI, etc. >>>> >>>> With KSPType = GMRES and PCType = ASM: >>>> Number of iterations: 500 Residual: +1.420471E-01 >>>> >>>> With KSPType = GMRES and PCType = JACOBI: >>>> Number of iterations: 500 Residual: +2.351882E-02 >>>> >>>> With KSPType = BCGS and PCType = ASM: >>>> Number of iterations: 136 Residual: +3.911446E+04 >>>> >>>> With KSPType = BCGS and PCType = NULL: >>>> Number of iterations: 157 Residual: +3.254728E+03 >>>> >>>> Is it normal that the convergence detiorates so much with such a slight >>> increase >>>> in the dimension of the matrix? Is there any optimization parameter that I >>> may >>>> be missing? >>>> >>>> >>>> Billy. >>>> >>>> >>> >>> >> >> >> >> > > From bsmith at mcs.anl.gov Fri Mar 3 11:50:02 2006 From: bsmith at mcs.anl.gov (Barry Smith) Date: Fri, 3 Mar 2006 11:50:02 -0600 (CST) Subject: SNES Problem In-Reply-To: <82f936c20603030158u33722ff0q3c50839df14841@mail.gmail.com> References: <82f936c20602270607t775d7e03o6a37afa4c0b3d2a8@mail.gmail.com> <82f936c20603020529j6d4181c8pc75c980357df9aa3@mail.gmail.com> <82f936c20603030047m5f64406n1435ca60f306fa98@mail.gmail.com> <82f936c20603030158u33722ff0q3c50839df14841@mail.gmail.com> Message-ID: There must be a difference between the two RKs. The initial timestep it uses, or algorithm for changing time step or slight difference in algorithms? Barry On Fri, 3 Mar 2006, Nils Erik Svang?rd wrote: > A interesting thing is when I change TS_BEULER to TS_RUNGE_KUTTA the > solver exits fast due to the non physical values. My original solver > is a 3-step Runge-Kutta which works flawlessly. > > The error when running RK: > > ./ImplicitG3D on a linux-gnu named sethnx004.vac.com by yy26539 Fri > Mar 3 10:31:27 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] TS user right-hand-side function line 0 unknownunknown > [0]PETSC ERROR: [0] TSComputeRHSFunction line 282 src/ts/interface/ts.c > [0]PETSC ERROR: [0] TSRkqs line 256 src/ts/impls/explicit/rk/rk.c > [0]PETSC ERROR: [0] TSStep_Rk line 322 src/ts/impls/explicit/rk/rk.c > [0]PETSC ERROR: [0] TSStep line 1520 src/ts/interface/ts.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 > > On 3/3/06, Nils Erik Svang?rd wrote: >> Hello again, >> >> > Is it just not compiling because PETSC_ERR_ARG_DOMAIN is not >>> defined? Or does it still not work even when you have put the number in? >>> What is the error? Or did you get it all working with SNES? >>> >> >> >> It is not compiling because PETSC_ERR_ARG_DOMAIN is not defined: >> >> error on line 585 of SNESG3D2.F: data type is undefined for variable >> PETSC_ERR_ARG_DOMAIN >> >> I tried putting a number in, then it compiles but complains while >> linking that the Push() and Pop() functions is not defined. I made a >> workaround by adding a variable in a common block and setting it >> before returning from a non physical value in the FormFunction. Now I >> can compile and when there is a non-physical value it returns and >> resumes with a smaller timestep. >> SNES still give non physical values which are hard to add checks for >> in the program (e.g sqrt(RO(L)-RO(L+1))). >> >> Did I understand correctly that SNES does a linesearch and probably >> goes for a solution which isnt the one I looking for? Does SNES use >> the linesearch algorithm when I use -snes_mf (which I use)? >> >>> It may work automatically with TS; you would just set TS with a >>> smaller timestep and call TSSolve again? >>> >> >> OK, I'll add a check and put TSSolve in a while loop. >> >> My SNESSolve loop looks like this right now: >> call VecCreateSeq(PETSC_COMM_SELF,N,x,ierr) >> call VecDuplicate(x,r,ierr) >> call VecDuplicate(x,xb,ierr) >> call SNESCreate(PETSC_COMM_SELF,snes,ierr) >> call SNESSetFunction(snes,r,FormFunction,PETSC_NULL_OBJECT,ierr) >> call SNESSetFromOptions(snes,ierr) >> call FormInitialGuess(x,ierr) >> call VecCopy(x,xb,ierr) >> write(6,*)zero,dt,tmax,i1000 >> step=0 >> timestep=dt >> bang=0 >> C While loop >> 10 if (step .le. 100) then >> C call PetscExceptionPush(87,ierr) >> C call PetscExceptionPush(PETSC_ERR_ARG_DOMAIN,ierr) >> call SNESSolve(snes,PETSC_NULL_OBJECT,x,ierr) >> ierr=bang >> C call PetscExceptionPop(87,ierr2) >> IF ( ierr .EQ. 87) THEN >> timestep=timestep/2 >> call VecCopy(xb,x,ierr) >> write(6,*) "No physical solution, trying", >> . " with smaller timestep: ",timestep >> bang=0 >> ELSE >> call SNESGetConvergedReason(snes,reason,ierr) >> IF ( reason .LT. 0 ) THEN >> timestep=timestep/2 >> call VecCopy(xb,x,ierr) >> write(6,*)"Solution diverged, trying with", >> . " smaller timestep: ",timestep >> ELSE >> timestep=dt >> step=step+1 >> call VecCopy(x,xb,ierr) >> write(6,*) "Solve success, going for step: ",step >> write(6,*) "Reason: ",reason," ierr: ",ierr >> reason=0 >> ierr=0 >> ENDIF >> ENDIF >> goto 10 >> endif >> C End While loop >> >> And the check in the FormFunction: >> >> if (ET(L) .LT. 0) then >> ierr = 87 >> bang = 87 >> C SETERRQ(87,"Non physical value!",ierr) >> return >> elseif ( RO(L) .LT. 0 ) then >> ierr = 87 >> bang = 87 >> return >> endif >> >> >> /nisse >> >> >> >>> Barry >>> >>> I'm adding a petscerror.h for Fortran that includes these values >>> Sorry I forgot we hadn't given them for Fortran. >>> >>> On Thu, 2 Mar 2006, Nils Erik Svang?rd wrote: >>> >>>> Hi again, >>>> I realised that my implementation was a bit flawed so I have rewritten >>>> it again, the push and pop() functions dont seem to work, and they are >>>> keeping me from compiling the program, this is the main timestep loop: >>>> >>>> call VecCreateSeq(PETSC_COMM_SELF,N,x,ierr) >>>> call VecDuplicate(x,r,ierr) >>>> call VecDuplicate(x,xb,ierr) >>>> call SNESCreate(PETSC_COMM_SELF,snes,ierr) >>>> call SNESSetFunction(snes,r,FormFunction,PETSC_NULL_OBJECT,ierr) >>>> call SNESSetFromOptions(snes,ierr) >>>> call FormInitialGuess(x,ierr) >>>> call VecCopy(x,xb,ierr) >>>> write(6,*)zero,dt,tmax,i1000 >>>> step=0 >>>> timestep=dt >>>> C While loop >>>> 10 if (step .le. 100) then >>>> call PetscExceptionPush(87,ierr) >>>> call SNESSolve(snes,PETSC_NULL_OBJECT,x,ierr) >>>> call PetscExceptionPop(87,ierr2) >>>> >>>> call SNESGetConvergedReason(snes,reason,ierr) >>>> IF ( reason .LT. 0 ) THEN >>>> timestep=timestep/2 >>>> VecCopy(xb,x,ierr) >>>> write(6,*)"Solution diverged, trying with", >>>> . " smaller timestep: ",timestep >>>> ELSE >>>> IF ( ierr .EQ. 87) THEN >>>> timestep=timestep/2 >>>> VecCopy(xb,x,ierr) >>>> write(6,*) "No physical solution, trying", >>>> . " with smaller timestep: ",timestep >>>> ELSE >>>> timestep=dt >>>> step=step+1 >>>> VecCopy(x,xb,ierr) >>>> write(6,*) "Solve success, going for step: ",step >>>> ENDIF >>>> ENDIF >>>> goto 10 >>>> endif >>>> C End While loop >>>> >>>> And in my Formfunction I have added the following check: >>>> if (ET(L) .LT. 0) then >>>> ierr = 87 >>>> return >>>> endif >>>> >>>> PETSC_ERR_ARG_DOMAIN didnt work: error on line 6500 of SNESG3D2.F: >>>> data type is undefined for variable PETSC_ERR_ARG_DOMAIN >>>> Even thought I had petsc.h included. >>>> >>>> Can I do this check when I use TS also? I have the sameproblem with >>>> the values being negative when using TS. >>>> >>>> >>>> /nisse >>>> >>>> >>>> On 2/27/06, Barry Smith wrote: >>>>> >>>>> SNES works by computing p = -approxinv(J)*F(uold) and >>>>> then does a line search on unew = uold + lambda*p to get the >>>>> new u. First it uses a test value of 1 for lambda so it >>>>> tries to compute F(uold + p). It is possible that uold + p >>>>> has some "non-physical" values in it. There are two ways >>>>> you can try handling it: >>>>> >>>>> 1) Before doing the linesearch SNES calls a "precheck" function, >>>>> that can change the step if it decides there is a problem >>>>> with the step (like it is too long). You can provide your >>>>> own precheck function with SNESLineSearchSetPreCheck() it could, >>>>> for example, shrink the Newton direction to make it remain physical. >>>>> >>>>> or 2) when your form function detects an illegal value it calls >>>>> SETERRQ(PETSC_ERR_ARG_DOMAIN,"Nonphysical function input"); Note: >>>>> this is before it takes the square root of the negative number, >>>>> so check the number and call the error before calling SETERRQ(). >>>>> (If using Fortran then simply set ierr = PETSC_ERR_ARG_DOMAIN and >>>>> then immediately return). Then replace your call to SNESSolve with >>>>> ierr = PetscExceptionTry1(SNESSolve(snes,b,x),PETSC_ERR_ARG_DOMAIN); >>>>> if (PetscExceptionCaught(ierr,PETSC_ERR_ARG_DOMAIN)) { >>>>> /* this means your function found a non-physical value so >>>>> cut your time-step and continue through the loop again. */ >>>>> Put code to do this here. >>>>> } >>>>> If using fortran then do >>>>> call PetscExceptionPush(PETSC_ERR_ARG_DOMAIN,ierr) >>>>> call SNESSolve(snes,b,x,ierr) >>>>> call PetscExceptionPop(PETSC_ERR_ARG_DOMAIN,anotherierr) >>>>> if (ierr == PETSC_ERR_ARG_DOMAIN) then >>>>> non-physical value so cut the time-step and try again >>>>> else ! everything is normal so take the next time-step >>>>> >>>>> Barry >>>>> >>>>> The Fortran interface may be missing PetscExceptionPush() and Pop() >>>>> if so let us know and we'll provide the patch. >>>>> >>>>> On Mon, 27 Feb 2006, Nils Erik Svang?rd wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> I have problems solving some CFD problems using SNES and my custom >>>>>> back-euler. I have 7 equations that I want to solve. >>>>>> >>>>>> First my FormFunction copies the values from the Vec that SNES uses to >>>>>> the variables that my code use: >>>>>> >>>>>> RO(L)=xx(1,L) >>>>>> RU(L)=xx(2,L) >>>>>> RV(L)=xx(3,L) >>>>>> RW(L)=xx(4,L) >>>>>> ET(L)=xx(5,L) >>>>>> RQ(L)= xx(6,L) >>>>>> REPS(L)=xx(7,L) >>>>>> >>>>>> Here I also print the values of ET(2) for debugging: >>>>>> >>>>>> write(6,*)"ET(2) = xx(5,2) : ",ET(2)," = ",xx(5,2) >>>>>> >>>>>> Then I get the fluxes by calling custom functions >>>>>> >>>>>> call AUXVR >>>>>> call VGRAD >>>>>> call FLUX >>>>>> call KESRC >>>>>> >>>>>> Then I perform back-euler save the new value to so that I can use it >>>>>> in the next iterationi (TSF(L) is Time step function, which is set by >>>>>> hand and is the same for all L): >>>>>> >>>>>> ff(1,L) = RO(L)-OLD(1,L)-TSF(L)*DRO(L) >>>>>> ff(2,L) = RU(L)-OLD(2,L)-TSF(L)*DRU(L) >>>>>> ff(3,L) = RV(L)-OLD(3,L)-TSF(L)*DRV(L) >>>>>> ff(4,L) = RW(L)-OLD(4,L)-TSF(L)*DRW(L) >>>>>> ff(5,L) = ET(L)-OLD(5,L)-TSF(L)*DET(L) >>>>>> ff(6,L) = RQ(L)-OLD(6,L)-TSF(L)*DRQ(L) >>>>>> ff(7,L) = REPS(L)-OLD(7,L)-TSF(L)*DREPS(L) >>>>>> >>>>>> And save the new value of RO-REPS to use in the next iteration of back-euler: >>>>>> >>>>>> OLD(1,L)=RO(L) >>>>>> OLD(2,L)=RU(L) >>>>>> OLD(3,L)=RV(L) >>>>>> OLD(4,L)=RW(L) >>>>>> OLD(5,L)=ET(L) >>>>>> OLD(6,L)=RQ(L) >>>>>> OLD(7,L)=REPS(L) >>>>>> >>>>>> Here I print the values of L=2 as above for debugging: >>>>>> >>>>>> write(6,*)ff(5,2)," = ",ET(2),"-",OLD(5,2),"-",TSF(2),"*",DET(2) >>>>>> >>>>>> >>>>>> >>>>>> The program exit abnormaly after 33 runs of the FormFunction. The >>>>>> cause of this is that AUXVR tries to perform sqrt(ET(2)) when ET(2) is >>>>>> negative, ET is the total energy and should never be negative. It >>>>>> seems that all of a sudden the PETSc SNES solver decides to supply the >>>>>> FormFunction with a negative ET value. I need help understanding why >>>>>> and how to fix it (if it is fixable). >>>>>> >>>>>> Here is the output of: >>>>>> write(6,*)"ET(2) = xx(5,2) : ",ET(2)," = ",xx(5,2) >>>>>> Which is in the beginning of my FormFunction. >>>>>> And: >>>>>> write(6,*)ff(5,2)," = ",ET(2),"-",OLD(5,2),"-",TSF(2),"*",DET(2) >>>>>> Which is in the end of my Formfunction. >>>>>> >>>>>> 1. ET(2) = xx(5,2) : 253250. = 253250.000000000 >>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>>>>> 2. ET(2) = xx(5,2) : 253250. = 253250.000010259 >>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>>>>> 3. ET(2) = xx(5,2) : 253250. = 253249.999999988 >>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4132419437260 = >>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941324E+08 >>>>>> 4. ET(2) = xx(5,2) : 253250. = 253250.000048432 >>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>>>>> 5. ET(2) = xx(5,2) : 253250. = 253249.999999872 >>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4177283437784 = >>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941773E+08 >>>>>> 6. ET(2) = xx(5,2) : 253250. = 253250.000071113 >>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>>>>> 7. ET(2) = xx(5,2) : 253250. = 253249.999980115 >>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4453347441010 = >>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.944533E+08 >>>>>> 8. ET(2) = xx(5,2) : 253250. = 253250.000037298 >>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4082723436679 = >>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940827E+08 >>>>>> 9. ET(2) = xx(5,2) : 253250. = 253249.999942706 >>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4082723436679 = >>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940827E+08 >>>>>> 10. ET(2) = xx(5,2) : 253250. = 253249.999948703 >>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>>>>> 11. ET(2) = xx(5,2) : 253250. = 253250.000007808 >>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.7283811474088 = >>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.972838E+08 >>>>>> 12. ET(2) = xx(5,2) : 253250. = 253250.000018146 >>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>>>>> 13. ET(2) = xx(5,2) : 253250. = 253250.000001865 >>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 28.3742819315846 = >>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.837428E+08 >>>>>> 14. ET(2) = xx(5,2) : 253250. = 253249.999997296 >>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>>>>> 15. ET(2) = xx(5,2) : 253250. = 253250.000000049 >>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 30.6548963582361 = >>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -3.065490E+08 >>>>>> 16. ET(2) = xx(5,2) : 253250. = 253250.000022870 >>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>>>>> 17. ET(2) = xx(5,2) : 253250. = 253249.999999716 >>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.5326051451209 = >>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.953260E+08 >>>>>> 18. ET(2) = xx(5,2) : 253250. = 253250.000074328 >>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4165187437643 = >>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941652E+08 >>>>>> 19. ET(2) = xx(5,2) : 253250. = 253250.000049809 >>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4085059436707 = >>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940851E+08 >>>>>> 20. ET(2) = xx(5,2) : 253250. = 253250.000019253 >>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>>>>> 21. ET(2) = xx(5,2) : 253250. = 253250.000000189 >>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.8851075492403 = >>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.988511E+08 >>>>>> 22. ET(2) = xx(5,2) : 253250. = 253249.999997897 >>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4085059436707 = >>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940851E+08 >>>>>> 23. ET(2) = xx(5,2) : 253250. = 253249.999975142 >>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.3961539435263 = >>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.939615E+08 >>>>>> 24. ET(2) = xx(5,2) : 253250. = 253250.000018324 >>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4085059436707 = >>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940851E+08 >>>>>> 25. ET(2) = xx(5,2) : 253250. = 253249.999987073 >>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4165187437643 = >>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941652E+08 >>>>>> 26. ET(2) = xx(5,2) : 253250. = 253249.999980982 >>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4165187437643 = >>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941652E+08 >>>>>> 27. ET(2) = xx(5,2) : 253250. = 253249.999994645 >>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>>>>> 28. ET(2) = xx(5,2) : 253250. = 253249.999962364 >>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4165187437643 = >>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941652E+08 >>>>>> 29. ET(2) = xx(5,2) : 253250. = 253249.999999921 >>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>>>>> 30. ET(2) = xx(5,2) : 253250. = 253250.000000058 >>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 28.4019971319085 = >>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.840200E+08 >>>>>> 31. ET(2) = xx(5,2) : 253250. = 253250.000040348 >>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4085059436707 = >>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940851E+08 >>>>>> 32. ET(2) = xx(5,2) : 253250. = 253250.000005245 >>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>>>>> 33. ET(2) = xx(5,2) : 253250. = 253250.000005245 >>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>>>>> 34. ET(2) = xx(5,2) : -848141. = -848141.388090847 >>>>>> -------------------------------------------------------------------------- >>>>>> 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. >>>>>> ----------------------------------------------------------------------- >>>>>> ./SNESG3D2 on a linux-gnu named sethnx004.vac.com by yy26539 Mon Feb >>>>>> 27 14:21:13 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] SNES user function line 0 unknownunknown >>>>>> [0]PETSC ERROR: [0] SNESComputeFunction line 788 src/snes/interface/snes.c >>>>>> [0]PETSC ERROR: [0] SNESLineSearchCubic line 514 src/snes/impls/ls/ls.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: ! >>>>>> >>>>>> >>>>>> Suggestions and tips are very welcome! >>>>>> /nisse >>>>>> >>>>>> >>>>>> -- >>>>>> Nils-Erik Svang???rd >>>>>> MSN: schweingaard at hotmail.com >>>>>> Skype: schweingaard >>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> Nils-Erik Svang?rd >>>> MSN: schweingaard at hotmail.com >>>> Skype: schweingaard >>>> >>>> >>> >> >> >> -- >> 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 > > From billy at dem.uminho.pt Fri Mar 3 12:03:34 2006 From: billy at dem.uminho.pt (billy at dem.uminho.pt) Date: Fri, 3 Mar 2006 18:03:34 +0000 Subject: Matrix convergence. In-Reply-To: References: <1141321382.44072ea6da75b@serv-g1.ccom.uminho.pt> <1141404107.440871cb0f016@serv-g1.ccom.uminho.pt> Message-ID: <1141409013.440884f603d32@serv-g1.ccom.uminho.pt> This is what I get: [0]PETSC ERROR: MatLUFactorSymbolic() line 2159 in src/mat/interface/matrix.c [0]PETSC ERROR: No support for this operation for this object type! [0]PETSC ERROR: Matrix type mpiaij symbolic LU! [0]PETSC ERROR: PCSetUp_LU() line 252 in src/ksp/pc/impls/factor/lu/lu.c [0]PETSC ERROR: PCSetUp() line 798 in src/ksp/pc/interface/precon.c [0]PETSC ERROR: KSPSetUp() line 234 in src/ksp/ksp/interface/itfunc.c [0]PETSC ERROR: KSPSolve() line 334 in src/ksp/ksp/interface/itfunc.c Quoting Barry Smith : > > Run the parallel PETSc job with -ksp_type gmres -ksp_gmres_restart 200 > -sub_pc_type lu > > > On Fri, 3 Mar 2006, billy at dem.uminho.pt wrote: > > > Hi, > > > > I tried to solve the 18x18 matrix with laspack and the results are the > following: > > > > Solver: GMRES, Preconditioning: NULL, Iterations: 500, Residual: 6.16E-2 > > Solver: GMRES, Preconditioning: SSOR, Iterations: 500, Residual: 6.57E-2 > > Solver: GMRES, Preconditioning: ILU, ERROR > > > > Solver: BiCGSTAB, Preconditioning: NULL, Iterations: 101, Residual: > 8.88E-7 > > Solver: BiCGSTAB, Preconditioning: SSOR, Iterations: 36, Residual: > 9.87E-7 > > Solver: BiCGSTAB, Preconditioning: ILU, ERROR > > > > > > Billy. > > > > > > Quoting Barry Smith : > > > >> > >> Billy, > >> > >> Most likely there is something wrong with the matrix being > >> generated. I would first look at the matrix entries and make > >> sure they make sense. Then I would solve the linear systems > >> with a direct solver -pc_type lu (on one processor and make > >> sure the solutions are reasonable and your simulation has > >> "correct" answers). > >> > >> It is possible the parallel matrix generation is wrong, > >> > >> Barry > >> > >> > >> On Thu, 2 Mar 2006, billy at dem.uminho.pt wrote: > >> > >>> > >>> Hi, > >>> > >>> > >>> I have been testing my parallel implementation with a 2D case. I have > used > >> the > >>> following grids with 2 and 4 processes: 4x4, 10x10, 16x16 and 18x18. > >>> > >>> It works for the first three (max. number of iterations to converge > aprox. > >> 70) > >>> but when I increase to 18x18 the matrix does not converge. I have > increased > >> the > >>> maximum number of iterations and I have used GMRES, BiCGSTAB with > >>> preconditioners ASM, JACOBI, etc. > >>> > >>> With KSPType = GMRES and PCType = ASM: > >>> Number of iterations: 500 Residual: +1.420471E-01 > >>> > >>> With KSPType = GMRES and PCType = JACOBI: > >>> Number of iterations: 500 Residual: +2.351882E-02 > >>> > >>> With KSPType = BCGS and PCType = ASM: > >>> Number of iterations: 136 Residual: +3.911446E+04 > >>> > >>> With KSPType = BCGS and PCType = NULL: > >>> Number of iterations: 157 Residual: +3.254728E+03 > >>> > >>> Is it normal that the convergence detiorates so much with such a slight > >> increase > >>> in the dimension of the matrix? Is there any optimization parameter that > I > >> may > >>> be missing? > >>> > >>> > >>> Billy. > >>> > >>> > >> > >> > > > > > > > > From bsmith at mcs.anl.gov Fri Mar 3 12:15:29 2006 From: bsmith at mcs.anl.gov (Barry Smith) Date: Fri, 3 Mar 2006 12:15:29 -0600 (CST) Subject: Matrix convergence. In-Reply-To: <1141409013.440884f603d32@serv-g1.ccom.uminho.pt> References: <1141321382.44072ea6da75b@serv-g1.ccom.uminho.pt> <1141404107.440871cb0f016@serv-g1.ccom.uminho.pt> <1141409013.440884f603d32@serv-g1.ccom.uminho.pt> Message-ID: You did not type it right -sub_pc_type lu not -pc_type lu On Fri, 3 Mar 2006, billy at dem.uminho.pt wrote: > > This is what I get: > > [0]PETSC ERROR: MatLUFactorSymbolic() line 2159 in src/mat/interface/matrix.c > [0]PETSC ERROR: No support for this operation for this object type! > [0]PETSC ERROR: Matrix type mpiaij symbolic LU! > [0]PETSC ERROR: PCSetUp_LU() line 252 in src/ksp/pc/impls/factor/lu/lu.c > [0]PETSC ERROR: PCSetUp() line 798 in src/ksp/pc/interface/precon.c > [0]PETSC ERROR: KSPSetUp() line 234 in src/ksp/ksp/interface/itfunc.c > [0]PETSC ERROR: KSPSolve() line 334 in src/ksp/ksp/interface/itfunc.c > > > Quoting Barry Smith : > >> >> Run the parallel PETSc job with -ksp_type gmres -ksp_gmres_restart 200 >> -sub_pc_type lu >> >> >> On Fri, 3 Mar 2006, billy at dem.uminho.pt wrote: >> >>> Hi, >>> >>> I tried to solve the 18x18 matrix with laspack and the results are the >> following: >>> >>> Solver: GMRES, Preconditioning: NULL, Iterations: 500, Residual: 6.16E-2 >>> Solver: GMRES, Preconditioning: SSOR, Iterations: 500, Residual: 6.57E-2 >>> Solver: GMRES, Preconditioning: ILU, ERROR >>> >>> Solver: BiCGSTAB, Preconditioning: NULL, Iterations: 101, Residual: >> 8.88E-7 >>> Solver: BiCGSTAB, Preconditioning: SSOR, Iterations: 36, Residual: >> 9.87E-7 >>> Solver: BiCGSTAB, Preconditioning: ILU, ERROR >>> >>> >>> Billy. >>> >>> >>> Quoting Barry Smith : >>> >>>> >>>> Billy, >>>> >>>> Most likely there is something wrong with the matrix being >>>> generated. I would first look at the matrix entries and make >>>> sure they make sense. Then I would solve the linear systems >>>> with a direct solver -pc_type lu (on one processor and make >>>> sure the solutions are reasonable and your simulation has >>>> "correct" answers). >>>> >>>> It is possible the parallel matrix generation is wrong, >>>> >>>> Barry >>>> >>>> >>>> On Thu, 2 Mar 2006, billy at dem.uminho.pt wrote: >>>> >>>>> >>>>> Hi, >>>>> >>>>> >>>>> I have been testing my parallel implementation with a 2D case. I have >> used >>>> the >>>>> following grids with 2 and 4 processes: 4x4, 10x10, 16x16 and 18x18. >>>>> >>>>> It works for the first three (max. number of iterations to converge >> aprox. >>>> 70) >>>>> but when I increase to 18x18 the matrix does not converge. I have >> increased >>>> the >>>>> maximum number of iterations and I have used GMRES, BiCGSTAB with >>>>> preconditioners ASM, JACOBI, etc. >>>>> >>>>> With KSPType = GMRES and PCType = ASM: >>>>> Number of iterations: 500 Residual: +1.420471E-01 >>>>> >>>>> With KSPType = GMRES and PCType = JACOBI: >>>>> Number of iterations: 500 Residual: +2.351882E-02 >>>>> >>>>> With KSPType = BCGS and PCType = ASM: >>>>> Number of iterations: 136 Residual: +3.911446E+04 >>>>> >>>>> With KSPType = BCGS and PCType = NULL: >>>>> Number of iterations: 157 Residual: +3.254728E+03 >>>>> >>>>> Is it normal that the convergence detiorates so much with such a slight >>>> increase >>>>> in the dimension of the matrix? Is there any optimization parameter that >> I >>>> may >>>>> be missing? >>>>> >>>>> >>>>> Billy. >>>>> >>>>> >>>> >>>> >>> >>> >>> >> >> > > > From knepley at mcs.anl.gov Fri Mar 3 13:16:03 2006 From: knepley at mcs.anl.gov (Matthew Knepley) Date: Fri, 03 Mar 2006 13:16:03 -0600 Subject: Matrix convergence. In-Reply-To: <1141409013.440884f603d32@serv-g1.ccom.uminho.pt> (billy@dem.uminho.pt's message of "Fri, 3 Mar 2006 18:03:34 +0000") References: <1141321382.44072ea6da75b@serv-g1.ccom.uminho.pt> <1141404107.440871cb0f016@serv-g1.ccom.uminho.pt> <1141409013.440884f603d32@serv-g1.ccom.uminho.pt> Message-ID: billy at dem.uminho.pt writes: Are you sure you have -pc_type bjacobi -sub_pc_type lu? Matt > This is what I get: > > [0]PETSC ERROR: MatLUFactorSymbolic() line 2159 in src/mat/interface/matrix.c > [0]PETSC ERROR: No support for this operation for this object type! > [0]PETSC ERROR: Matrix type mpiaij symbolic LU! > [0]PETSC ERROR: PCSetUp_LU() line 252 in src/ksp/pc/impls/factor/lu/lu.c > [0]PETSC ERROR: PCSetUp() line 798 in src/ksp/pc/interface/precon.c > [0]PETSC ERROR: KSPSetUp() line 234 in src/ksp/ksp/interface/itfunc.c > [0]PETSC ERROR: KSPSolve() line 334 in src/ksp/ksp/interface/itfunc.c > > > Quoting Barry Smith : > >> >> Run the parallel PETSc job with -ksp_type gmres -ksp_gmres_restart 200 >> -sub_pc_type lu >> >> >> On Fri, 3 Mar 2006, billy at dem.uminho.pt wrote: >> >> > Hi, >> > >> > I tried to solve the 18x18 matrix with laspack and the results are the >> following: >> > >> > Solver: GMRES, Preconditioning: NULL, Iterations: 500, Residual: 6.16E-2 >> > Solver: GMRES, Preconditioning: SSOR, Iterations: 500, Residual: 6.57E-2 >> > Solver: GMRES, Preconditioning: ILU, ERROR >> > >> > Solver: BiCGSTAB, Preconditioning: NULL, Iterations: 101, Residual: >> 8.88E-7 >> > Solver: BiCGSTAB, Preconditioning: SSOR, Iterations: 36, Residual: >> 9.87E-7 >> > Solver: BiCGSTAB, Preconditioning: ILU, ERROR >> > >> > >> > Billy. >> > >> > >> > Quoting Barry Smith : >> > >> >> >> >> Billy, >> >> >> >> Most likely there is something wrong with the matrix being >> >> generated. I would first look at the matrix entries and make >> >> sure they make sense. Then I would solve the linear systems >> >> with a direct solver -pc_type lu (on one processor and make >> >> sure the solutions are reasonable and your simulation has >> >> "correct" answers). >> >> >> >> It is possible the parallel matrix generation is wrong, >> >> >> >> Barry >> >> >> >> >> >> On Thu, 2 Mar 2006, billy at dem.uminho.pt wrote: >> >> >> >>> >> >>> Hi, >> >>> >> >>> >> >>> I have been testing my parallel implementation with a 2D case. I have >> used >> >> the >> >>> following grids with 2 and 4 processes: 4x4, 10x10, 16x16 and 18x18. >> >>> >> >>> It works for the first three (max. number of iterations to converge >> aprox. >> >> 70) >> >>> but when I increase to 18x18 the matrix does not converge. I have >> increased >> >> the >> >>> maximum number of iterations and I have used GMRES, BiCGSTAB with >> >>> preconditioners ASM, JACOBI, etc. >> >>> >> >>> With KSPType = GMRES and PCType = ASM: >> >>> Number of iterations: 500 Residual: +1.420471E-01 >> >>> >> >>> With KSPType = GMRES and PCType = JACOBI: >> >>> Number of iterations: 500 Residual: +2.351882E-02 >> >>> >> >>> With KSPType = BCGS and PCType = ASM: >> >>> Number of iterations: 136 Residual: +3.911446E+04 >> >>> >> >>> With KSPType = BCGS and PCType = NULL: >> >>> Number of iterations: 157 Residual: +3.254728E+03 >> >>> >> >>> Is it normal that the convergence detiorates so much with such a slight >> >> increase >> >>> in the dimension of the matrix? Is there any optimization parameter that >> I >> >> may >> >>> be missing? >> >>> >> >>> >> >>> Billy. >> >>> >> >>> >> >> >> >> >> > >> > >> > >> >> > > > > -- "Failure has a thousand explanations. Success doesn't need one" -- Sir Alec Guiness From billy at dem.uminho.pt Fri Mar 3 13:21:40 2006 From: billy at dem.uminho.pt (billy at dem.uminho.pt) Date: Fri, 3 Mar 2006 19:21:40 +0000 Subject: Matrix convergence. In-Reply-To: References: <1141321382.44072ea6da75b@serv-g1.ccom.uminho.pt> <1141404107.440871cb0f016@serv-g1.ccom.uminho.pt> <1141409013.440884f603d32@serv-g1.ccom.uminho.pt> Message-ID: <1141413700.440897443f31a@serv-g1.ccom.uminho.pt> It has improved but the residual is still over the tolerance I want, which is 1E-6. Number of iterations: 500 Residual: +5.450688E-04 Billy. Quoting Barry Smith : > > You did not type it right -sub_pc_type lu not -pc_type lu > > > On Fri, 3 Mar 2006, billy at dem.uminho.pt wrote: > > > > > This is what I get: > > > > [0]PETSC ERROR: MatLUFactorSymbolic() line 2159 in > src/mat/interface/matrix.c > > [0]PETSC ERROR: No support for this operation for this object type! > > [0]PETSC ERROR: Matrix type mpiaij symbolic LU! > > [0]PETSC ERROR: PCSetUp_LU() line 252 in src/ksp/pc/impls/factor/lu/lu.c > > [0]PETSC ERROR: PCSetUp() line 798 in src/ksp/pc/interface/precon.c > > [0]PETSC ERROR: KSPSetUp() line 234 in src/ksp/ksp/interface/itfunc.c > > [0]PETSC ERROR: KSPSolve() line 334 in src/ksp/ksp/interface/itfunc.c > > > > > > Quoting Barry Smith : > > > >> > >> Run the parallel PETSc job with -ksp_type gmres -ksp_gmres_restart > 200 > >> -sub_pc_type lu > >> > >> > >> On Fri, 3 Mar 2006, billy at dem.uminho.pt wrote: > >> > >>> Hi, > >>> > >>> I tried to solve the 18x18 matrix with laspack and the results are the > >> following: > >>> > >>> Solver: GMRES, Preconditioning: NULL, Iterations: 500, Residual: > 6.16E-2 > >>> Solver: GMRES, Preconditioning: SSOR, Iterations: 500, Residual: > 6.57E-2 > >>> Solver: GMRES, Preconditioning: ILU, ERROR > >>> > >>> Solver: BiCGSTAB, Preconditioning: NULL, Iterations: 101, Residual: > >> 8.88E-7 > >>> Solver: BiCGSTAB, Preconditioning: SSOR, Iterations: 36, Residual: > >> 9.87E-7 > >>> Solver: BiCGSTAB, Preconditioning: ILU, ERROR > >>> > >>> > >>> Billy. > >>> > >>> > >>> Quoting Barry Smith : > >>> > >>>> > >>>> Billy, > >>>> > >>>> Most likely there is something wrong with the matrix being > >>>> generated. I would first look at the matrix entries and make > >>>> sure they make sense. Then I would solve the linear systems > >>>> with a direct solver -pc_type lu (on one processor and make > >>>> sure the solutions are reasonable and your simulation has > >>>> "correct" answers). > >>>> > >>>> It is possible the parallel matrix generation is wrong, > >>>> > >>>> Barry > >>>> > >>>> > >>>> On Thu, 2 Mar 2006, billy at dem.uminho.pt wrote: > >>>> > >>>>> > >>>>> Hi, > >>>>> > >>>>> > >>>>> I have been testing my parallel implementation with a 2D case. I have > >> used > >>>> the > >>>>> following grids with 2 and 4 processes: 4x4, 10x10, 16x16 and 18x18. > >>>>> > >>>>> It works for the first three (max. number of iterations to converge > >> aprox. > >>>> 70) > >>>>> but when I increase to 18x18 the matrix does not converge. I have > >> increased > >>>> the > >>>>> maximum number of iterations and I have used GMRES, BiCGSTAB with > >>>>> preconditioners ASM, JACOBI, etc. > >>>>> > >>>>> With KSPType = GMRES and PCType = ASM: > >>>>> Number of iterations: 500 Residual: +1.420471E-01 > >>>>> > >>>>> With KSPType = GMRES and PCType = JACOBI: > >>>>> Number of iterations: 500 Residual: +2.351882E-02 > >>>>> > >>>>> With KSPType = BCGS and PCType = ASM: > >>>>> Number of iterations: 136 Residual: +3.911446E+04 > >>>>> > >>>>> With KSPType = BCGS and PCType = NULL: > >>>>> Number of iterations: 157 Residual: +3.254728E+03 > >>>>> > >>>>> Is it normal that the convergence detiorates so much with such a > slight > >>>> increase > >>>>> in the dimension of the matrix? Is there any optimization parameter > that > >> I > >>>> may > >>>>> be missing? > >>>>> > >>>>> > >>>>> Billy. > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >>> > >> > >> > > > > > > > > From bsmith at mcs.anl.gov Fri Mar 3 13:41:19 2006 From: bsmith at mcs.anl.gov (Barry Smith) Date: Fri, 3 Mar 2006 13:41:19 -0600 (CST) Subject: Matrix convergence. In-Reply-To: <1141413700.440897443f31a@serv-g1.ccom.uminho.pt> References: <1141321382.44072ea6da75b@serv-g1.ccom.uminho.pt> <1141404107.440871cb0f016@serv-g1.ccom.uminho.pt> <1141409013.440884f603d32@serv-g1.ccom.uminho.pt> <1141413700.440897443f31a@serv-g1.ccom.uminho.pt> Message-ID: Add the additional option -pc_type asm On Fri, 3 Mar 2006, billy at dem.uminho.pt wrote: > > It has improved but the residual is still over the tolerance I want, which is 1E-6. > > Number of iterations: 500 Residual: +5.450688E-04 > > Billy. > > > Quoting Barry Smith : > >> >> You did not type it right -sub_pc_type lu not -pc_type lu >> >> >> On Fri, 3 Mar 2006, billy at dem.uminho.pt wrote: >> >>> >>> This is what I get: >>> >>> [0]PETSC ERROR: MatLUFactorSymbolic() line 2159 in >> src/mat/interface/matrix.c >>> [0]PETSC ERROR: No support for this operation for this object type! >>> [0]PETSC ERROR: Matrix type mpiaij symbolic LU! >>> [0]PETSC ERROR: PCSetUp_LU() line 252 in src/ksp/pc/impls/factor/lu/lu.c >>> [0]PETSC ERROR: PCSetUp() line 798 in src/ksp/pc/interface/precon.c >>> [0]PETSC ERROR: KSPSetUp() line 234 in src/ksp/ksp/interface/itfunc.c >>> [0]PETSC ERROR: KSPSolve() line 334 in src/ksp/ksp/interface/itfunc.c >>> >>> >>> Quoting Barry Smith : >>> >>>> >>>> Run the parallel PETSc job with -ksp_type gmres -ksp_gmres_restart >> 200 >>>> -sub_pc_type lu >>>> >>>> >>>> On Fri, 3 Mar 2006, billy at dem.uminho.pt wrote: >>>> >>>>> Hi, >>>>> >>>>> I tried to solve the 18x18 matrix with laspack and the results are the >>>> following: >>>>> >>>>> Solver: GMRES, Preconditioning: NULL, Iterations: 500, Residual: >> 6.16E-2 >>>>> Solver: GMRES, Preconditioning: SSOR, Iterations: 500, Residual: >> 6.57E-2 >>>>> Solver: GMRES, Preconditioning: ILU, ERROR >>>>> >>>>> Solver: BiCGSTAB, Preconditioning: NULL, Iterations: 101, Residual: >>>> 8.88E-7 >>>>> Solver: BiCGSTAB, Preconditioning: SSOR, Iterations: 36, Residual: >>>> 9.87E-7 >>>>> Solver: BiCGSTAB, Preconditioning: ILU, ERROR >>>>> >>>>> >>>>> Billy. >>>>> >>>>> >>>>> Quoting Barry Smith : >>>>> >>>>>> >>>>>> Billy, >>>>>> >>>>>> Most likely there is something wrong with the matrix being >>>>>> generated. I would first look at the matrix entries and make >>>>>> sure they make sense. Then I would solve the linear systems >>>>>> with a direct solver -pc_type lu (on one processor and make >>>>>> sure the solutions are reasonable and your simulation has >>>>>> "correct" answers). >>>>>> >>>>>> It is possible the parallel matrix generation is wrong, >>>>>> >>>>>> Barry >>>>>> >>>>>> >>>>>> On Thu, 2 Mar 2006, billy at dem.uminho.pt wrote: >>>>>> >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> >>>>>>> I have been testing my parallel implementation with a 2D case. I have >>>> used >>>>>> the >>>>>>> following grids with 2 and 4 processes: 4x4, 10x10, 16x16 and 18x18. >>>>>>> >>>>>>> It works for the first three (max. number of iterations to converge >>>> aprox. >>>>>> 70) >>>>>>> but when I increase to 18x18 the matrix does not converge. I have >>>> increased >>>>>> the >>>>>>> maximum number of iterations and I have used GMRES, BiCGSTAB with >>>>>>> preconditioners ASM, JACOBI, etc. >>>>>>> >>>>>>> With KSPType = GMRES and PCType = ASM: >>>>>>> Number of iterations: 500 Residual: +1.420471E-01 >>>>>>> >>>>>>> With KSPType = GMRES and PCType = JACOBI: >>>>>>> Number of iterations: 500 Residual: +2.351882E-02 >>>>>>> >>>>>>> With KSPType = BCGS and PCType = ASM: >>>>>>> Number of iterations: 136 Residual: +3.911446E+04 >>>>>>> >>>>>>> With KSPType = BCGS and PCType = NULL: >>>>>>> Number of iterations: 157 Residual: +3.254728E+03 >>>>>>> >>>>>>> Is it normal that the convergence detiorates so much with such a >> slight >>>>>> increase >>>>>>> in the dimension of the matrix? Is there any optimization parameter >> that >>>> I >>>>>> may >>>>>>> be missing? >>>>>>> >>>>>>> >>>>>>> Billy. >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >>> >> >> > > > From billy at dem.uminho.pt Fri Mar 3 14:26:00 2006 From: billy at dem.uminho.pt (billy at dem.uminho.pt) Date: Fri, 3 Mar 2006 20:26:00 +0000 Subject: Matrix convergence. In-Reply-To: References: <1141321382.44072ea6da75b@serv-g1.ccom.uminho.pt> <1141404107.440871cb0f016@serv-g1.ccom.uminho.pt> <1141409013.440884f603d32@serv-g1.ccom.uminho.pt> Message-ID: <1141417560.4408a65857fa4@serv-g1.ccom.uminho.pt> Thank you for all your help. You were right, there was a problem with the matrix. It was supposed to be symmetric and it wasn't in only two rows. Billy. Quoting Barry Smith : > > You did not type it right -sub_pc_type lu not -pc_type lu > > > On Fri, 3 Mar 2006, billy at dem.uminho.pt wrote: > > > > > This is what I get: > > > > [0]PETSC ERROR: MatLUFactorSymbolic() line 2159 in > src/mat/interface/matrix.c > > [0]PETSC ERROR: No support for this operation for this object type! > > [0]PETSC ERROR: Matrix type mpiaij symbolic LU! > > [0]PETSC ERROR: PCSetUp_LU() line 252 in src/ksp/pc/impls/factor/lu/lu.c > > [0]PETSC ERROR: PCSetUp() line 798 in src/ksp/pc/interface/precon.c > > [0]PETSC ERROR: KSPSetUp() line 234 in src/ksp/ksp/interface/itfunc.c > > [0]PETSC ERROR: KSPSolve() line 334 in src/ksp/ksp/interface/itfunc.c > > > > > > Quoting Barry Smith : > > > >> > >> Run the parallel PETSc job with -ksp_type gmres -ksp_gmres_restart > 200 > >> -sub_pc_type lu > >> > >> > >> On Fri, 3 Mar 2006, billy at dem.uminho.pt wrote: > >> > >>> Hi, > >>> > >>> I tried to solve the 18x18 matrix with laspack and the results are the > >> following: > >>> > >>> Solver: GMRES, Preconditioning: NULL, Iterations: 500, Residual: > 6.16E-2 > >>> Solver: GMRES, Preconditioning: SSOR, Iterations: 500, Residual: > 6.57E-2 > >>> Solver: GMRES, Preconditioning: ILU, ERROR > >>> > >>> Solver: BiCGSTAB, Preconditioning: NULL, Iterations: 101, Residual: > >> 8.88E-7 > >>> Solver: BiCGSTAB, Preconditioning: SSOR, Iterations: 36, Residual: > >> 9.87E-7 > >>> Solver: BiCGSTAB, Preconditioning: ILU, ERROR > >>> > >>> > >>> Billy. > >>> > >>> > >>> Quoting Barry Smith : > >>> > >>>> > >>>> Billy, > >>>> > >>>> Most likely there is something wrong with the matrix being > >>>> generated. I would first look at the matrix entries and make > >>>> sure they make sense. Then I would solve the linear systems > >>>> with a direct solver -pc_type lu (on one processor and make > >>>> sure the solutions are reasonable and your simulation has > >>>> "correct" answers). > >>>> > >>>> It is possible the parallel matrix generation is wrong, > >>>> > >>>> Barry > >>>> > >>>> > >>>> On Thu, 2 Mar 2006, billy at dem.uminho.pt wrote: > >>>> > >>>>> > >>>>> Hi, > >>>>> > >>>>> > >>>>> I have been testing my parallel implementation with a 2D case. I have > >> used > >>>> the > >>>>> following grids with 2 and 4 processes: 4x4, 10x10, 16x16 and 18x18. > >>>>> > >>>>> It works for the first three (max. number of iterations to converge > >> aprox. > >>>> 70) > >>>>> but when I increase to 18x18 the matrix does not converge. I have > >> increased > >>>> the > >>>>> maximum number of iterations and I have used GMRES, BiCGSTAB with > >>>>> preconditioners ASM, JACOBI, etc. > >>>>> > >>>>> With KSPType = GMRES and PCType = ASM: > >>>>> Number of iterations: 500 Residual: +1.420471E-01 > >>>>> > >>>>> With KSPType = GMRES and PCType = JACOBI: > >>>>> Number of iterations: 500 Residual: +2.351882E-02 > >>>>> > >>>>> With KSPType = BCGS and PCType = ASM: > >>>>> Number of iterations: 136 Residual: +3.911446E+04 > >>>>> > >>>>> With KSPType = BCGS and PCType = NULL: > >>>>> Number of iterations: 157 Residual: +3.254728E+03 > >>>>> > >>>>> Is it normal that the convergence detiorates so much with such a > slight > >>>> increase > >>>>> in the dimension of the matrix? Is there any optimization parameter > that > >> I > >>>> may > >>>>> be missing? > >>>>> > >>>>> > >>>>> Billy. > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >>> > >> > >> > > > > > > > > From billy at dem.uminho.pt Sat Mar 4 10:18:09 2006 From: billy at dem.uminho.pt (billy at dem.uminho.pt) Date: Sat, 4 Mar 2006 16:18:09 +0000 Subject: Gradient at ghost cells only? Message-ID: <1141489089.4409bdc1a2a8e@serv-g1.ccom.uminho.pt> Hi, I need the gradient of 5 scalars at ghost cells and I was thinking of creating 5x3 vectors with VecCreateGhost(). Right now, I calculate the gradient during each iteration and I don't store it's value. I would like to calculate, store and exchange the gradient at the ghost cells only, to minimize memory requirements. How is the best way to do that? Billy. From knepley at mcs.anl.gov Sat Mar 4 11:22:59 2006 From: knepley at mcs.anl.gov (Matthew Knepley) Date: Sat, 4 Mar 2006 11:22:59 -0600 Subject: Gradient at ghost cells only? In-Reply-To: <1141489089.4409bdc1a2a8e@serv-g1.ccom.uminho.pt> References: <1141489089.4409bdc1a2a8e@serv-g1.ccom.uminho.pt> Message-ID: I think it would be really useful to look at the DA code first. This has all the correct structures, but a simple implementation for structured grids. For instance, the gradient is the action of the Jacobian on a vector. That is really how it should be coded. You have a bunch of local actions, and then a global assembly. Matt On 3/4/06, billy at dem.uminho.pt wrote: > > > Hi, > > I need the gradient of 5 scalars at ghost cells and I was thinking of > creating > 5x3 vectors with VecCreateGhost(). Right now, I calculate the gradient > during > each iteration and I don't store it's value. > I would like to calculate, store and exchange the gradient at the ghost > cells > only, to minimize memory requirements. How is the best way to do that? > > Billy. > > -- "Failure has a thousand explanations. Success doesn't need one" -- Sir Alec Guiness -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsmith at mcs.anl.gov Sat Mar 4 12:02:17 2006 From: bsmith at mcs.anl.gov (Barry Smith) Date: Sat, 4 Mar 2006 12:02:17 -0600 (CST) Subject: Gradient at ghost cells only? In-Reply-To: <1141489089.4409bdc1a2a8e@serv-g1.ccom.uminho.pt> References: <1141489089.4409bdc1a2a8e@serv-g1.ccom.uminho.pt> Message-ID: On Sat, 4 Mar 2006, billy at dem.uminho.pt wrote: > > Hi, > > I need the gradient of 5 scalars at ghost cells and I was thinking of creating > 5x3 vectors with VecCreateGhost(). Right now, I calculate the gradient during > each iteration and I don't store it's value. > I would like to calculate, store and exchange the gradient at the ghost cells > only, to minimize memory requirements. How is the best way to do that? ^^^^^^^ Do you not need the gradient values for the interior points? Or are you willing to recompute the gradients for the interior points? Why different? If the gradient is the same each time why not just calculate it the first time and store it for later? Don't make live complicated by using VecCreateGhost(), just compute them and store them in some array. Barry > > Billy. > > From billy at dem.uminho.pt Sat Mar 4 19:09:36 2006 From: billy at dem.uminho.pt (billy at dem.uminho.pt) Date: Sun, 5 Mar 2006 01:09:36 +0000 Subject: Gradient at ghost cells only? In-Reply-To: References: <1141489089.4409bdc1a2a8e@serv-g1.ccom.uminho.pt> Message-ID: <1141520976.440a3a507a944@serv-g1.ccom.uminho.pt> Firstly, I would like to congratulate the PETSc team for such a great code! I send you an image of my case (all indices are global). Ghost cells are in yellow and white cells are the interior cells. To calculate the gradient at a cell, I use the gauss theorem so I need all neighbor cells for that. The interior points are easy I can calculate them each time in each processor since I have a ghost cell layer. My problem is the gradient in ghost cells because I need the values at pink cells but they belong to another process. I guess I could include these pink cells also as ghost cells and then I would have access to their values. Or I could calculate the gradient and exchange it through processes using VecCreateGhost(). For now I have the code working because I only use these cell-centered gradients for non-orthogonal corrections. So, if the grid orthogonal this term is zero. Quoting Barry Smith : > > > On Sat, 4 Mar 2006, billy at dem.uminho.pt wrote: > > > > > Hi, > > > > I need the gradient of 5 scalars at ghost cells and I was thinking of > creating > > 5x3 vectors with VecCreateGhost(). Right now, I calculate the gradient > during > > each iteration and I don't store it's value. > > I would like to calculate, store and exchange the gradient at the ghost > cells > > only, to minimize memory requirements. How is the best way to do that? > ^^^^^^^ > Do you not need the gradient values for the interior points? Or are you > > willing to recompute the gradients for the interior points? Why different? > > If the gradient is the same each time why not just calculate it the > first > time and store it for later? Don't make live complicated by using > VecCreateGhost(), just compute them and store them in some array. > > Barry > > > > > > Billy. > > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: cells.png Type: image/png Size: 10524 bytes Desc: not available URL: From bsmith at mcs.anl.gov Sat Mar 4 19:25:43 2006 From: bsmith at mcs.anl.gov (Barry Smith) Date: Sat, 4 Mar 2006 19:25:43 -0600 (CST) Subject: Gradient at ghost cells only? In-Reply-To: <1141520976.440a3a507a944@serv-g1.ccom.uminho.pt> References: <1141489089.4409bdc1a2a8e@serv-g1.ccom.uminho.pt> <1141520976.440a3a507a944@serv-g1.ccom.uminho.pt> Message-ID: On Sun, 5 Mar 2006, billy at dem.uminho.pt wrote: > > Firstly, I would like to congratulate the PETSc team for such a great code! > > I send you an image of my case (all indices are global). Ghost cells are in > yellow and white cells are the interior cells. To calculate the gradient at a > cell, I use the gauss theorem so I need all neighbor cells for that. The > interior points are easy I can calculate them each time in each processor since > I have a ghost cell layer. My problem is the gradient in ghost cells because I > need the values at pink cells but they belong to another process. I guess I > could include these pink cells also as ghost cells and then I would have access > to their values. This is the way we handle things in PETSc-Fun3d; If you need to calculate new gradients each time then just use double wide ghost points for all your vectors. If you only need to calculate them less often you can create a seperate VecScatter to get the double-wide ghosts just when you need to. If the gradient is linear in the cell values you can compute "your part of it", store in a regular ghosted vector move to the other side and then add "its" part of the gradient. Tricker but avoids the two levels of communication. Barry > Or I could calculate the gradient and exchange it through > processes using VecCreateGhost(). > > For now I have the code working because I only use these cell-centered gradients > for non-orthogonal corrections. So, if the grid orthogonal this term is zero. > > > > > > > Quoting Barry Smith : > >> >> >> On Sat, 4 Mar 2006, billy at dem.uminho.pt wrote: >> >>> >>> Hi, >>> >>> I need the gradient of 5 scalars at ghost cells and I was thinking of >> creating >>> 5x3 vectors with VecCreateGhost(). Right now, I calculate the gradient >> during >>> each iteration and I don't store it's value. >>> I would like to calculate, store and exchange the gradient at the ghost >> cells >>> only, to minimize memory requirements. How is the best way to do that? >> ^^^^^^^ >> Do you not need the gradient values for the interior points? Or are you >> >> willing to recompute the gradients for the interior points? Why different? >> >> If the gradient is the same each time why not just calculate it the >> first >> time and store it for later? Don't make live complicated by using >> VecCreateGhost(), just compute them and store them in some array. >> >> Barry >> >> >>> >>> Billy. >>> >>> >> >> > > > From billy at dem.uminho.pt Sat Mar 11 21:47:44 2006 From: billy at dem.uminho.pt (billy at dem.uminho.pt) Date: Sun, 12 Mar 2006 03:47:44 +0000 Subject: Matrix convergence. In-Reply-To: References: <1141321382.44072ea6da75b@serv-g1.ccom.uminho.pt> <1141404107.440871cb0f016@serv-g1.ccom.uminho.pt> <1141409013.440884f603d32@serv-g1.ccom.uminho.pt> Message-ID: <1142135264.441399e06138c@serv-g1.ccom.uminho.pt> Hi, "-sub_pc_type" How do I set this option in the code? Billy. Quoting Barry Smith : > > You did not type it right -sub_pc_type lu not -pc_type lu > > > On Fri, 3 Mar 2006, billy at dem.uminho.pt wrote: > > > > > This is what I get: > > > > [0]PETSC ERROR: MatLUFactorSymbolic() line 2159 in > src/mat/interface/matrix.c > > [0]PETSC ERROR: No support for this operation for this object type! > > [0]PETSC ERROR: Matrix type mpiaij symbolic LU! > > [0]PETSC ERROR: PCSetUp_LU() line 252 in src/ksp/pc/impls/factor/lu/lu.c > > [0]PETSC ERROR: PCSetUp() line 798 in src/ksp/pc/interface/precon.c > > [0]PETSC ERROR: KSPSetUp() line 234 in src/ksp/ksp/interface/itfunc.c > > [0]PETSC ERROR: KSPSolve() line 334 in src/ksp/ksp/interface/itfunc.c > > > > > > Quoting Barry Smith : > > > >> > >> Run the parallel PETSc job with -ksp_type gmres -ksp_gmres_restart > 200 > >> -sub_pc_type lu > >> > >> > >> On Fri, 3 Mar 2006, billy at dem.uminho.pt wrote: > >> > >>> Hi, > >>> > >>> I tried to solve the 18x18 matrix with laspack and the results are the > >> following: > >>> > >>> Solver: GMRES, Preconditioning: NULL, Iterations: 500, Residual: > 6.16E-2 > >>> Solver: GMRES, Preconditioning: SSOR, Iterations: 500, Residual: > 6.57E-2 > >>> Solver: GMRES, Preconditioning: ILU, ERROR > >>> > >>> Solver: BiCGSTAB, Preconditioning: NULL, Iterations: 101, Residual: > >> 8.88E-7 > >>> Solver: BiCGSTAB, Preconditioning: SSOR, Iterations: 36, Residual: > >> 9.87E-7 > >>> Solver: BiCGSTAB, Preconditioning: ILU, ERROR > >>> > >>> > >>> Billy. > >>> > >>> > >>> Quoting Barry Smith : > >>> > >>>> > >>>> Billy, > >>>> > >>>> Most likely there is something wrong with the matrix being > >>>> generated. I would first look at the matrix entries and make > >>>> sure they make sense. Then I would solve the linear systems > >>>> with a direct solver -pc_type lu (on one processor and make > >>>> sure the solutions are reasonable and your simulation has > >>>> "correct" answers). > >>>> > >>>> It is possible the parallel matrix generation is wrong, > >>>> > >>>> Barry > >>>> > >>>> > >>>> On Thu, 2 Mar 2006, billy at dem.uminho.pt wrote: > >>>> > >>>>> > >>>>> Hi, > >>>>> > >>>>> > >>>>> I have been testing my parallel implementation with a 2D case. I have > >> used > >>>> the > >>>>> following grids with 2 and 4 processes: 4x4, 10x10, 16x16 and 18x18. > >>>>> > >>>>> It works for the first three (max. number of iterations to converge > >> aprox. > >>>> 70) > >>>>> but when I increase to 18x18 the matrix does not converge. I have > >> increased > >>>> the > >>>>> maximum number of iterations and I have used GMRES, BiCGSTAB with > >>>>> preconditioners ASM, JACOBI, etc. > >>>>> > >>>>> With KSPType = GMRES and PCType = ASM: > >>>>> Number of iterations: 500 Residual: +1.420471E-01 > >>>>> > >>>>> With KSPType = GMRES and PCType = JACOBI: > >>>>> Number of iterations: 500 Residual: +2.351882E-02 > >>>>> > >>>>> With KSPType = BCGS and PCType = ASM: > >>>>> Number of iterations: 136 Residual: +3.911446E+04 > >>>>> > >>>>> With KSPType = BCGS and PCType = NULL: > >>>>> Number of iterations: 157 Residual: +3.254728E+03 > >>>>> > >>>>> Is it normal that the convergence detiorates so much with such a > slight > >>>> increase > >>>>> in the dimension of the matrix? Is there any optimization parameter > that > >> I > >>>> may > >>>>> be missing? > >>>>> > >>>>> > >>>>> Billy. > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >>> > >> > >> > > > > > > > > From bsmith at mcs.anl.gov Sat Mar 11 21:50:53 2006 From: bsmith at mcs.anl.gov (Barry Smith) Date: Sat, 11 Mar 2006 21:50:53 -0600 (CST) Subject: Matrix convergence. In-Reply-To: <1142135264.441399e06138c@serv-g1.ccom.uminho.pt> References: <1141321382.44072ea6da75b@serv-g1.ccom.uminho.pt> <1141404107.440871cb0f016@serv-g1.ccom.uminho.pt> <1141409013.440884f603d32@serv-g1.ccom.uminho.pt> <1142135264.441399e06138c@serv-g1.ccom.uminho.pt> Message-ID: KSPGetPC(ksp,&pc); PCBJacobiGetSubKSP(pc,&subksp); or PCASMGetSubKSP(.. KPSGetPC(subksp,&subpc); PCSetType(subpc,PCLU); On Sun, 12 Mar 2006, billy at dem.uminho.pt wrote: > Hi, > > > "-sub_pc_type" > > How do I set this option in the code? > > Billy. > > Quoting Barry Smith : > >> >> You did not type it right -sub_pc_type lu not -pc_type lu >> >> >> On Fri, 3 Mar 2006, billy at dem.uminho.pt wrote: >> >>> >>> This is what I get: >>> >>> [0]PETSC ERROR: MatLUFactorSymbolic() line 2159 in >> src/mat/interface/matrix.c >>> [0]PETSC ERROR: No support for this operation for this object type! >>> [0]PETSC ERROR: Matrix type mpiaij symbolic LU! >>> [0]PETSC ERROR: PCSetUp_LU() line 252 in src/ksp/pc/impls/factor/lu/lu.c >>> [0]PETSC ERROR: PCSetUp() line 798 in src/ksp/pc/interface/precon.c >>> [0]PETSC ERROR: KSPSetUp() line 234 in src/ksp/ksp/interface/itfunc.c >>> [0]PETSC ERROR: KSPSolve() line 334 in src/ksp/ksp/interface/itfunc.c >>> >>> >>> Quoting Barry Smith : >>> >>>> >>>> Run the parallel PETSc job with -ksp_type gmres -ksp_gmres_restart >> 200 >>>> -sub_pc_type lu >>>> >>>> >>>> On Fri, 3 Mar 2006, billy at dem.uminho.pt wrote: >>>> >>>>> Hi, >>>>> >>>>> I tried to solve the 18x18 matrix with laspack and the results are the >>>> following: >>>>> >>>>> Solver: GMRES, Preconditioning: NULL, Iterations: 500, Residual: >> 6.16E-2 >>>>> Solver: GMRES, Preconditioning: SSOR, Iterations: 500, Residual: >> 6.57E-2 >>>>> Solver: GMRES, Preconditioning: ILU, ERROR >>>>> >>>>> Solver: BiCGSTAB, Preconditioning: NULL, Iterations: 101, Residual: >>>> 8.88E-7 >>>>> Solver: BiCGSTAB, Preconditioning: SSOR, Iterations: 36, Residual: >>>> 9.87E-7 >>>>> Solver: BiCGSTAB, Preconditioning: ILU, ERROR >>>>> >>>>> >>>>> Billy. >>>>> >>>>> >>>>> Quoting Barry Smith : >>>>> >>>>>> >>>>>> Billy, >>>>>> >>>>>> Most likely there is something wrong with the matrix being >>>>>> generated. I would first look at the matrix entries and make >>>>>> sure they make sense. Then I would solve the linear systems >>>>>> with a direct solver -pc_type lu (on one processor and make >>>>>> sure the solutions are reasonable and your simulation has >>>>>> "correct" answers). >>>>>> >>>>>> It is possible the parallel matrix generation is wrong, >>>>>> >>>>>> Barry >>>>>> >>>>>> >>>>>> On Thu, 2 Mar 2006, billy at dem.uminho.pt wrote: >>>>>> >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> >>>>>>> I have been testing my parallel implementation with a 2D case. I have >>>> used >>>>>> the >>>>>>> following grids with 2 and 4 processes: 4x4, 10x10, 16x16 and 18x18. >>>>>>> >>>>>>> It works for the first three (max. number of iterations to converge >>>> aprox. >>>>>> 70) >>>>>>> but when I increase to 18x18 the matrix does not converge. I have >>>> increased >>>>>> the >>>>>>> maximum number of iterations and I have used GMRES, BiCGSTAB with >>>>>>> preconditioners ASM, JACOBI, etc. >>>>>>> >>>>>>> With KSPType = GMRES and PCType = ASM: >>>>>>> Number of iterations: 500 Residual: +1.420471E-01 >>>>>>> >>>>>>> With KSPType = GMRES and PCType = JACOBI: >>>>>>> Number of iterations: 500 Residual: +2.351882E-02 >>>>>>> >>>>>>> With KSPType = BCGS and PCType = ASM: >>>>>>> Number of iterations: 136 Residual: +3.911446E+04 >>>>>>> >>>>>>> With KSPType = BCGS and PCType = NULL: >>>>>>> Number of iterations: 157 Residual: +3.254728E+03 >>>>>>> >>>>>>> Is it normal that the convergence detiorates so much with such a >> slight >>>>>> increase >>>>>>> in the dimension of the matrix? Is there any optimization parameter >> that >>>> I >>>>>> may >>>>>>> be missing? >>>>>>> >>>>>>> >>>>>>> Billy. >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >>> >> >> > > > From billy at dem.uminho.pt Sat Mar 11 22:42:50 2006 From: billy at dem.uminho.pt (billy at dem.uminho.pt) Date: Sun, 12 Mar 2006 04:42:50 +0000 Subject: reordering mesh/matrix Message-ID: <1142138570.4413a6ca486f6@serv-g1.ccom.uminho.pt> What is the best way to reorder an unstructured partitioned mesh for PETSc? I want to reduce the bandwidth of the mesh. I use reverse cuthill-mckee to reorder the mesh and then partition with metis. Then, I reorder again to PETSc style ordering. Billy. From bsmith at mcs.anl.gov Sun Mar 12 03:04:07 2006 From: bsmith at mcs.anl.gov (Barry Smith) Date: Sun, 12 Mar 2006 03:04:07 -0600 (CST) Subject: reordering mesh/matrix In-Reply-To: <1142138570.4413a6ca486f6@serv-g1.ccom.uminho.pt> References: <1142138570.4413a6ca486f6@serv-g1.ccom.uminho.pt> Message-ID: On Sun, 12 Mar 2006, billy at dem.uminho.pt wrote: > > What is the best way to reorder an unstructured partitioned mesh for PETSc? I > want to reduce the bandwidth of the mesh. > > I use reverse cuthill-mckee to reorder the mesh and then partition with metis. > Then, I reorder again to PETSc style ordering. Billy, To my knowledge this is the best thing to do. Use metis/parmetis to decide which elements/nodes belong to each process then get the data (geometry, connectivity, physical parameters etc) for each element/node to the process it belongs. Then RENUMBER the nodes so that the first process owns the first set of nodes etc. Note that this renumbering is JUST a relabeling of the "name" of each node, the decision of which nodes belong to which process is determined by metis/parmetis. If this is what you are doing then you are doing what I would do. Barry > > > Billy. > > From balay at mcs.anl.gov Mon Mar 13 11:02:27 2006 From: balay at mcs.anl.gov (Satish Balay) Date: Mon, 13 Mar 2006 11:02:27 -0600 (CST) Subject: Matrix convergence. In-Reply-To: References: <1141321382.44072ea6da75b@serv-g1.ccom.uminho.pt> <1141404107.440871cb0f016@serv-g1.ccom.uminho.pt> <1141409013.440884f603d32@serv-g1.ccom.uminho.pt> <1142135264.441399e06138c@serv-g1.ccom.uminho.pt> Message-ID: Actually there could be multiple blocks per proc in BJACOBI/ASM so the could would be something like: KSPGetPC(ksp,&pc); PCBJacobiGetSubKSP(pc,&nblocks,&subksp); for (i=0; i< nblocks; i++) { PC subpc; KPSGetPC(subksp[i],&subpc); PCSetType(subpc,PCLU); } Satish On Sat, 11 Mar 2006, Barry Smith wrote: > > KSPGetPC(ksp,&pc); > PCBJacobiGetSubKSP(pc,&subksp); or PCASMGetSubKSP(.. > KPSGetPC(subksp,&subpc); > PCSetType(subpc,PCLU); > > On Sun, 12 Mar 2006, billy at dem.uminho.pt wrote: > > > Hi, > > > > > > "-sub_pc_type" > > > > How do I set this option in the code? > > > > Billy. > > > > Quoting Barry Smith : > > > > > > > > You did not type it right -sub_pc_type lu not -pc_type lu > > > > > > > > > On Fri, 3 Mar 2006, billy at dem.uminho.pt wrote: > > > > > > > > > > > This is what I get: > > > > > > > > [0]PETSC ERROR: MatLUFactorSymbolic() line 2159 in > > > src/mat/interface/matrix.c > > > > [0]PETSC ERROR: No support for this operation for this object type! > > > > [0]PETSC ERROR: Matrix type mpiaij symbolic LU! > > > > [0]PETSC ERROR: PCSetUp_LU() line 252 in src/ksp/pc/impls/factor/lu/lu.c > > > > [0]PETSC ERROR: PCSetUp() line 798 in src/ksp/pc/interface/precon.c > > > > [0]PETSC ERROR: KSPSetUp() line 234 in src/ksp/ksp/interface/itfunc.c > > > > [0]PETSC ERROR: KSPSolve() line 334 in src/ksp/ksp/interface/itfunc.c > > > > > > > > > > > > Quoting Barry Smith : > > > > > > > > > > > > > > Run the parallel PETSc job with -ksp_type gmres -ksp_gmres_restart > > > 200 > > > > > -sub_pc_type lu > > > > > > > > > > > > > > > On Fri, 3 Mar 2006, billy at dem.uminho.pt wrote: > > > > > > > > > > > Hi, > > > > > > > > > > > > I tried to solve the 18x18 matrix with laspack and the results are > > > > > > the > > > > > following: > > > > > > > > > > > > Solver: GMRES, Preconditioning: NULL, Iterations: 500, Residual: > > > 6.16E-2 > > > > > > Solver: GMRES, Preconditioning: SSOR, Iterations: 500, Residual: > > > 6.57E-2 > > > > > > Solver: GMRES, Preconditioning: ILU, ERROR > > > > > > > > > > > > Solver: BiCGSTAB, Preconditioning: NULL, Iterations: 101, Residual: > > > > > 8.88E-7 > > > > > > Solver: BiCGSTAB, Preconditioning: SSOR, Iterations: 36, Residual: > > > > > 9.87E-7 > > > > > > Solver: BiCGSTAB, Preconditioning: ILU, ERROR > > > > > > > > > > > > > > > > > > Billy. > > > > > > > > > > > > > > > > > > Quoting Barry Smith : > > > > > > > > > > > > > > > > > > > > Billy, > > > > > > > > > > > > > > Most likely there is something wrong with the matrix being > > > > > > > generated. I would first look at the matrix entries and make > > > > > > > sure they make sense. Then I would solve the linear systems > > > > > > > with a direct solver -pc_type lu (on one processor and make > > > > > > > sure the solutions are reasonable and your simulation has > > > > > > > "correct" answers). > > > > > > > > > > > > > > It is possible the parallel matrix generation is wrong, > > > > > > > > > > > > > > Barry > > > > > > > > > > > > > > > > > > > > > On Thu, 2 Mar 2006, billy at dem.uminho.pt wrote: > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > > I have been testing my parallel implementation with a 2D case. I > > > > > > > > have > > > > > used > > > > > > > the > > > > > > > > following grids with 2 and 4 processes: 4x4, 10x10, 16x16 and > > > > > > > > 18x18. > > > > > > > > > > > > > > > > It works for the first three (max. number of iterations to > > > > > > > > converge > > > > > aprox. > > > > > > > 70) > > > > > > > > but when I increase to 18x18 the matrix does not converge. I > > > > > > > > have > > > > > increased > > > > > > > the > > > > > > > > maximum number of iterations and I have used GMRES, BiCGSTAB > > > > > > > > with > > > > > > > > preconditioners ASM, JACOBI, etc. > > > > > > > > > > > > > > > > With KSPType = GMRES and PCType = ASM: > > > > > > > > Number of iterations: 500 Residual: +1.420471E-01 > > > > > > > > > > > > > > > > With KSPType = GMRES and PCType = JACOBI: > > > > > > > > Number of iterations: 500 Residual: +2.351882E-02 > > > > > > > > > > > > > > > > With KSPType = BCGS and PCType = ASM: > > > > > > > > Number of iterations: 136 Residual: +3.911446E+04 > > > > > > > > > > > > > > > > With KSPType = BCGS and PCType = NULL: > > > > > > > > Number of iterations: 157 Residual: +3.254728E+03 > > > > > > > > > > > > > > > > Is it normal that the convergence detiorates so much with such a > > > slight > > > > > > > increase > > > > > > > > in the dimension of the matrix? Is there any optimization > > > > > > > > parameter > > > that > > > > > I > > > > > > > may > > > > > > > > be missing? > > > > > > > > > > > > > > > > > > > > > > > > Billy. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From balay at mcs.anl.gov Mon Mar 13 13:36:03 2006 From: balay at mcs.anl.gov (Satish Balay) Date: Mon, 13 Mar 2006 13:36:03 -0600 (CST) Subject: ***LOOPING MAIL*** PetscInitialize problem? In-Reply-To: <1142275120.4415bc30c005d@webmail.lncc.br> References: <1142275120.4415bc30c005d@webmail.lncc.br> Message-ID: According to the error message - the communicator is invalid. You might want to check that.. You should be able to call MPI_Comm_size() after PetscInitialize() Check src/sys/examples/tutorials/ex1.c for an example of this usage. BTW: Do PETSc examples run fine with your install? Satish On Mon, 13 Mar 2006, ziemer at lncc.br wrote: > Hello, > > I would be very glad if someone could give me some direction: > > After the MPI_Comm_size function is called, I got this error: > > aborting job: > Fatal error in MPI_Comm_size: Invalid communicator, error stack: > MPI_Comm_size(110): MPI_Comm_size(comm=0x1, size=0xbfffdf78) failed > MPI_Comm_size(69): Invalid communicator > > It seems that the MPI environment is not being correctly created by the function > PetscInitialize. > > > Does anyone have any idea? > > > Best Regards. > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > > From balay at mcs.anl.gov Mon Mar 13 14:38:00 2006 From: balay at mcs.anl.gov (Satish Balay) Date: Mon, 13 Mar 2006 14:38:00 -0600 (CST) Subject: ***LOOPING MAIL*** PetscInitialize problem? In-Reply-To: <1142279432.4415cd08d6d72@webmail.lncc.br> References: <1142275120.4415bc30c005d@webmail.lncc.br> <1142279432.4415cd08d6d72@webmail.lncc.br> Message-ID: You should be able to use either MPI_COMM_WORLD or PETSC_COMM_WORLD or any other communicator. There must be something else wrong in your code. Can't comment without looking at the code. Satish On Mon, 13 Mar 2006, ziemer at lncc.br wrote: > Hi, > > The Petsc installation examples run ok. > > The strange thing is if I change the parameter MPI_COMM_WORLD of the function > MPI_Comm_size() to PTESC_COMM_WORLD this function works, but at same time this > same strategy does not work with the MPI_Bcast() function. > > Thank you very much for your nice help. > > Paulo Ziemer. > > > Quoting Satish Balay : > > > According to the error message - the communicator is invalid. You > > might want to check that.. > > > > You should be able to call MPI_Comm_size() after PetscInitialize() > > Check src/sys/examples/tutorials/ex1.c for an example of this usage. > > > > BTW: Do PETSc examples run fine with your install? > > > > Satish > > > > > > On Mon, 13 Mar 2006, ziemer at lncc.br wrote: > > > > > Hello, > > > > > > I would be very glad if someone could give me some direction: > > > > > > After the MPI_Comm_size function is called, I got this error: > > > > > > aborting job: > > > Fatal error in MPI_Comm_size: Invalid communicator, error stack: > > > MPI_Comm_size(110): MPI_Comm_size(comm=0x1, size=0xbfffdf78) failed > > > MPI_Comm_size(69): Invalid communicator > > > > > > It seems that the MPI environment is not being correctly created by the > > function > > > PetscInitialize. > > > > > > > > > Does anyone have any idea? > > > > > > > > > Best Regards. > > > > > > ---------------------------------------------------------------- > > > This message was sent using IMP, the Internet Messaging Program. > > > > > > > > > > > > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > > -------------- next part -------------- /* Program usage: mpirun ex1 [-help] [all PETSc options] */ static char help[] = "Introductory example that illustrates printing.\n\n"; /*T Concepts: introduction to PETSc; Concepts: printing^in parallel Processors: n T*/ #include "petsc.h" int main(int argc,char **argv) { PetscErrorCode ierr; PetscMPIInt rank,size; /* Every PETSc routine should begin with the PetscInitialize() routine. argc, argv - These command line arguments are taken to extract the options supplied to PETSc and options supplied to MPI. help - When PETSc executable is invoked with the option -help, it prints the various options that can be applied at runtime. The user can use the "help" variable place additional help messages in this printout. */ ierr = PetscInitialize(&argc,&argv,(char *)0,help);CHKERRQ(ierr); /* The following MPI calls return the number of processes being used and the rank of this process in the group. */ ierr = MPI_Comm_size(PETSC_COMM_WORLD,&size);CHKERRQ(ierr); ierr = MPI_Comm_rank(PETSC_COMM_WORLD,&rank);CHKERRQ(ierr); /* Here we would like to print only one message that represents all the processes in the group. We use PetscPrintf() with the communicator PETSC_COMM_WORLD. Thus, only one message is printed representng PETSC_COMM_WORLD, i.e., all the processors. */ ierr = PetscPrintf(PETSC_COMM_WORLD,"Number of processors = %d, rank = %d\n",size,rank);CHKERRQ(ierr); /* Here a barrier is used to separate the two program states. */ ierr = MPI_Barrier(PETSC_COMM_WORLD);CHKERRQ(ierr); /* Here we simply use PetscPrintf() with the communicator PETSC_COMM_SELF, where each process is considered separately and prints independently to the screen. Thus, the output from different processes does not appear in any particular order. */ ierr = PetscPrintf(PETSC_COMM_SELF,"[%d] Jumbled Hello World\n",rank);CHKERRQ(ierr); /* Always call PetscFinalize() before exiting a program. This routine - finalizes the PETSc libraries as well as MPI - provides summary and diagnostic information if certain runtime options are chosen (e.g., -log_summary). See PetscFinalize() manpage for more information. */ ierr = PetscFinalize();CHKERRQ(ierr); return 0; } From ziemer at lncc.br Tue Mar 14 06:03:06 2006 From: ziemer at lncc.br (ziemer at lncc.br) Date: Tue, 14 Mar 2006 09:03:06 -0300 Subject: ***LOOPING MAIL*** PetscInitialize problem? In-Reply-To: References: <1142275120.4415bc30c005d@webmail.lncc.br> <1142279432.4415cd08d6d72@webmail.lncc.br> Message-ID: <1142337786.4416b0fabfdb5@webmail.lncc.br> This is part of the source code where the problem happens: Thank you for your patience. ***************************************************************** PROGRAM Premain C ------------------------------------------------------------------ ! Use ModuloLectura IMPLICIT REAL*8 (A-H,O-Z) ! ! Parallel begin ! petsc include files #include "include/finclude/petsc.h" ! Parallel end ! Logical Sym, NonLinearProblem,Iterative INTEGER ERR_ALLOC Parameter (Lch=16) Character Str*120 double precision noMPI_Wtime C ! INTERFACE ReadMat ! MODULE PROCEDURE ReadMat ! END INTERFACE ! INTERFACE ReadCoupling ! MODULE PROCEDURE ReadCoupling ! END INTERFACE ! INTERFACE Dimen ! MODULE PROCEDURE Dimen ! END INTERFACE C Allocatable X (:) Allocatable Ie__Param (:) Allocatable Ie_JParam (:) Allocatable Param (:) ! Parallel begin call PetscInitialize (PETSC_NULL_CHARACTER, iError) if (iError.ne.0) then Write (6,*) "Can't initialize PETSC" Stop End if ! Ask total number of proccesses ! ! PROBLEM BEGINS IN THE NEXT FUNCTION - MPI_COMM_WORLD IS NOT SET!! call MPI_Comm_size (MPI_COMM_WORLD, iSize, iError) ! ID of this proccess call MPI_Comm_rank (MPI_COMM_WORLD, iRank, iError) ! ********************************************************** Quoting Satish Balay : > > You should be able to use either MPI_COMM_WORLD or PETSC_COMM_WORLD or > any other communicator. There must be something else wrong in your > code. Can't comment without looking at the code. > > Satish > > On Mon, 13 Mar 2006, ziemer at lncc.br wrote: > > > Hi, > > > > The Petsc installation examples run ok. > > > > The strange thing is if I change the parameter MPI_COMM_WORLD of the > function > > MPI_Comm_size() to PTESC_COMM_WORLD this function works, but at same time > this > > same strategy does not work with the MPI_Bcast() function. > > > > Thank you very much for your nice help. > > > > Paulo Ziemer. > > > > > > Quoting Satish Balay : > > > > > According to the error message - the communicator is invalid. You > > > might want to check that.. > > > > > > You should be able to call MPI_Comm_size() after PetscInitialize() > > > Check src/sys/examples/tutorials/ex1.c for an example of this usage. > > > > > > BTW: Do PETSc examples run fine with your install? > > > > > > Satish > > > > > > > > > On Mon, 13 Mar 2006, ziemer at lncc.br wrote: > > > > > > > Hello, > > > > > > > > I would be very glad if someone could give me some direction: > > > > > > > > After the MPI_Comm_size function is called, I got this error: > > > > > > > > aborting job: > > > > Fatal error in MPI_Comm_size: Invalid communicator, error stack: > > > > MPI_Comm_size(110): MPI_Comm_size(comm=0x1, size=0xbfffdf78) failed > > > > MPI_Comm_size(69): Invalid communicator > > > > > > > > It seems that the MPI environment is not being correctly created by the > > > function > > > > PetscInitialize. > > > > > > > > > > > > Does anyone have any idea? > > > > > > > > > > > > Best Regards. > > > > > > > > ---------------------------------------------------------------- > > > > This message was sent using IMP, the Internet Messaging Program. > > > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------- > > This message was sent using IMP, the Internet Messaging Program. > > > > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From nilserik at gmail.com Tue Mar 14 09:27:51 2006 From: nilserik at gmail.com (=?ISO-8859-1?Q?Nils_Erik_Svang=E5rd?=) Date: Tue, 14 Mar 2006 16:27:51 +0100 Subject: SNES Problem In-Reply-To: References: <82f936c20602270607t775d7e03o6a37afa4c0b3d2a8@mail.gmail.com> <82f936c20603020529j6d4181c8pc75c980357df9aa3@mail.gmail.com> <82f936c20603030047m5f64406n1435ca60f306fa98@mail.gmail.com> <82f936c20603030158u33722ff0q3c50839df14841@mail.gmail.com> Message-ID: <82f936c20603140727k208100f8vcb8f5672f9e9284e@mail.gmail.com> Hi, Yes, there is a difference between the old 3-stage RK-solver and the SNESsolver using RK. In the old a timestep was calculatade for each cell based on a stability criteria and if chosen it could run in time-accurate mode eg. the timestep is the same for each cell, in SNES I use a timestep that is the same for all cells and changes only if it returns non-physical answers or the solution diverges. Another interesting observation is that when using back euler at the moment when it bugs out petsc has assigned neigboring cells pressure values that differs about 1 ATM, which is a very non physical value, but I have no clue as to why petsc want such a value in thesolution. /nisse On 3/3/06, Barry Smith wrote: > > There must be a difference between the two RKs. The initial > timestep it uses, or algorithm for changing time step or slight > difference in algorithms? > > Barry > > On Fri, 3 Mar 2006, Nils Erik Svang?rd wrote: > > > A interesting thing is when I change TS_BEULER to TS_RUNGE_KUTTA the > > solver exits fast due to the non physical values. My original solver > > is a 3-step Runge-Kutta which works flawlessly. > > > > The error when running RK: > > > > ./ImplicitG3D on a linux-gnu named sethnx004.vac.com by yy26539 Fri > > Mar 3 10:31:27 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] TS user right-hand-side function line 0 unknownunknown > > [0]PETSC ERROR: [0] TSComputeRHSFunction line 282 src/ts/interface/ts.c > > [0]PETSC ERROR: [0] TSRkqs line 256 src/ts/impls/explicit/rk/rk.c > > [0]PETSC ERROR: [0] TSStep_Rk line 322 src/ts/impls/explicit/rk/rk.c > > [0]PETSC ERROR: [0] TSStep line 1520 src/ts/interface/ts.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 > > > > On 3/3/06, Nils Erik Svang?rd wrote: > >> Hello again, > >> > >> > Is it just not compiling because PETSC_ERR_ARG_DOMAIN is not > >>> defined? Or does it still not work even when you have put the number in? > >>> What is the error? Or did you get it all working with SNES? > >>> > >> > >> > >> It is not compiling because PETSC_ERR_ARG_DOMAIN is not defined: > >> > >> error on line 585 of SNESG3D2.F: data type is undefined for variable > >> PETSC_ERR_ARG_DOMAIN > >> > >> I tried putting a number in, then it compiles but complains while > >> linking that the Push() and Pop() functions is not defined. I made a > >> workaround by adding a variable in a common block and setting it > >> before returning from a non physical value in the FormFunction. Now I > >> can compile and when there is a non-physical value it returns and > >> resumes with a smaller timestep. > >> SNES still give non physical values which are hard to add checks for > >> in the program (e.g sqrt(RO(L)-RO(L+1))). > >> > >> Did I understand correctly that SNES does a linesearch and probably > >> goes for a solution which isnt the one I looking for? Does SNES use > >> the linesearch algorithm when I use -snes_mf (which I use)? > >> > >>> It may work automatically with TS; you would just set TS with a > >>> smaller timestep and call TSSolve again? > >>> > >> > >> OK, I'll add a check and put TSSolve in a while loop. > >> > >> My SNESSolve loop looks like this right now: > >> call VecCreateSeq(PETSC_COMM_SELF,N,x,ierr) > >> call VecDuplicate(x,r,ierr) > >> call VecDuplicate(x,xb,ierr) > >> call SNESCreate(PETSC_COMM_SELF,snes,ierr) > >> call SNESSetFunction(snes,r,FormFunction,PETSC_NULL_OBJECT,ierr) > >> call SNESSetFromOptions(snes,ierr) > >> call FormInitialGuess(x,ierr) > >> call VecCopy(x,xb,ierr) > >> write(6,*)zero,dt,tmax,i1000 > >> step=0 > >> timestep=dt > >> bang=0 > >> C While loop > >> 10 if (step .le. 100) then > >> C call PetscExceptionPush(87,ierr) > >> C call PetscExceptionPush(PETSC_ERR_ARG_DOMAIN,ierr) > >> call SNESSolve(snes,PETSC_NULL_OBJECT,x,ierr) > >> ierr=bang > >> C call PetscExceptionPop(87,ierr2) > >> IF ( ierr .EQ. 87) THEN > >> timestep=timestep/2 > >> call VecCopy(xb,x,ierr) > >> write(6,*) "No physical solution, trying", > >> . " with smaller timestep: ",timestep > >> bang=0 > >> ELSE > >> call SNESGetConvergedReason(snes,reason,ierr) > >> IF ( reason .LT. 0 ) THEN > >> timestep=timestep/2 > >> call VecCopy(xb,x,ierr) > >> write(6,*)"Solution diverged, trying with", > >> . " smaller timestep: ",timestep > >> ELSE > >> timestep=dt > >> step=step+1 > >> call VecCopy(x,xb,ierr) > >> write(6,*) "Solve success, going for step: ",step > >> write(6,*) "Reason: ",reason," ierr: ",ierr > >> reason=0 > >> ierr=0 > >> ENDIF > >> ENDIF > >> goto 10 > >> endif > >> C End While loop > >> > >> And the check in the FormFunction: > >> > >> if (ET(L) .LT. 0) then > >> ierr = 87 > >> bang = 87 > >> C SETERRQ(87,"Non physical value!",ierr) > >> return > >> elseif ( RO(L) .LT. 0 ) then > >> ierr = 87 > >> bang = 87 > >> return > >> endif > >> > >> > >> /nisse > >> > >> > >> > >>> Barry > >>> > >>> I'm adding a petscerror.h for Fortran that includes these values > >>> Sorry I forgot we hadn't given them for Fortran. > >>> > >>> On Thu, 2 Mar 2006, Nils Erik Svang?rd wrote: > >>> > >>>> Hi again, > >>>> I realised that my implementation was a bit flawed so I have rewritten > >>>> it again, the push and pop() functions dont seem to work, and they are > >>>> keeping me from compiling the program, this is the main timestep loop: > >>>> > >>>> call VecCreateSeq(PETSC_COMM_SELF,N,x,ierr) > >>>> call VecDuplicate(x,r,ierr) > >>>> call VecDuplicate(x,xb,ierr) > >>>> call SNESCreate(PETSC_COMM_SELF,snes,ierr) > >>>> call SNESSetFunction(snes,r,FormFunction,PETSC_NULL_OBJECT,ierr) > >>>> call SNESSetFromOptions(snes,ierr) > >>>> call FormInitialGuess(x,ierr) > >>>> call VecCopy(x,xb,ierr) > >>>> write(6,*)zero,dt,tmax,i1000 > >>>> step=0 > >>>> timestep=dt > >>>> C While loop > >>>> 10 if (step .le. 100) then > >>>> call PetscExceptionPush(87,ierr) > >>>> call SNESSolve(snes,PETSC_NULL_OBJECT,x,ierr) > >>>> call PetscExceptionPop(87,ierr2) > >>>> > >>>> call SNESGetConvergedReason(snes,reason,ierr) > >>>> IF ( reason .LT. 0 ) THEN > >>>> timestep=timestep/2 > >>>> VecCopy(xb,x,ierr) > >>>> write(6,*)"Solution diverged, trying with", > >>>> . " smaller timestep: ",timestep > >>>> ELSE > >>>> IF ( ierr .EQ. 87) THEN > >>>> timestep=timestep/2 > >>>> VecCopy(xb,x,ierr) > >>>> write(6,*) "No physical solution, trying", > >>>> . " with smaller timestep: ",timestep > >>>> ELSE > >>>> timestep=dt > >>>> step=step+1 > >>>> VecCopy(x,xb,ierr) > >>>> write(6,*) "Solve success, going for step: ",step > >>>> ENDIF > >>>> ENDIF > >>>> goto 10 > >>>> endif > >>>> C End While loop > >>>> > >>>> And in my Formfunction I have added the following check: > >>>> if (ET(L) .LT. 0) then > >>>> ierr = 87 > >>>> return > >>>> endif > >>>> > >>>> PETSC_ERR_ARG_DOMAIN didnt work: error on line 6500 of SNESG3D2.F: > >>>> data type is undefined for variable PETSC_ERR_ARG_DOMAIN > >>>> Even thought I had petsc.h included. > >>>> > >>>> Can I do this check when I use TS also? I have the sameproblem with > >>>> the values being negative when using TS. > >>>> > >>>> > >>>> /nisse > >>>> > >>>> > >>>> On 2/27/06, Barry Smith wrote: > >>>>> > >>>>> SNES works by computing p = -approxinv(J)*F(uold) and > >>>>> then does a line search on unew = uold + lambda*p to get the > >>>>> new u. First it uses a test value of 1 for lambda so it > >>>>> tries to compute F(uold + p). It is possible that uold + p > >>>>> has some "non-physical" values in it. There are two ways > >>>>> you can try handling it: > >>>>> > >>>>> 1) Before doing the linesearch SNES calls a "precheck" function, > >>>>> that can change the step if it decides there is a problem > >>>>> with the step (like it is too long). You can provide your > >>>>> own precheck function with SNESLineSearchSetPreCheck() it could, > >>>>> for example, shrink the Newton direction to make it remain physical. > >>>>> > >>>>> or 2) when your form function detects an illegal value it calls > >>>>> SETERRQ(PETSC_ERR_ARG_DOMAIN,"Nonphysical function input"); Note: > >>>>> this is before it takes the square root of the negative number, > >>>>> so check the number and call the error before calling SETERRQ(). > >>>>> (If using Fortran then simply set ierr = PETSC_ERR_ARG_DOMAIN and > >>>>> then immediately return). Then replace your call to SNESSolve with > >>>>> ierr = PetscExceptionTry1(SNESSolve(snes,b,x),PETSC_ERR_ARG_DOMAIN); > >>>>> if (PetscExceptionCaught(ierr,PETSC_ERR_ARG_DOMAIN)) { > >>>>> /* this means your function found a non-physical value so > >>>>> cut your time-step and continue through the loop again. */ > >>>>> Put code to do this here. > >>>>> } > >>>>> If using fortran then do > >>>>> call PetscExceptionPush(PETSC_ERR_ARG_DOMAIN,ierr) > >>>>> call SNESSolve(snes,b,x,ierr) > >>>>> call PetscExceptionPop(PETSC_ERR_ARG_DOMAIN,anotherierr) > >>>>> if (ierr == PETSC_ERR_ARG_DOMAIN) then > >>>>> non-physical value so cut the time-step and try again > >>>>> else ! everything is normal so take the next time-step > >>>>> > >>>>> Barry > >>>>> > >>>>> The Fortran interface may be missing PetscExceptionPush() and Pop() > >>>>> if so let us know and we'll provide the patch. > >>>>> > >>>>> On Mon, 27 Feb 2006, Nils Erik Svang?rd wrote: > >>>>> > >>>>>> Hi all, > >>>>>> > >>>>>> I have problems solving some CFD problems using SNES and my custom > >>>>>> back-euler. I have 7 equations that I want to solve. > >>>>>> > >>>>>> First my FormFunction copies the values from the Vec that SNES uses to > >>>>>> the variables that my code use: > >>>>>> > >>>>>> RO(L)=xx(1,L) > >>>>>> RU(L)=xx(2,L) > >>>>>> RV(L)=xx(3,L) > >>>>>> RW(L)=xx(4,L) > >>>>>> ET(L)=xx(5,L) > >>>>>> RQ(L)= xx(6,L) > >>>>>> REPS(L)=xx(7,L) > >>>>>> > >>>>>> Here I also print the values of ET(2) for debugging: > >>>>>> > >>>>>> write(6,*)"ET(2) = xx(5,2) : ",ET(2)," = ",xx(5,2) > >>>>>> > >>>>>> Then I get the fluxes by calling custom functions > >>>>>> > >>>>>> call AUXVR > >>>>>> call VGRAD > >>>>>> call FLUX > >>>>>> call KESRC > >>>>>> > >>>>>> Then I perform back-euler save the new value to so that I can use it > >>>>>> in the next iterationi (TSF(L) is Time step function, which is set by > >>>>>> hand and is the same for all L): > >>>>>> > >>>>>> ff(1,L) = RO(L)-OLD(1,L)-TSF(L)*DRO(L) > >>>>>> ff(2,L) = RU(L)-OLD(2,L)-TSF(L)*DRU(L) > >>>>>> ff(3,L) = RV(L)-OLD(3,L)-TSF(L)*DRV(L) > >>>>>> ff(4,L) = RW(L)-OLD(4,L)-TSF(L)*DRW(L) > >>>>>> ff(5,L) = ET(L)-OLD(5,L)-TSF(L)*DET(L) > >>>>>> ff(6,L) = RQ(L)-OLD(6,L)-TSF(L)*DRQ(L) > >>>>>> ff(7,L) = REPS(L)-OLD(7,L)-TSF(L)*DREPS(L) > >>>>>> > >>>>>> And save the new value of RO-REPS to use in the next iteration of back-euler: > >>>>>> > >>>>>> OLD(1,L)=RO(L) > >>>>>> OLD(2,L)=RU(L) > >>>>>> OLD(3,L)=RV(L) > >>>>>> OLD(4,L)=RW(L) > >>>>>> OLD(5,L)=ET(L) > >>>>>> OLD(6,L)=RQ(L) > >>>>>> OLD(7,L)=REPS(L) > >>>>>> > >>>>>> Here I print the values of L=2 as above for debugging: > >>>>>> > >>>>>> write(6,*)ff(5,2)," = ",ET(2),"-",OLD(5,2),"-",TSF(2),"*",DET(2) > >>>>>> > >>>>>> > >>>>>> > >>>>>> The program exit abnormaly after 33 runs of the FormFunction. The > >>>>>> cause of this is that AUXVR tries to perform sqrt(ET(2)) when ET(2) is > >>>>>> negative, ET is the total energy and should never be negative. It > >>>>>> seems that all of a sudden the PETSc SNES solver decides to supply the > >>>>>> FormFunction with a negative ET value. I need help understanding why > >>>>>> and how to fix it (if it is fixable). > >>>>>> > >>>>>> Here is the output of: > >>>>>> write(6,*)"ET(2) = xx(5,2) : ",ET(2)," = ",xx(5,2) > >>>>>> Which is in the beginning of my FormFunction. > >>>>>> And: > >>>>>> write(6,*)ff(5,2)," = ",ET(2),"-",OLD(5,2),"-",TSF(2),"*",DET(2) > >>>>>> Which is in the end of my Formfunction. > >>>>>> > >>>>>> 1. ET(2) = xx(5,2) : 253250. = 253250.000000000 > >>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > >>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > >>>>>> 2. ET(2) = xx(5,2) : 253250. = 253250.000010259 > >>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > >>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > >>>>>> 3. ET(2) = xx(5,2) : 253250. = 253249.999999988 > >>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4132419437260 = > >>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941324E+08 > >>>>>> 4. ET(2) = xx(5,2) : 253250. = 253250.000048432 > >>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > >>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > >>>>>> 5. ET(2) = xx(5,2) : 253250. = 253249.999999872 > >>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4177283437784 = > >>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941773E+08 > >>>>>> 6. ET(2) = xx(5,2) : 253250. = 253250.000071113 > >>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > >>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > >>>>>> 7. ET(2) = xx(5,2) : 253250. = 253249.999980115 > >>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4453347441010 = > >>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.944533E+08 > >>>>>> 8. ET(2) = xx(5,2) : 253250. = 253250.000037298 > >>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4082723436679 = > >>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940827E+08 > >>>>>> 9. ET(2) = xx(5,2) : 253250. = 253249.999942706 > >>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4082723436679 = > >>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940827E+08 > >>>>>> 10. ET(2) = xx(5,2) : 253250. = 253249.999948703 > >>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > >>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > >>>>>> 11. ET(2) = xx(5,2) : 253250. = 253250.000007808 > >>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.7283811474088 = > >>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.972838E+08 > >>>>>> 12. ET(2) = xx(5,2) : 253250. = 253250.000018146 > >>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > >>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > >>>>>> 13. ET(2) = xx(5,2) : 253250. = 253250.000001865 > >>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 28.3742819315846 = > >>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.837428E+08 > >>>>>> 14. ET(2) = xx(5,2) : 253250. = 253249.999997296 > >>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > >>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > >>>>>> 15. ET(2) = xx(5,2) : 253250. = 253250.000000049 > >>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 30.6548963582361 = > >>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -3.065490E+08 > >>>>>> 16. ET(2) = xx(5,2) : 253250. = 253250.000022870 > >>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > >>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > >>>>>> 17. ET(2) = xx(5,2) : 253250. = 253249.999999716 > >>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.5326051451209 = > >>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.953260E+08 > >>>>>> 18. ET(2) = xx(5,2) : 253250. = 253250.000074328 > >>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4165187437643 = > >>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941652E+08 > >>>>>> 19. ET(2) = xx(5,2) : 253250. = 253250.000049809 > >>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4085059436707 = > >>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940851E+08 > >>>>>> 20. ET(2) = xx(5,2) : 253250. = 253250.000019253 > >>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > >>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > >>>>>> 21. ET(2) = xx(5,2) : 253250. = 253250.000000189 > >>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.8851075492403 = > >>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.988511E+08 > >>>>>> 22. ET(2) = xx(5,2) : 253250. = 253249.999997897 > >>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4085059436707 = > >>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940851E+08 > >>>>>> 23. ET(2) = xx(5,2) : 253250. = 253249.999975142 > >>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.3961539435263 = > >>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.939615E+08 > >>>>>> 24. ET(2) = xx(5,2) : 253250. = 253250.000018324 > >>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4085059436707 = > >>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940851E+08 > >>>>>> 25. ET(2) = xx(5,2) : 253250. = 253249.999987073 > >>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4165187437643 = > >>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941652E+08 > >>>>>> 26. ET(2) = xx(5,2) : 253250. = 253249.999980982 > >>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4165187437643 = > >>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941652E+08 > >>>>>> 27. ET(2) = xx(5,2) : 253250. = 253249.999994645 > >>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > >>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > >>>>>> 28. ET(2) = xx(5,2) : 253250. = 253249.999962364 > >>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4165187437643 = > >>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941652E+08 > >>>>>> 29. ET(2) = xx(5,2) : 253250. = 253249.999999921 > >>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > >>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > >>>>>> 30. ET(2) = xx(5,2) : 253250. = 253250.000000058 > >>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 28.4019971319085 = > >>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.840200E+08 > >>>>>> 31. ET(2) = xx(5,2) : 253250. = 253250.000040348 > >>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4085059436707 = > >>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940851E+08 > >>>>>> 32. ET(2) = xx(5,2) : 253250. = 253250.000005245 > >>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > >>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > >>>>>> 33. ET(2) = xx(5,2) : 253250. = 253250.000005245 > >>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > >>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > >>>>>> 34. ET(2) = xx(5,2) : -848141. = -848141.388090847 > >>>>>> -------------------------------------------------------------------------- > >>>>>> 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. > >>>>>> ----------------------------------------------------------------------- > >>>>>> ./SNESG3D2 on a linux-gnu named sethnx004.vac.com by yy26539 Mon Feb > >>>>>> 27 14:21:13 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] SNES user function line 0 unknownunknown > >>>>>> [0]PETSC ERROR: [0] SNESComputeFunction line 788 src/snes/interface/snes.c > >>>>>> [0]PETSC ERROR: [0] SNESLineSearchCubic line 514 src/snes/impls/ls/ls.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: ! > >>>>>> > >>>>>> > >>>>>> Suggestions and tips are very welcome! > >>>>>> /nisse > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> Nils-Erik Svang???rd > >>>>>> MSN: schweingaard at hotmail.com > >>>>>> Skype: schweingaard > >>>>>> > >>>>>> > >>>>> > >>>> > >>>> > >>>> -- > >>>> Nils-Erik Svang?rd > >>>> MSN: schweingaard at hotmail.com > >>>> Skype: schweingaard > >>>> > >>>> > >>> > >> > >> > >> -- > >> 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 From bsmith at mcs.anl.gov Tue Mar 14 13:20:17 2006 From: bsmith at mcs.anl.gov (Barry Smith) Date: Tue, 14 Mar 2006 13:20:17 -0600 (CST) Subject: SNES Problem In-Reply-To: <82f936c20603140727k208100f8vcb8f5672f9e9284e@mail.gmail.com> References: <82f936c20602270607t775d7e03o6a37afa4c0b3d2a8@mail.gmail.com> <82f936c20603020529j6d4181c8pc75c980357df9aa3@mail.gmail.com> <82f936c20603030047m5f64406n1435ca60f306fa98@mail.gmail.com> <82f936c20603030158u33722ff0q3c50839df14841@mail.gmail.com> <82f936c20603140727k208100f8vcb8f5672f9e9284e@mail.gmail.com> Message-ID: On Tue, 14 Mar 2006, Nils Erik Svang?rd wrote: > Hi, > Yes, there is a difference between the old 3-stage RK-solver and the > SNESsolver using RK. In the old a timestep was calculatade for each ^^^^^^^^^^^^^^^ Are you using PETSc's explicit RK? If so that does not use SNES. > cell based on a stability criteria and if chosen it could run in > time-accurate mode eg. the timestep is the same for each cell, in SNES ^^^^^^^^^ Do you mean for backward Euler for the explicit RK? Or both? > I use a timestep that is the same for all cells and > changes only if it returns non-physical answers or the solution diverges. I think you need to put the "proper" computation of the time-step based on the stability criteria that you have in the "old" code. Unfortunately this is currently hardwired in src/ts/impls/explicit/rk/rk.c (search for "Computing next stepsize"). I think you need to use the minimum of the timestep computed here and what is needed for the "stability criteria". > > Another interesting observation is that when using back euler at the > moment when it bugs out petsc has assigned neigboring cells pressure > values that differs about 1 ATM, which is a very non physical value, Likely some stability problem. Barry > but I have no clue as to why petsc want such a value in thesolution. > > /nisse > > On 3/3/06, Barry Smith wrote: >> >> There must be a difference between the two RKs. The initial >> timestep it uses, or algorithm for changing time step or slight >> difference in algorithms? >> >> Barry >> >> On Fri, 3 Mar 2006, Nils Erik Svang?rd wrote: >> >>> A interesting thing is when I change TS_BEULER to TS_RUNGE_KUTTA the >>> solver exits fast due to the non physical values. My original solver >>> is a 3-step Runge-Kutta which works flawlessly. >>> >>> The error when running RK: >>> >>> ./ImplicitG3D on a linux-gnu named sethnx004.vac.com by yy26539 Fri >>> Mar 3 10:31:27 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] TS user right-hand-side function line 0 unknownunknown >>> [0]PETSC ERROR: [0] TSComputeRHSFunction line 282 src/ts/interface/ts.c >>> [0]PETSC ERROR: [0] TSRkqs line 256 src/ts/impls/explicit/rk/rk.c >>> [0]PETSC ERROR: [0] TSStep_Rk line 322 src/ts/impls/explicit/rk/rk.c >>> [0]PETSC ERROR: [0] TSStep line 1520 src/ts/interface/ts.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 >>> >>> On 3/3/06, Nils Erik Svang?rd wrote: >>>> Hello again, >>>> >>>>> Is it just not compiling because PETSC_ERR_ARG_DOMAIN is not >>>>> defined? Or does it still not work even when you have put the number in? >>>>> What is the error? Or did you get it all working with SNES? >>>>> >>>> >>>> >>>> It is not compiling because PETSC_ERR_ARG_DOMAIN is not defined: >>>> >>>> error on line 585 of SNESG3D2.F: data type is undefined for variable >>>> PETSC_ERR_ARG_DOMAIN >>>> >>>> I tried putting a number in, then it compiles but complains while >>>> linking that the Push() and Pop() functions is not defined. I made a >>>> workaround by adding a variable in a common block and setting it >>>> before returning from a non physical value in the FormFunction. Now I >>>> can compile and when there is a non-physical value it returns and >>>> resumes with a smaller timestep. >>>> SNES still give non physical values which are hard to add checks for >>>> in the program (e.g sqrt(RO(L)-RO(L+1))). >>>> >>>> Did I understand correctly that SNES does a linesearch and probably >>>> goes for a solution which isnt the one I looking for? Does SNES use >>>> the linesearch algorithm when I use -snes_mf (which I use)? >>>> >>>>> It may work automatically with TS; you would just set TS with a >>>>> smaller timestep and call TSSolve again? >>>>> >>>> >>>> OK, I'll add a check and put TSSolve in a while loop. >>>> >>>> My SNESSolve loop looks like this right now: >>>> call VecCreateSeq(PETSC_COMM_SELF,N,x,ierr) >>>> call VecDuplicate(x,r,ierr) >>>> call VecDuplicate(x,xb,ierr) >>>> call SNESCreate(PETSC_COMM_SELF,snes,ierr) >>>> call SNESSetFunction(snes,r,FormFunction,PETSC_NULL_OBJECT,ierr) >>>> call SNESSetFromOptions(snes,ierr) >>>> call FormInitialGuess(x,ierr) >>>> call VecCopy(x,xb,ierr) >>>> write(6,*)zero,dt,tmax,i1000 >>>> step=0 >>>> timestep=dt >>>> bang=0 >>>> C While loop >>>> 10 if (step .le. 100) then >>>> C call PetscExceptionPush(87,ierr) >>>> C call PetscExceptionPush(PETSC_ERR_ARG_DOMAIN,ierr) >>>> call SNESSolve(snes,PETSC_NULL_OBJECT,x,ierr) >>>> ierr=bang >>>> C call PetscExceptionPop(87,ierr2) >>>> IF ( ierr .EQ. 87) THEN >>>> timestep=timestep/2 >>>> call VecCopy(xb,x,ierr) >>>> write(6,*) "No physical solution, trying", >>>> . " with smaller timestep: ",timestep >>>> bang=0 >>>> ELSE >>>> call SNESGetConvergedReason(snes,reason,ierr) >>>> IF ( reason .LT. 0 ) THEN >>>> timestep=timestep/2 >>>> call VecCopy(xb,x,ierr) >>>> write(6,*)"Solution diverged, trying with", >>>> . " smaller timestep: ",timestep >>>> ELSE >>>> timestep=dt >>>> step=step+1 >>>> call VecCopy(x,xb,ierr) >>>> write(6,*) "Solve success, going for step: ",step >>>> write(6,*) "Reason: ",reason," ierr: ",ierr >>>> reason=0 >>>> ierr=0 >>>> ENDIF >>>> ENDIF >>>> goto 10 >>>> endif >>>> C End While loop >>>> >>>> And the check in the FormFunction: >>>> >>>> if (ET(L) .LT. 0) then >>>> ierr = 87 >>>> bang = 87 >>>> C SETERRQ(87,"Non physical value!",ierr) >>>> return >>>> elseif ( RO(L) .LT. 0 ) then >>>> ierr = 87 >>>> bang = 87 >>>> return >>>> endif >>>> >>>> >>>> /nisse >>>> >>>> >>>> >>>>> Barry >>>>> >>>>> I'm adding a petscerror.h for Fortran that includes these values >>>>> Sorry I forgot we hadn't given them for Fortran. >>>>> >>>>> On Thu, 2 Mar 2006, Nils Erik Svang?rd wrote: >>>>> >>>>>> Hi again, >>>>>> I realised that my implementation was a bit flawed so I have rewritten >>>>>> it again, the push and pop() functions dont seem to work, and they are >>>>>> keeping me from compiling the program, this is the main timestep loop: >>>>>> >>>>>> call VecCreateSeq(PETSC_COMM_SELF,N,x,ierr) >>>>>> call VecDuplicate(x,r,ierr) >>>>>> call VecDuplicate(x,xb,ierr) >>>>>> call SNESCreate(PETSC_COMM_SELF,snes,ierr) >>>>>> call SNESSetFunction(snes,r,FormFunction,PETSC_NULL_OBJECT,ierr) >>>>>> call SNESSetFromOptions(snes,ierr) >>>>>> call FormInitialGuess(x,ierr) >>>>>> call VecCopy(x,xb,ierr) >>>>>> write(6,*)zero,dt,tmax,i1000 >>>>>> step=0 >>>>>> timestep=dt >>>>>> C While loop >>>>>> 10 if (step .le. 100) then >>>>>> call PetscExceptionPush(87,ierr) >>>>>> call SNESSolve(snes,PETSC_NULL_OBJECT,x,ierr) >>>>>> call PetscExceptionPop(87,ierr2) >>>>>> >>>>>> call SNESGetConvergedReason(snes,reason,ierr) >>>>>> IF ( reason .LT. 0 ) THEN >>>>>> timestep=timestep/2 >>>>>> VecCopy(xb,x,ierr) >>>>>> write(6,*)"Solution diverged, trying with", >>>>>> . " smaller timestep: ",timestep >>>>>> ELSE >>>>>> IF ( ierr .EQ. 87) THEN >>>>>> timestep=timestep/2 >>>>>> VecCopy(xb,x,ierr) >>>>>> write(6,*) "No physical solution, trying", >>>>>> . " with smaller timestep: ",timestep >>>>>> ELSE >>>>>> timestep=dt >>>>>> step=step+1 >>>>>> VecCopy(x,xb,ierr) >>>>>> write(6,*) "Solve success, going for step: ",step >>>>>> ENDIF >>>>>> ENDIF >>>>>> goto 10 >>>>>> endif >>>>>> C End While loop >>>>>> >>>>>> And in my Formfunction I have added the following check: >>>>>> if (ET(L) .LT. 0) then >>>>>> ierr = 87 >>>>>> return >>>>>> endif >>>>>> >>>>>> PETSC_ERR_ARG_DOMAIN didnt work: error on line 6500 of SNESG3D2.F: >>>>>> data type is undefined for variable PETSC_ERR_ARG_DOMAIN >>>>>> Even thought I had petsc.h included. >>>>>> >>>>>> Can I do this check when I use TS also? I have the sameproblem with >>>>>> the values being negative when using TS. >>>>>> >>>>>> >>>>>> /nisse >>>>>> >>>>>> >>>>>> On 2/27/06, Barry Smith wrote: >>>>>>> >>>>>>> SNES works by computing p = -approxinv(J)*F(uold) and >>>>>>> then does a line search on unew = uold + lambda*p to get the >>>>>>> new u. First it uses a test value of 1 for lambda so it >>>>>>> tries to compute F(uold + p). It is possible that uold + p >>>>>>> has some "non-physical" values in it. There are two ways >>>>>>> you can try handling it: >>>>>>> >>>>>>> 1) Before doing the linesearch SNES calls a "precheck" function, >>>>>>> that can change the step if it decides there is a problem >>>>>>> with the step (like it is too long). You can provide your >>>>>>> own precheck function with SNESLineSearchSetPreCheck() it could, >>>>>>> for example, shrink the Newton direction to make it remain physical. >>>>>>> >>>>>>> or 2) when your form function detects an illegal value it calls >>>>>>> SETERRQ(PETSC_ERR_ARG_DOMAIN,"Nonphysical function input"); Note: >>>>>>> this is before it takes the square root of the negative number, >>>>>>> so check the number and call the error before calling SETERRQ(). >>>>>>> (If using Fortran then simply set ierr = PETSC_ERR_ARG_DOMAIN and >>>>>>> then immediately return). Then replace your call to SNESSolve with >>>>>>> ierr = PetscExceptionTry1(SNESSolve(snes,b,x),PETSC_ERR_ARG_DOMAIN); >>>>>>> if (PetscExceptionCaught(ierr,PETSC_ERR_ARG_DOMAIN)) { >>>>>>> /* this means your function found a non-physical value so >>>>>>> cut your time-step and continue through the loop again. */ >>>>>>> Put code to do this here. >>>>>>> } >>>>>>> If using fortran then do >>>>>>> call PetscExceptionPush(PETSC_ERR_ARG_DOMAIN,ierr) >>>>>>> call SNESSolve(snes,b,x,ierr) >>>>>>> call PetscExceptionPop(PETSC_ERR_ARG_DOMAIN,anotherierr) >>>>>>> if (ierr == PETSC_ERR_ARG_DOMAIN) then >>>>>>> non-physical value so cut the time-step and try again >>>>>>> else ! everything is normal so take the next time-step >>>>>>> >>>>>>> Barry >>>>>>> >>>>>>> The Fortran interface may be missing PetscExceptionPush() and Pop() >>>>>>> if so let us know and we'll provide the patch. >>>>>>> >>>>>>> On Mon, 27 Feb 2006, Nils Erik Svang?rd wrote: >>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I have problems solving some CFD problems using SNES and my custom >>>>>>>> back-euler. I have 7 equations that I want to solve. >>>>>>>> >>>>>>>> First my FormFunction copies the values from the Vec that SNES uses to >>>>>>>> the variables that my code use: >>>>>>>> >>>>>>>> RO(L)=xx(1,L) >>>>>>>> RU(L)=xx(2,L) >>>>>>>> RV(L)=xx(3,L) >>>>>>>> RW(L)=xx(4,L) >>>>>>>> ET(L)=xx(5,L) >>>>>>>> RQ(L)= xx(6,L) >>>>>>>> REPS(L)=xx(7,L) >>>>>>>> >>>>>>>> Here I also print the values of ET(2) for debugging: >>>>>>>> >>>>>>>> write(6,*)"ET(2) = xx(5,2) : ",ET(2)," = ",xx(5,2) >>>>>>>> >>>>>>>> Then I get the fluxes by calling custom functions >>>>>>>> >>>>>>>> call AUXVR >>>>>>>> call VGRAD >>>>>>>> call FLUX >>>>>>>> call KESRC >>>>>>>> >>>>>>>> Then I perform back-euler save the new value to so that I can use it >>>>>>>> in the next iterationi (TSF(L) is Time step function, which is set by >>>>>>>> hand and is the same for all L): >>>>>>>> >>>>>>>> ff(1,L) = RO(L)-OLD(1,L)-TSF(L)*DRO(L) >>>>>>>> ff(2,L) = RU(L)-OLD(2,L)-TSF(L)*DRU(L) >>>>>>>> ff(3,L) = RV(L)-OLD(3,L)-TSF(L)*DRV(L) >>>>>>>> ff(4,L) = RW(L)-OLD(4,L)-TSF(L)*DRW(L) >>>>>>>> ff(5,L) = ET(L)-OLD(5,L)-TSF(L)*DET(L) >>>>>>>> ff(6,L) = RQ(L)-OLD(6,L)-TSF(L)*DRQ(L) >>>>>>>> ff(7,L) = REPS(L)-OLD(7,L)-TSF(L)*DREPS(L) >>>>>>>> >>>>>>>> And save the new value of RO-REPS to use in the next iteration of back-euler: >>>>>>>> >>>>>>>> OLD(1,L)=RO(L) >>>>>>>> OLD(2,L)=RU(L) >>>>>>>> OLD(3,L)=RV(L) >>>>>>>> OLD(4,L)=RW(L) >>>>>>>> OLD(5,L)=ET(L) >>>>>>>> OLD(6,L)=RQ(L) >>>>>>>> OLD(7,L)=REPS(L) >>>>>>>> >>>>>>>> Here I print the values of L=2 as above for debugging: >>>>>>>> >>>>>>>> write(6,*)ff(5,2)," = ",ET(2),"-",OLD(5,2),"-",TSF(2),"*",DET(2) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> The program exit abnormaly after 33 runs of the FormFunction. The >>>>>>>> cause of this is that AUXVR tries to perform sqrt(ET(2)) when ET(2) is >>>>>>>> negative, ET is the total energy and should never be negative. It >>>>>>>> seems that all of a sudden the PETSc SNES solver decides to supply the >>>>>>>> FormFunction with a negative ET value. I need help understanding why >>>>>>>> and how to fix it (if it is fixable). >>>>>>>> >>>>>>>> Here is the output of: >>>>>>>> write(6,*)"ET(2) = xx(5,2) : ",ET(2)," = ",xx(5,2) >>>>>>>> Which is in the beginning of my FormFunction. >>>>>>>> And: >>>>>>>> write(6,*)ff(5,2)," = ",ET(2),"-",OLD(5,2),"-",TSF(2),"*",DET(2) >>>>>>>> Which is in the end of my Formfunction. >>>>>>>> >>>>>>>> 1. ET(2) = xx(5,2) : 253250. = 253250.000000000 >>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>>>>>>> 2. ET(2) = xx(5,2) : 253250. = 253250.000010259 >>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>>>>>>> 3. ET(2) = xx(5,2) : 253250. = 253249.999999988 >>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4132419437260 = >>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941324E+08 >>>>>>>> 4. ET(2) = xx(5,2) : 253250. = 253250.000048432 >>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>>>>>>> 5. ET(2) = xx(5,2) : 253250. = 253249.999999872 >>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4177283437784 = >>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941773E+08 >>>>>>>> 6. ET(2) = xx(5,2) : 253250. = 253250.000071113 >>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>>>>>>> 7. ET(2) = xx(5,2) : 253250. = 253249.999980115 >>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4453347441010 = >>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.944533E+08 >>>>>>>> 8. ET(2) = xx(5,2) : 253250. = 253250.000037298 >>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4082723436679 = >>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940827E+08 >>>>>>>> 9. ET(2) = xx(5,2) : 253250. = 253249.999942706 >>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4082723436679 = >>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940827E+08 >>>>>>>> 10. ET(2) = xx(5,2) : 253250. = 253249.999948703 >>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>>>>>>> 11. ET(2) = xx(5,2) : 253250. = 253250.000007808 >>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.7283811474088 = >>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.972838E+08 >>>>>>>> 12. ET(2) = xx(5,2) : 253250. = 253250.000018146 >>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>>>>>>> 13. ET(2) = xx(5,2) : 253250. = 253250.000001865 >>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 28.3742819315846 = >>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.837428E+08 >>>>>>>> 14. ET(2) = xx(5,2) : 253250. = 253249.999997296 >>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>>>>>>> 15. ET(2) = xx(5,2) : 253250. = 253250.000000049 >>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 30.6548963582361 = >>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -3.065490E+08 >>>>>>>> 16. ET(2) = xx(5,2) : 253250. = 253250.000022870 >>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>>>>>>> 17. ET(2) = xx(5,2) : 253250. = 253249.999999716 >>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.5326051451209 = >>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.953260E+08 >>>>>>>> 18. ET(2) = xx(5,2) : 253250. = 253250.000074328 >>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4165187437643 = >>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941652E+08 >>>>>>>> 19. ET(2) = xx(5,2) : 253250. = 253250.000049809 >>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4085059436707 = >>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940851E+08 >>>>>>>> 20. ET(2) = xx(5,2) : 253250. = 253250.000019253 >>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>>>>>>> 21. ET(2) = xx(5,2) : 253250. = 253250.000000189 >>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.8851075492403 = >>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.988511E+08 >>>>>>>> 22. ET(2) = xx(5,2) : 253250. = 253249.999997897 >>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4085059436707 = >>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940851E+08 >>>>>>>> 23. ET(2) = xx(5,2) : 253250. = 253249.999975142 >>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.3961539435263 = >>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.939615E+08 >>>>>>>> 24. ET(2) = xx(5,2) : 253250. = 253250.000018324 >>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4085059436707 = >>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940851E+08 >>>>>>>> 25. ET(2) = xx(5,2) : 253250. = 253249.999987073 >>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4165187437643 = >>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941652E+08 >>>>>>>> 26. ET(2) = xx(5,2) : 253250. = 253249.999980982 >>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4165187437643 = >>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941652E+08 >>>>>>>> 27. ET(2) = xx(5,2) : 253250. = 253249.999994645 >>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>>>>>>> 28. ET(2) = xx(5,2) : 253250. = 253249.999962364 >>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4165187437643 = >>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941652E+08 >>>>>>>> 29. ET(2) = xx(5,2) : 253250. = 253249.999999921 >>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>>>>>>> 30. ET(2) = xx(5,2) : 253250. = 253250.000000058 >>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 28.4019971319085 = >>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.840200E+08 >>>>>>>> 31. ET(2) = xx(5,2) : 253250. = 253250.000040348 >>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4085059436707 = >>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940851E+08 >>>>>>>> 32. ET(2) = xx(5,2) : 253250. = 253250.000005245 >>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>>>>>>> 33. ET(2) = xx(5,2) : 253250. = 253250.000005245 >>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>>>>>>> 34. ET(2) = xx(5,2) : -848141. = -848141.388090847 >>>>>>>> -------------------------------------------------------------------------- >>>>>>>> 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. >>>>>>>> ----------------------------------------------------------------------- >>>>>>>> ./SNESG3D2 on a linux-gnu named sethnx004.vac.com by yy26539 Mon Feb >>>>>>>> 27 14:21:13 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] SNES user function line 0 unknownunknown >>>>>>>> [0]PETSC ERROR: [0] SNESComputeFunction line 788 src/snes/interface/snes.c >>>>>>>> [0]PETSC ERROR: [0] SNESLineSearchCubic line 514 src/snes/impls/ls/ls.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: ! >>>>>>>> >>>>>>>> >>>>>>>> Suggestions and tips are very welcome! >>>>>>>> /nisse >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Nils-Erik Svang???rd >>>>>>>> MSN: schweingaard at hotmail.com >>>>>>>> Skype: schweingaard >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Nils-Erik Svang?rd >>>>>> MSN: schweingaard at hotmail.com >>>>>> Skype: schweingaard >>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> 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 > > From nilserik at gmail.com Tue Mar 14 14:02:27 2006 From: nilserik at gmail.com (=?ISO-8859-1?Q?Nils_Erik_Svang=E5rd?=) Date: Tue, 14 Mar 2006 21:02:27 +0100 Subject: SNES Problem In-Reply-To: References: <82f936c20602270607t775d7e03o6a37afa4c0b3d2a8@mail.gmail.com> <82f936c20603020529j6d4181c8pc75c980357df9aa3@mail.gmail.com> <82f936c20603030047m5f64406n1435ca60f306fa98@mail.gmail.com> <82f936c20603030158u33722ff0q3c50839df14841@mail.gmail.com> <82f936c20603140727k208100f8vcb8f5672f9e9284e@mail.gmail.com> Message-ID: <82f936c20603141202p77439573hf249e43c53ae4d45@mail.gmail.com> > > Yes, there is a difference between the old 3-stage RK-solver and the > > SNESsolver using RK. In the old a timestep was calculatade for each > ^^^^^^^^^^^^^^^ > Are you using PETSc's explicit RK? If so that does not use SNES. > Sorry, I meant TS. > > cell based on a stability criteria and if chosen it could run in > > time-accurate mode eg. the timestep is the same for each cell, in SNES > ^^^^^^^^^ > Do you mean for backward Euler for the explicit RK? Or both? Sorry again, using TS I use the same size of the timestep on every cell (both when trying use back-euler and RK). In my old 3-stage RK I can use both variable timestep and time-accurate timestep. In my seperate back-euler implementation using SNES I use the same timestep on every cell. > > > I use a timestep that is the same for all cells and > > changes only if it returns non-physical answers or the solution diverges. > > I think you need to put the "proper" computation of the time-step > based on the stability criteria that you have in the "old" code. > Unfortunately this is currently hardwired in src/ts/impls/explicit/rk/rk.c > (search for "Computing next stepsize"). I think you need to use the minimum > of the timestep computed here and what is needed for the "stability criteria". > Hmm.. Ok so I could use my back-euler SNES implementation with my old timestep calculation function (using time-accurate timestep)? And it might work better. Thanks /nisse > > > > Another interesting observation is that when using back euler at the > > moment when it bugs out petsc has assigned neigboring cells pressure > > values that differs about 1 ATM, which is a very non physical value, > > Likely some stability problem. > > Barry > > > but I have no clue as to why petsc want such a value in thesolution. > > > > /nisse > > > > On 3/3/06, Barry Smith wrote: > >> > >> There must be a difference between the two RKs. The initial > >> timestep it uses, or algorithm for changing time step or slight > >> difference in algorithms? > >> > >> Barry > >> > >> On Fri, 3 Mar 2006, Nils Erik Svang?rd wrote: > >> > >>> A interesting thing is when I change TS_BEULER to TS_RUNGE_KUTTA the > >>> solver exits fast due to the non physical values. My original solver > >>> is a 3-step Runge-Kutta which works flawlessly. > >>> > >>> The error when running RK: > >>> > >>> ./ImplicitG3D on a linux-gnu named sethnx004.vac.com by yy26539 Fri > >>> Mar 3 10:31:27 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] TS user right-hand-side function line 0 unknownunknown > >>> [0]PETSC ERROR: [0] TSComputeRHSFunction line 282 src/ts/interface/ts.c > >>> [0]PETSC ERROR: [0] TSRkqs line 256 src/ts/impls/explicit/rk/rk.c > >>> [0]PETSC ERROR: [0] TSStep_Rk line 322 src/ts/impls/explicit/rk/rk.c > >>> [0]PETSC ERROR: [0] TSStep line 1520 src/ts/interface/ts.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 > >>> > >>> On 3/3/06, Nils Erik Svang?rd wrote: > >>>> Hello again, > >>>> > >>>>> Is it just not compiling because PETSC_ERR_ARG_DOMAIN is not > >>>>> defined? Or does it still not work even when you have put the number in? > >>>>> What is the error? Or did you get it all working with SNES? > >>>>> > >>>> > >>>> > >>>> It is not compiling because PETSC_ERR_ARG_DOMAIN is not defined: > >>>> > >>>> error on line 585 of SNESG3D2.F: data type is undefined for variable > >>>> PETSC_ERR_ARG_DOMAIN > >>>> > >>>> I tried putting a number in, then it compiles but complains while > >>>> linking that the Push() and Pop() functions is not defined. I made a > >>>> workaround by adding a variable in a common block and setting it > >>>> before returning from a non physical value in the FormFunction. Now I > >>>> can compile and when there is a non-physical value it returns and > >>>> resumes with a smaller timestep. > >>>> SNES still give non physical values which are hard to add checks for > >>>> in the program (e.g sqrt(RO(L)-RO(L+1))). > >>>> > >>>> Did I understand correctly that SNES does a linesearch and probably > >>>> goes for a solution which isnt the one I looking for? Does SNES use > >>>> the linesearch algorithm when I use -snes_mf (which I use)? > >>>> > >>>>> It may work automatically with TS; you would just set TS with a > >>>>> smaller timestep and call TSSolve again? > >>>>> > >>>> > >>>> OK, I'll add a check and put TSSolve in a while loop. > >>>> > >>>> My SNESSolve loop looks like this right now: > >>>> call VecCreateSeq(PETSC_COMM_SELF,N,x,ierr) > >>>> call VecDuplicate(x,r,ierr) > >>>> call VecDuplicate(x,xb,ierr) > >>>> call SNESCreate(PETSC_COMM_SELF,snes,ierr) > >>>> call SNESSetFunction(snes,r,FormFunction,PETSC_NULL_OBJECT,ierr) > >>>> call SNESSetFromOptions(snes,ierr) > >>>> call FormInitialGuess(x,ierr) > >>>> call VecCopy(x,xb,ierr) > >>>> write(6,*)zero,dt,tmax,i1000 > >>>> step=0 > >>>> timestep=dt > >>>> bang=0 > >>>> C While loop > >>>> 10 if (step .le. 100) then > >>>> C call PetscExceptionPush(87,ierr) > >>>> C call PetscExceptionPush(PETSC_ERR_ARG_DOMAIN,ierr) > >>>> call SNESSolve(snes,PETSC_NULL_OBJECT,x,ierr) > >>>> ierr=bang > >>>> C call PetscExceptionPop(87,ierr2) > >>>> IF ( ierr .EQ. 87) THEN > >>>> timestep=timestep/2 > >>>> call VecCopy(xb,x,ierr) > >>>> write(6,*) "No physical solution, trying", > >>>> . " with smaller timestep: ",timestep > >>>> bang=0 > >>>> ELSE > >>>> call SNESGetConvergedReason(snes,reason,ierr) > >>>> IF ( reason .LT. 0 ) THEN > >>>> timestep=timestep/2 > >>>> call VecCopy(xb,x,ierr) > >>>> write(6,*)"Solution diverged, trying with", > >>>> . " smaller timestep: ",timestep > >>>> ELSE > >>>> timestep=dt > >>>> step=step+1 > >>>> call VecCopy(x,xb,ierr) > >>>> write(6,*) "Solve success, going for step: ",step > >>>> write(6,*) "Reason: ",reason," ierr: ",ierr > >>>> reason=0 > >>>> ierr=0 > >>>> ENDIF > >>>> ENDIF > >>>> goto 10 > >>>> endif > >>>> C End While loop > >>>> > >>>> And the check in the FormFunction: > >>>> > >>>> if (ET(L) .LT. 0) then > >>>> ierr = 87 > >>>> bang = 87 > >>>> C SETERRQ(87,"Non physical value!",ierr) > >>>> return > >>>> elseif ( RO(L) .LT. 0 ) then > >>>> ierr = 87 > >>>> bang = 87 > >>>> return > >>>> endif > >>>> > >>>> > >>>> /nisse > >>>> > >>>> > >>>> > >>>>> Barry > >>>>> > >>>>> I'm adding a petscerror.h for Fortran that includes these values > >>>>> Sorry I forgot we hadn't given them for Fortran. > >>>>> > >>>>> On Thu, 2 Mar 2006, Nils Erik Svang?rd wrote: > >>>>> > >>>>>> Hi again, > >>>>>> I realised that my implementation was a bit flawed so I have rewritten > >>>>>> it again, the push and pop() functions dont seem to work, and they are > >>>>>> keeping me from compiling the program, this is the main timestep loop: > >>>>>> > >>>>>> call VecCreateSeq(PETSC_COMM_SELF,N,x,ierr) > >>>>>> call VecDuplicate(x,r,ierr) > >>>>>> call VecDuplicate(x,xb,ierr) > >>>>>> call SNESCreate(PETSC_COMM_SELF,snes,ierr) > >>>>>> call SNESSetFunction(snes,r,FormFunction,PETSC_NULL_OBJECT,ierr) > >>>>>> call SNESSetFromOptions(snes,ierr) > >>>>>> call FormInitialGuess(x,ierr) > >>>>>> call VecCopy(x,xb,ierr) > >>>>>> write(6,*)zero,dt,tmax,i1000 > >>>>>> step=0 > >>>>>> timestep=dt > >>>>>> C While loop > >>>>>> 10 if (step .le. 100) then > >>>>>> call PetscExceptionPush(87,ierr) > >>>>>> call SNESSolve(snes,PETSC_NULL_OBJECT,x,ierr) > >>>>>> call PetscExceptionPop(87,ierr2) > >>>>>> > >>>>>> call SNESGetConvergedReason(snes,reason,ierr) > >>>>>> IF ( reason .LT. 0 ) THEN > >>>>>> timestep=timestep/2 > >>>>>> VecCopy(xb,x,ierr) > >>>>>> write(6,*)"Solution diverged, trying with", > >>>>>> . " smaller timestep: ",timestep > >>>>>> ELSE > >>>>>> IF ( ierr .EQ. 87) THEN > >>>>>> timestep=timestep/2 > >>>>>> VecCopy(xb,x,ierr) > >>>>>> write(6,*) "No physical solution, trying", > >>>>>> . " with smaller timestep: ",timestep > >>>>>> ELSE > >>>>>> timestep=dt > >>>>>> step=step+1 > >>>>>> VecCopy(x,xb,ierr) > >>>>>> write(6,*) "Solve success, going for step: ",step > >>>>>> ENDIF > >>>>>> ENDIF > >>>>>> goto 10 > >>>>>> endif > >>>>>> C End While loop > >>>>>> > >>>>>> And in my Formfunction I have added the following check: > >>>>>> if (ET(L) .LT. 0) then > >>>>>> ierr = 87 > >>>>>> return > >>>>>> endif > >>>>>> > >>>>>> PETSC_ERR_ARG_DOMAIN didnt work: error on line 6500 of SNESG3D2.F: > >>>>>> data type is undefined for variable PETSC_ERR_ARG_DOMAIN > >>>>>> Even thought I had petsc.h included. > >>>>>> > >>>>>> Can I do this check when I use TS also? I have the sameproblem with > >>>>>> the values being negative when using TS. > >>>>>> > >>>>>> > >>>>>> /nisse > >>>>>> > >>>>>> > >>>>>> On 2/27/06, Barry Smith wrote: > >>>>>>> > >>>>>>> SNES works by computing p = -approxinv(J)*F(uold) and > >>>>>>> then does a line search on unew = uold + lambda*p to get the > >>>>>>> new u. First it uses a test value of 1 for lambda so it > >>>>>>> tries to compute F(uold + p). It is possible that uold + p > >>>>>>> has some "non-physical" values in it. There are two ways > >>>>>>> you can try handling it: > >>>>>>> > >>>>>>> 1) Before doing the linesearch SNES calls a "precheck" function, > >>>>>>> that can change the step if it decides there is a problem > >>>>>>> with the step (like it is too long). You can provide your > >>>>>>> own precheck function with SNESLineSearchSetPreCheck() it could, > >>>>>>> for example, shrink the Newton direction to make it remain physical. > >>>>>>> > >>>>>>> or 2) when your form function detects an illegal value it calls > >>>>>>> SETERRQ(PETSC_ERR_ARG_DOMAIN,"Nonphysical function input"); Note: > >>>>>>> this is before it takes the square root of the negative number, > >>>>>>> so check the number and call the error before calling SETERRQ(). > >>>>>>> (If using Fortran then simply set ierr = PETSC_ERR_ARG_DOMAIN and > >>>>>>> then immediately return). Then replace your call to SNESSolve with > >>>>>>> ierr = PetscExceptionTry1(SNESSolve(snes,b,x),PETSC_ERR_ARG_DOMAIN); > >>>>>>> if (PetscExceptionCaught(ierr,PETSC_ERR_ARG_DOMAIN)) { > >>>>>>> /* this means your function found a non-physical value so > >>>>>>> cut your time-step and continue through the loop again. */ > >>>>>>> Put code to do this here. > >>>>>>> } > >>>>>>> If using fortran then do > >>>>>>> call PetscExceptionPush(PETSC_ERR_ARG_DOMAIN,ierr) > >>>>>>> call SNESSolve(snes,b,x,ierr) > >>>>>>> call PetscExceptionPop(PETSC_ERR_ARG_DOMAIN,anotherierr) > >>>>>>> if (ierr == PETSC_ERR_ARG_DOMAIN) then > >>>>>>> non-physical value so cut the time-step and try again > >>>>>>> else ! everything is normal so take the next time-step > >>>>>>> > >>>>>>> Barry > >>>>>>> > >>>>>>> The Fortran interface may be missing PetscExceptionPush() and Pop() > >>>>>>> if so let us know and we'll provide the patch. > >>>>>>> > >>>>>>> On Mon, 27 Feb 2006, Nils Erik Svang?rd wrote: > >>>>>>> > >>>>>>>> Hi all, > >>>>>>>> > >>>>>>>> I have problems solving some CFD problems using SNES and my custom > >>>>>>>> back-euler. I have 7 equations that I want to solve. > >>>>>>>> > >>>>>>>> First my FormFunction copies the values from the Vec that SNES uses to > >>>>>>>> the variables that my code use: > >>>>>>>> > >>>>>>>> RO(L)=xx(1,L) > >>>>>>>> RU(L)=xx(2,L) > >>>>>>>> RV(L)=xx(3,L) > >>>>>>>> RW(L)=xx(4,L) > >>>>>>>> ET(L)=xx(5,L) > >>>>>>>> RQ(L)= xx(6,L) > >>>>>>>> REPS(L)=xx(7,L) > >>>>>>>> > >>>>>>>> Here I also print the values of ET(2) for debugging: > >>>>>>>> > >>>>>>>> write(6,*)"ET(2) = xx(5,2) : ",ET(2)," = ",xx(5,2) > >>>>>>>> > >>>>>>>> Then I get the fluxes by calling custom functions > >>>>>>>> > >>>>>>>> call AUXVR > >>>>>>>> call VGRAD > >>>>>>>> call FLUX > >>>>>>>> call KESRC > >>>>>>>> > >>>>>>>> Then I perform back-euler save the new value to so that I can use it > >>>>>>>> in the next iterationi (TSF(L) is Time step function, which is set by > >>>>>>>> hand and is the same for all L): > >>>>>>>> > >>>>>>>> ff(1,L) = RO(L)-OLD(1,L)-TSF(L)*DRO(L) > >>>>>>>> ff(2,L) = RU(L)-OLD(2,L)-TSF(L)*DRU(L) > >>>>>>>> ff(3,L) = RV(L)-OLD(3,L)-TSF(L)*DRV(L) > >>>>>>>> ff(4,L) = RW(L)-OLD(4,L)-TSF(L)*DRW(L) > >>>>>>>> ff(5,L) = ET(L)-OLD(5,L)-TSF(L)*DET(L) > >>>>>>>> ff(6,L) = RQ(L)-OLD(6,L)-TSF(L)*DRQ(L) > >>>>>>>> ff(7,L) = REPS(L)-OLD(7,L)-TSF(L)*DREPS(L) > >>>>>>>> > >>>>>>>> And save the new value of RO-REPS to use in the next iteration of back-euler: > >>>>>>>> > >>>>>>>> OLD(1,L)=RO(L) > >>>>>>>> OLD(2,L)=RU(L) > >>>>>>>> OLD(3,L)=RV(L) > >>>>>>>> OLD(4,L)=RW(L) > >>>>>>>> OLD(5,L)=ET(L) > >>>>>>>> OLD(6,L)=RQ(L) > >>>>>>>> OLD(7,L)=REPS(L) > >>>>>>>> > >>>>>>>> Here I print the values of L=2 as above for debugging: > >>>>>>>> > >>>>>>>> write(6,*)ff(5,2)," = ",ET(2),"-",OLD(5,2),"-",TSF(2),"*",DET(2) > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> The program exit abnormaly after 33 runs of the FormFunction. The > >>>>>>>> cause of this is that AUXVR tries to perform sqrt(ET(2)) when ET(2) is > >>>>>>>> negative, ET is the total energy and should never be negative. It > >>>>>>>> seems that all of a sudden the PETSc SNES solver decides to supply the > >>>>>>>> FormFunction with a negative ET value. I need help understanding why > >>>>>>>> and how to fix it (if it is fixable). > >>>>>>>> > >>>>>>>> Here is the output of: > >>>>>>>> write(6,*)"ET(2) = xx(5,2) : ",ET(2)," = ",xx(5,2) > >>>>>>>> Which is in the beginning of my FormFunction. > >>>>>>>> And: > >>>>>>>> write(6,*)ff(5,2)," = ",ET(2),"-",OLD(5,2),"-",TSF(2),"*",DET(2) > >>>>>>>> Which is in the end of my Formfunction. > >>>>>>>> > >>>>>>>> 1. ET(2) = xx(5,2) : 253250. = 253250.000000000 > >>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > >>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > >>>>>>>> 2. ET(2) = xx(5,2) : 253250. = 253250.000010259 > >>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > >>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > >>>>>>>> 3. ET(2) = xx(5,2) : 253250. = 253249.999999988 > >>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4132419437260 = > >>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941324E+08 > >>>>>>>> 4. ET(2) = xx(5,2) : 253250. = 253250.000048432 > >>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > >>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > >>>>>>>> 5. ET(2) = xx(5,2) : 253250. = 253249.999999872 > >>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4177283437784 = > >>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941773E+08 > >>>>>>>> 6. ET(2) = xx(5,2) : 253250. = 253250.000071113 > >>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > >>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > >>>>>>>> 7. ET(2) = xx(5,2) : 253250. = 253249.999980115 > >>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4453347441010 = > >>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.944533E+08 > >>>>>>>> 8. ET(2) = xx(5,2) : 253250. = 253250.000037298 > >>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4082723436679 = > >>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940827E+08 > >>>>>>>> 9. ET(2) = xx(5,2) : 253250. = 253249.999942706 > >>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4082723436679 = > >>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940827E+08 > >>>>>>>> 10. ET(2) = xx(5,2) : 253250. = 253249.999948703 > >>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > >>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > >>>>>>>> 11. ET(2) = xx(5,2) : 253250. = 253250.000007808 > >>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.7283811474088 = > >>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.972838E+08 > >>>>>>>> 12. ET(2) = xx(5,2) : 253250. = 253250.000018146 > >>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > >>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > >>>>>>>> 13. ET(2) = xx(5,2) : 253250. = 253250.000001865 > >>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 28.3742819315846 = > >>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.837428E+08 > >>>>>>>> 14. ET(2) = xx(5,2) : 253250. = 253249.999997296 > >>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > >>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > >>>>>>>> 15. ET(2) = xx(5,2) : 253250. = 253250.000000049 > >>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 30.6548963582361 = > >>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -3.065490E+08 > >>>>>>>> 16. ET(2) = xx(5,2) : 253250. = 253250.000022870 > >>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > >>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > >>>>>>>> 17. ET(2) = xx(5,2) : 253250. = 253249.999999716 > >>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.5326051451209 = > >>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.953260E+08 > >>>>>>>> 18. ET(2) = xx(5,2) : 253250. = 253250.000074328 > >>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4165187437643 = > >>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941652E+08 > >>>>>>>> 19. ET(2) = xx(5,2) : 253250. = 253250.000049809 > >>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4085059436707 = > >>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940851E+08 > >>>>>>>> 20. ET(2) = xx(5,2) : 253250. = 253250.000019253 > >>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > >>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > >>>>>>>> 21. ET(2) = xx(5,2) : 253250. = 253250.000000189 > >>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.8851075492403 = > >>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.988511E+08 > >>>>>>>> 22. ET(2) = xx(5,2) : 253250. = 253249.999997897 > >>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4085059436707 = > >>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940851E+08 > >>>>>>>> 23. ET(2) = xx(5,2) : 253250. = 253249.999975142 > >>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.3961539435263 = > >>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.939615E+08 > >>>>>>>> 24. ET(2) = xx(5,2) : 253250. = 253250.000018324 > >>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4085059436707 = > >>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940851E+08 > >>>>>>>> 25. ET(2) = xx(5,2) : 253250. = 253249.999987073 > >>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4165187437643 = > >>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941652E+08 > >>>>>>>> 26. ET(2) = xx(5,2) : 253250. = 253249.999980982 > >>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4165187437643 = > >>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941652E+08 > >>>>>>>> 27. ET(2) = xx(5,2) : 253250. = 253249.999994645 > >>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > >>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > >>>>>>>> 28. ET(2) = xx(5,2) : 253250. = 253249.999962364 > >>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4165187437643 = > >>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941652E+08 > >>>>>>>> 29. ET(2) = xx(5,2) : 253250. = 253249.999999921 > >>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > >>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > >>>>>>>> 30. ET(2) = xx(5,2) : 253250. = 253250.000000058 > >>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 28.4019971319085 = > >>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.840200E+08 > >>>>>>>> 31. ET(2) = xx(5,2) : 253250. = 253250.000040348 > >>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4085059436707 = > >>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940851E+08 > >>>>>>>> 32. ET(2) = xx(5,2) : 253250. = 253250.000005245 > >>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > >>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > >>>>>>>> 33. ET(2) = xx(5,2) : 253250. = 253250.000005245 > >>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > >>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > >>>>>>>> 34. ET(2) = xx(5,2) : -848141. = -848141.388090847 > >>>>>>>> -------------------------------------------------------------------------- > >>>>>>>> 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. > >>>>>>>> ----------------------------------------------------------------------- > >>>>>>>> ./SNESG3D2 on a linux-gnu named sethnx004.vac.com by yy26539 Mon Feb > >>>>>>>> 27 14:21:13 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] SNES user function line 0 unknownunknown > >>>>>>>> [0]PETSC ERROR: [0] SNESComputeFunction line 788 src/snes/interface/snes.c > >>>>>>>> [0]PETSC ERROR: [0] SNESLineSearchCubic line 514 src/snes/impls/ls/ls.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: ! > >>>>>>>> > >>>>>>>> > >>>>>>>> Suggestions and tips are very welcome! > >>>>>>>> /nisse > >>>>>>>> > >>>>>>>> > >>>>>>>> -- > >>>>>>>> Nils-Erik Svang???rd > >>>>>>>> MSN: schweingaard at hotmail.com > >>>>>>>> Skype: schweingaard > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> Nils-Erik Svang?rd > >>>>>> MSN: schweingaard at hotmail.com > >>>>>> Skype: schweingaard > >>>>>> > >>>>>> > >>>>> > >>>> > >>>> > >>>> -- > >>>> 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 From bsmith at mcs.anl.gov Tue Mar 14 14:11:13 2006 From: bsmith at mcs.anl.gov (Barry Smith) Date: Tue, 14 Mar 2006 14:11:13 -0600 (CST) Subject: SNES Problem In-Reply-To: <82f936c20603141202p77439573hf249e43c53ae4d45@mail.gmail.com> References: <82f936c20602270607t775d7e03o6a37afa4c0b3d2a8@mail.gmail.com> <82f936c20603020529j6d4181c8pc75c980357df9aa3@mail.gmail.com> <82f936c20603030047m5f64406n1435ca60f306fa98@mail.gmail.com> <82f936c20603030158u33722ff0q3c50839df14841@mail.gmail.com> <82f936c20603140727k208100f8vcb8f5672f9e9284e@mail.gmail.com> <82f936c20603141202p77439573hf249e43c53ae4d45@mail.gmail.com> Message-ID: > Hmm.. Ok so I could use my back-euler SNES implementation with my old > timestep calculation function (using time-accurate timestep)? And it > might work better. Nisse, First I'd like to see the PETSc rk code behaving pretty much the same as your RK (then move onto the implicit code). Do I understand that the PETSc rk code goes "non-physical" while your RK does not? If so, I was suggesting putting in YOUR timestep control into the PETSc rk (I listed the file below). Once the PETSc rk behaves like your rk we can move onto the implicit code. Reason: I want to confirm that the basic "translation" to PETSc is working, before dealing with the implicitness (which introduces its own difficulties). Barry On Tue, 14 Mar 2006, Nils Erik Svang?rd wrote: >>> Yes, there is a difference between the old 3-stage RK-solver and the >>> SNESsolver using RK. In the old a timestep was calculatade for each >> ^^^^^^^^^^^^^^^ >> Are you using PETSc's explicit RK? If so that does not use SNES. >> > > Sorry, I meant TS. > >>> cell based on a stability criteria and if chosen it could run in >>> time-accurate mode eg. the timestep is the same for each cell, in SNES >> ^^^^^^^^^ >> Do you mean for backward Euler for the explicit RK? Or both? > > Sorry again, using TS I use the same size of the timestep on every > cell (both when trying use back-euler and RK). > In my old 3-stage RK I can use both variable timestep and > time-accurate timestep. > In my seperate back-euler implementation using SNES I use the same > timestep on every cell. > >> >>> I use a timestep that is the same for all cells and >>> changes only if it returns non-physical answers or the solution diverges. >> >> I think you need to put the "proper" computation of the time-step >> based on the stability criteria that you have in the "old" code. >> Unfortunately this is currently hardwired in src/ts/impls/explicit/rk/rk.c >> (search for "Computing next stepsize"). I think you need to use the minimum >> of the timestep computed here and what is needed for the "stability criteria". >> > Hmm.. Ok so I could use my back-euler SNES implementation with my old > timestep calculation function (using time-accurate timestep)? And it > might work better. > > > Thanks > /nisse > >>> >>> Another interesting observation is that when using back euler at the >>> moment when it bugs out petsc has assigned neigboring cells pressure >>> values that differs about 1 ATM, which is a very non physical value, >> >> Likely some stability problem. >> >> Barry >> >>> but I have no clue as to why petsc want such a value in thesolution. >>> >>> /nisse >>> >>> On 3/3/06, Barry Smith wrote: >>>> >>>> There must be a difference between the two RKs. The initial >>>> timestep it uses, or algorithm for changing time step or slight >>>> difference in algorithms? >>>> >>>> Barry >>>> >>>> On Fri, 3 Mar 2006, Nils Erik Svang?rd wrote: >>>> >>>>> A interesting thing is when I change TS_BEULER to TS_RUNGE_KUTTA the >>>>> solver exits fast due to the non physical values. My original solver >>>>> is a 3-step Runge-Kutta which works flawlessly. >>>>> >>>>> The error when running RK: >>>>> >>>>> ./ImplicitG3D on a linux-gnu named sethnx004.vac.com by yy26539 Fri >>>>> Mar 3 10:31:27 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] TS user right-hand-side function line 0 unknownunknown >>>>> [0]PETSC ERROR: [0] TSComputeRHSFunction line 282 src/ts/interface/ts.c >>>>> [0]PETSC ERROR: [0] TSRkqs line 256 src/ts/impls/explicit/rk/rk.c >>>>> [0]PETSC ERROR: [0] TSStep_Rk line 322 src/ts/impls/explicit/rk/rk.c >>>>> [0]PETSC ERROR: [0] TSStep line 1520 src/ts/interface/ts.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 >>>>> >>>>> On 3/3/06, Nils Erik Svang?rd wrote: >>>>>> Hello again, >>>>>> >>>>>>> Is it just not compiling because PETSC_ERR_ARG_DOMAIN is not >>>>>>> defined? Or does it still not work even when you have put the number in? >>>>>>> What is the error? Or did you get it all working with SNES? >>>>>>> >>>>>> >>>>>> >>>>>> It is not compiling because PETSC_ERR_ARG_DOMAIN is not defined: >>>>>> >>>>>> error on line 585 of SNESG3D2.F: data type is undefined for variable >>>>>> PETSC_ERR_ARG_DOMAIN >>>>>> >>>>>> I tried putting a number in, then it compiles but complains while >>>>>> linking that the Push() and Pop() functions is not defined. I made a >>>>>> workaround by adding a variable in a common block and setting it >>>>>> before returning from a non physical value in the FormFunction. Now I >>>>>> can compile and when there is a non-physical value it returns and >>>>>> resumes with a smaller timestep. >>>>>> SNES still give non physical values which are hard to add checks for >>>>>> in the program (e.g sqrt(RO(L)-RO(L+1))). >>>>>> >>>>>> Did I understand correctly that SNES does a linesearch and probably >>>>>> goes for a solution which isnt the one I looking for? Does SNES use >>>>>> the linesearch algorithm when I use -snes_mf (which I use)? >>>>>> >>>>>>> It may work automatically with TS; you would just set TS with a >>>>>>> smaller timestep and call TSSolve again? >>>>>>> >>>>>> >>>>>> OK, I'll add a check and put TSSolve in a while loop. >>>>>> >>>>>> My SNESSolve loop looks like this right now: >>>>>> call VecCreateSeq(PETSC_COMM_SELF,N,x,ierr) >>>>>> call VecDuplicate(x,r,ierr) >>>>>> call VecDuplicate(x,xb,ierr) >>>>>> call SNESCreate(PETSC_COMM_SELF,snes,ierr) >>>>>> call SNESSetFunction(snes,r,FormFunction,PETSC_NULL_OBJECT,ierr) >>>>>> call SNESSetFromOptions(snes,ierr) >>>>>> call FormInitialGuess(x,ierr) >>>>>> call VecCopy(x,xb,ierr) >>>>>> write(6,*)zero,dt,tmax,i1000 >>>>>> step=0 >>>>>> timestep=dt >>>>>> bang=0 >>>>>> C While loop >>>>>> 10 if (step .le. 100) then >>>>>> C call PetscExceptionPush(87,ierr) >>>>>> C call PetscExceptionPush(PETSC_ERR_ARG_DOMAIN,ierr) >>>>>> call SNESSolve(snes,PETSC_NULL_OBJECT,x,ierr) >>>>>> ierr=bang >>>>>> C call PetscExceptionPop(87,ierr2) >>>>>> IF ( ierr .EQ. 87) THEN >>>>>> timestep=timestep/2 >>>>>> call VecCopy(xb,x,ierr) >>>>>> write(6,*) "No physical solution, trying", >>>>>> . " with smaller timestep: ",timestep >>>>>> bang=0 >>>>>> ELSE >>>>>> call SNESGetConvergedReason(snes,reason,ierr) >>>>>> IF ( reason .LT. 0 ) THEN >>>>>> timestep=timestep/2 >>>>>> call VecCopy(xb,x,ierr) >>>>>> write(6,*)"Solution diverged, trying with", >>>>>> . " smaller timestep: ",timestep >>>>>> ELSE >>>>>> timestep=dt >>>>>> step=step+1 >>>>>> call VecCopy(x,xb,ierr) >>>>>> write(6,*) "Solve success, going for step: ",step >>>>>> write(6,*) "Reason: ",reason," ierr: ",ierr >>>>>> reason=0 >>>>>> ierr=0 >>>>>> ENDIF >>>>>> ENDIF >>>>>> goto 10 >>>>>> endif >>>>>> C End While loop >>>>>> >>>>>> And the check in the FormFunction: >>>>>> >>>>>> if (ET(L) .LT. 0) then >>>>>> ierr = 87 >>>>>> bang = 87 >>>>>> C SETERRQ(87,"Non physical value!",ierr) >>>>>> return >>>>>> elseif ( RO(L) .LT. 0 ) then >>>>>> ierr = 87 >>>>>> bang = 87 >>>>>> return >>>>>> endif >>>>>> >>>>>> >>>>>> /nisse >>>>>> >>>>>> >>>>>> >>>>>>> Barry >>>>>>> >>>>>>> I'm adding a petscerror.h for Fortran that includes these values >>>>>>> Sorry I forgot we hadn't given them for Fortran. >>>>>>> >>>>>>> On Thu, 2 Mar 2006, Nils Erik Svang?rd wrote: >>>>>>> >>>>>>>> Hi again, >>>>>>>> I realised that my implementation was a bit flawed so I have rewritten >>>>>>>> it again, the push and pop() functions dont seem to work, and they are >>>>>>>> keeping me from compiling the program, this is the main timestep loop: >>>>>>>> >>>>>>>> call VecCreateSeq(PETSC_COMM_SELF,N,x,ierr) >>>>>>>> call VecDuplicate(x,r,ierr) >>>>>>>> call VecDuplicate(x,xb,ierr) >>>>>>>> call SNESCreate(PETSC_COMM_SELF,snes,ierr) >>>>>>>> call SNESSetFunction(snes,r,FormFunction,PETSC_NULL_OBJECT,ierr) >>>>>>>> call SNESSetFromOptions(snes,ierr) >>>>>>>> call FormInitialGuess(x,ierr) >>>>>>>> call VecCopy(x,xb,ierr) >>>>>>>> write(6,*)zero,dt,tmax,i1000 >>>>>>>> step=0 >>>>>>>> timestep=dt >>>>>>>> C While loop >>>>>>>> 10 if (step .le. 100) then >>>>>>>> call PetscExceptionPush(87,ierr) >>>>>>>> call SNESSolve(snes,PETSC_NULL_OBJECT,x,ierr) >>>>>>>> call PetscExceptionPop(87,ierr2) >>>>>>>> >>>>>>>> call SNESGetConvergedReason(snes,reason,ierr) >>>>>>>> IF ( reason .LT. 0 ) THEN >>>>>>>> timestep=timestep/2 >>>>>>>> VecCopy(xb,x,ierr) >>>>>>>> write(6,*)"Solution diverged, trying with", >>>>>>>> . " smaller timestep: ",timestep >>>>>>>> ELSE >>>>>>>> IF ( ierr .EQ. 87) THEN >>>>>>>> timestep=timestep/2 >>>>>>>> VecCopy(xb,x,ierr) >>>>>>>> write(6,*) "No physical solution, trying", >>>>>>>> . " with smaller timestep: ",timestep >>>>>>>> ELSE >>>>>>>> timestep=dt >>>>>>>> step=step+1 >>>>>>>> VecCopy(x,xb,ierr) >>>>>>>> write(6,*) "Solve success, going for step: ",step >>>>>>>> ENDIF >>>>>>>> ENDIF >>>>>>>> goto 10 >>>>>>>> endif >>>>>>>> C End While loop >>>>>>>> >>>>>>>> And in my Formfunction I have added the following check: >>>>>>>> if (ET(L) .LT. 0) then >>>>>>>> ierr = 87 >>>>>>>> return >>>>>>>> endif >>>>>>>> >>>>>>>> PETSC_ERR_ARG_DOMAIN didnt work: error on line 6500 of SNESG3D2.F: >>>>>>>> data type is undefined for variable PETSC_ERR_ARG_DOMAIN >>>>>>>> Even thought I had petsc.h included. >>>>>>>> >>>>>>>> Can I do this check when I use TS also? I have the sameproblem with >>>>>>>> the values being negative when using TS. >>>>>>>> >>>>>>>> >>>>>>>> /nisse >>>>>>>> >>>>>>>> >>>>>>>> On 2/27/06, Barry Smith wrote: >>>>>>>>> >>>>>>>>> SNES works by computing p = -approxinv(J)*F(uold) and >>>>>>>>> then does a line search on unew = uold + lambda*p to get the >>>>>>>>> new u. First it uses a test value of 1 for lambda so it >>>>>>>>> tries to compute F(uold + p). It is possible that uold + p >>>>>>>>> has some "non-physical" values in it. There are two ways >>>>>>>>> you can try handling it: >>>>>>>>> >>>>>>>>> 1) Before doing the linesearch SNES calls a "precheck" function, >>>>>>>>> that can change the step if it decides there is a problem >>>>>>>>> with the step (like it is too long). You can provide your >>>>>>>>> own precheck function with SNESLineSearchSetPreCheck() it could, >>>>>>>>> for example, shrink the Newton direction to make it remain physical. >>>>>>>>> >>>>>>>>> or 2) when your form function detects an illegal value it calls >>>>>>>>> SETERRQ(PETSC_ERR_ARG_DOMAIN,"Nonphysical function input"); Note: >>>>>>>>> this is before it takes the square root of the negative number, >>>>>>>>> so check the number and call the error before calling SETERRQ(). >>>>>>>>> (If using Fortran then simply set ierr = PETSC_ERR_ARG_DOMAIN and >>>>>>>>> then immediately return). Then replace your call to SNESSolve with >>>>>>>>> ierr = PetscExceptionTry1(SNESSolve(snes,b,x),PETSC_ERR_ARG_DOMAIN); >>>>>>>>> if (PetscExceptionCaught(ierr,PETSC_ERR_ARG_DOMAIN)) { >>>>>>>>> /* this means your function found a non-physical value so >>>>>>>>> cut your time-step and continue through the loop again. */ >>>>>>>>> Put code to do this here. >>>>>>>>> } >>>>>>>>> If using fortran then do >>>>>>>>> call PetscExceptionPush(PETSC_ERR_ARG_DOMAIN,ierr) >>>>>>>>> call SNESSolve(snes,b,x,ierr) >>>>>>>>> call PetscExceptionPop(PETSC_ERR_ARG_DOMAIN,anotherierr) >>>>>>>>> if (ierr == PETSC_ERR_ARG_DOMAIN) then >>>>>>>>> non-physical value so cut the time-step and try again >>>>>>>>> else ! everything is normal so take the next time-step >>>>>>>>> >>>>>>>>> Barry >>>>>>>>> >>>>>>>>> The Fortran interface may be missing PetscExceptionPush() and Pop() >>>>>>>>> if so let us know and we'll provide the patch. >>>>>>>>> >>>>>>>>> On Mon, 27 Feb 2006, Nils Erik Svang?rd wrote: >>>>>>>>> >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> I have problems solving some CFD problems using SNES and my custom >>>>>>>>>> back-euler. I have 7 equations that I want to solve. >>>>>>>>>> >>>>>>>>>> First my FormFunction copies the values from the Vec that SNES uses to >>>>>>>>>> the variables that my code use: >>>>>>>>>> >>>>>>>>>> RO(L)=xx(1,L) >>>>>>>>>> RU(L)=xx(2,L) >>>>>>>>>> RV(L)=xx(3,L) >>>>>>>>>> RW(L)=xx(4,L) >>>>>>>>>> ET(L)=xx(5,L) >>>>>>>>>> RQ(L)= xx(6,L) >>>>>>>>>> REPS(L)=xx(7,L) >>>>>>>>>> >>>>>>>>>> Here I also print the values of ET(2) for debugging: >>>>>>>>>> >>>>>>>>>> write(6,*)"ET(2) = xx(5,2) : ",ET(2)," = ",xx(5,2) >>>>>>>>>> >>>>>>>>>> Then I get the fluxes by calling custom functions >>>>>>>>>> >>>>>>>>>> call AUXVR >>>>>>>>>> call VGRAD >>>>>>>>>> call FLUX >>>>>>>>>> call KESRC >>>>>>>>>> >>>>>>>>>> Then I perform back-euler save the new value to so that I can use it >>>>>>>>>> in the next iterationi (TSF(L) is Time step function, which is set by >>>>>>>>>> hand and is the same for all L): >>>>>>>>>> >>>>>>>>>> ff(1,L) = RO(L)-OLD(1,L)-TSF(L)*DRO(L) >>>>>>>>>> ff(2,L) = RU(L)-OLD(2,L)-TSF(L)*DRU(L) >>>>>>>>>> ff(3,L) = RV(L)-OLD(3,L)-TSF(L)*DRV(L) >>>>>>>>>> ff(4,L) = RW(L)-OLD(4,L)-TSF(L)*DRW(L) >>>>>>>>>> ff(5,L) = ET(L)-OLD(5,L)-TSF(L)*DET(L) >>>>>>>>>> ff(6,L) = RQ(L)-OLD(6,L)-TSF(L)*DRQ(L) >>>>>>>>>> ff(7,L) = REPS(L)-OLD(7,L)-TSF(L)*DREPS(L) >>>>>>>>>> >>>>>>>>>> And save the new value of RO-REPS to use in the next iteration of back-euler: >>>>>>>>>> >>>>>>>>>> OLD(1,L)=RO(L) >>>>>>>>>> OLD(2,L)=RU(L) >>>>>>>>>> OLD(3,L)=RV(L) >>>>>>>>>> OLD(4,L)=RW(L) >>>>>>>>>> OLD(5,L)=ET(L) >>>>>>>>>> OLD(6,L)=RQ(L) >>>>>>>>>> OLD(7,L)=REPS(L) >>>>>>>>>> >>>>>>>>>> Here I print the values of L=2 as above for debugging: >>>>>>>>>> >>>>>>>>>> write(6,*)ff(5,2)," = ",ET(2),"-",OLD(5,2),"-",TSF(2),"*",DET(2) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The program exit abnormaly after 33 runs of the FormFunction. The >>>>>>>>>> cause of this is that AUXVR tries to perform sqrt(ET(2)) when ET(2) is >>>>>>>>>> negative, ET is the total energy and should never be negative. It >>>>>>>>>> seems that all of a sudden the PETSc SNES solver decides to supply the >>>>>>>>>> FormFunction with a negative ET value. I need help understanding why >>>>>>>>>> and how to fix it (if it is fixable). >>>>>>>>>> >>>>>>>>>> Here is the output of: >>>>>>>>>> write(6,*)"ET(2) = xx(5,2) : ",ET(2)," = ",xx(5,2) >>>>>>>>>> Which is in the beginning of my FormFunction. >>>>>>>>>> And: >>>>>>>>>> write(6,*)ff(5,2)," = ",ET(2),"-",OLD(5,2),"-",TSF(2),"*",DET(2) >>>>>>>>>> Which is in the end of my Formfunction. >>>>>>>>>> >>>>>>>>>> 1. ET(2) = xx(5,2) : 253250. = 253250.000000000 >>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>>>>>>>>> 2. ET(2) = xx(5,2) : 253250. = 253250.000010259 >>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>>>>>>>>> 3. ET(2) = xx(5,2) : 253250. = 253249.999999988 >>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4132419437260 = >>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941324E+08 >>>>>>>>>> 4. ET(2) = xx(5,2) : 253250. = 253250.000048432 >>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>>>>>>>>> 5. ET(2) = xx(5,2) : 253250. = 253249.999999872 >>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4177283437784 = >>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941773E+08 >>>>>>>>>> 6. ET(2) = xx(5,2) : 253250. = 253250.000071113 >>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>>>>>>>>> 7. ET(2) = xx(5,2) : 253250. = 253249.999980115 >>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4453347441010 = >>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.944533E+08 >>>>>>>>>> 8. ET(2) = xx(5,2) : 253250. = 253250.000037298 >>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4082723436679 = >>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940827E+08 >>>>>>>>>> 9. ET(2) = xx(5,2) : 253250. = 253249.999942706 >>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4082723436679 = >>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940827E+08 >>>>>>>>>> 10. ET(2) = xx(5,2) : 253250. = 253249.999948703 >>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>>>>>>>>> 11. ET(2) = xx(5,2) : 253250. = 253250.000007808 >>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.7283811474088 = >>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.972838E+08 >>>>>>>>>> 12. ET(2) = xx(5,2) : 253250. = 253250.000018146 >>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>>>>>>>>> 13. ET(2) = xx(5,2) : 253250. = 253250.000001865 >>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 28.3742819315846 = >>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.837428E+08 >>>>>>>>>> 14. ET(2) = xx(5,2) : 253250. = 253249.999997296 >>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>>>>>>>>> 15. ET(2) = xx(5,2) : 253250. = 253250.000000049 >>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 30.6548963582361 = >>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -3.065490E+08 >>>>>>>>>> 16. ET(2) = xx(5,2) : 253250. = 253250.000022870 >>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>>>>>>>>> 17. ET(2) = xx(5,2) : 253250. = 253249.999999716 >>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.5326051451209 = >>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.953260E+08 >>>>>>>>>> 18. ET(2) = xx(5,2) : 253250. = 253250.000074328 >>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4165187437643 = >>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941652E+08 >>>>>>>>>> 19. ET(2) = xx(5,2) : 253250. = 253250.000049809 >>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4085059436707 = >>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940851E+08 >>>>>>>>>> 20. ET(2) = xx(5,2) : 253250. = 253250.000019253 >>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>>>>>>>>> 21. ET(2) = xx(5,2) : 253250. = 253250.000000189 >>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.8851075492403 = >>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.988511E+08 >>>>>>>>>> 22. ET(2) = xx(5,2) : 253250. = 253249.999997897 >>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4085059436707 = >>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940851E+08 >>>>>>>>>> 23. ET(2) = xx(5,2) : 253250. = 253249.999975142 >>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.3961539435263 = >>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.939615E+08 >>>>>>>>>> 24. ET(2) = xx(5,2) : 253250. = 253250.000018324 >>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4085059436707 = >>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940851E+08 >>>>>>>>>> 25. ET(2) = xx(5,2) : 253250. = 253249.999987073 >>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4165187437643 = >>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941652E+08 >>>>>>>>>> 26. ET(2) = xx(5,2) : 253250. = 253249.999980982 >>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4165187437643 = >>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941652E+08 >>>>>>>>>> 27. ET(2) = xx(5,2) : 253250. = 253249.999994645 >>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>>>>>>>>> 28. ET(2) = xx(5,2) : 253250. = 253249.999962364 >>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4165187437643 = >>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941652E+08 >>>>>>>>>> 29. ET(2) = xx(5,2) : 253250. = 253249.999999921 >>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>>>>>>>>> 30. ET(2) = xx(5,2) : 253250. = 253250.000000058 >>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 28.4019971319085 = >>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.840200E+08 >>>>>>>>>> 31. ET(2) = xx(5,2) : 253250. = 253250.000040348 >>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4085059436707 = >>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940851E+08 >>>>>>>>>> 32. ET(2) = xx(5,2) : 253250. = 253250.000005245 >>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>>>>>>>>> 33. ET(2) = xx(5,2) : 253250. = 253250.000005245 >>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>>>>>>>>> 34. ET(2) = xx(5,2) : -848141. = -848141.388090847 >>>>>>>>>> -------------------------------------------------------------------------- >>>>>>>>>> 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. >>>>>>>>>> ----------------------------------------------------------------------- >>>>>>>>>> ./SNESG3D2 on a linux-gnu named sethnx004.vac.com by yy26539 Mon Feb >>>>>>>>>> 27 14:21:13 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] SNES user function line 0 unknownunknown >>>>>>>>>> [0]PETSC ERROR: [0] SNESComputeFunction line 788 src/snes/interface/snes.c >>>>>>>>>> [0]PETSC ERROR: [0] SNESLineSearchCubic line 514 src/snes/impls/ls/ls.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: ! >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Suggestions and tips are very welcome! >>>>>>>>>> /nisse >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Nils-Erik Svang???rd >>>>>>>>>> MSN: schweingaard at hotmail.com >>>>>>>>>> Skype: schweingaard >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Nils-Erik Svang?rd >>>>>>>> MSN: schweingaard at hotmail.com >>>>>>>> Skype: schweingaard >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> 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 > > From bsmith at mcs.anl.gov Tue Mar 14 14:25:42 2006 From: bsmith at mcs.anl.gov (Barry Smith) Date: Tue, 14 Mar 2006 14:25:42 -0600 (CST) Subject: ***LOOPING MAIL*** PetscInitialize problem? In-Reply-To: <1142337786.4416b0fabfdb5@webmail.lncc.br> References: <1142275120.4415bc30c005d@webmail.lncc.br> <1142279432.4415cd08d6d72@webmail.lncc.br> <1142337786.4416b0fabfdb5@webmail.lncc.br> Message-ID: Are you sure that mpif.h is actually being included by include/finclude/petsc.h? Barry On Tue, 14 Mar 2006, ziemer at lncc.br wrote: > This is part of the source code where the problem happens: > > Thank you for your patience. > > ***************************************************************** > PROGRAM Premain > C ------------------------------------------------------------------ > ! Use ModuloLectura > IMPLICIT REAL*8 (A-H,O-Z) > ! > ! Parallel begin > ! petsc include files > #include "include/finclude/petsc.h" > ! Parallel end > ! > Logical Sym, NonLinearProblem,Iterative > INTEGER ERR_ALLOC > Parameter (Lch=16) > Character Str*120 > double precision noMPI_Wtime > C > ! INTERFACE ReadMat > ! MODULE PROCEDURE ReadMat > ! END INTERFACE > ! INTERFACE ReadCoupling > ! MODULE PROCEDURE ReadCoupling > ! END INTERFACE > ! INTERFACE Dimen > ! MODULE PROCEDURE Dimen > ! END INTERFACE > C > Allocatable X (:) > Allocatable Ie__Param (:) > Allocatable Ie_JParam (:) > Allocatable Param (:) > > ! Parallel begin > call PetscInitialize (PETSC_NULL_CHARACTER, iError) > if (iError.ne.0) then > Write (6,*) "Can't initialize PETSC" > Stop > End if > ! Ask total number of proccesses > ! > ! PROBLEM BEGINS IN THE NEXT FUNCTION - MPI_COMM_WORLD IS NOT SET!! > call MPI_Comm_size (MPI_COMM_WORLD, iSize, iError) > ! ID of this proccess > call MPI_Comm_rank (MPI_COMM_WORLD, iRank, iError) > ! > ********************************************************** > > > Quoting Satish Balay : > >> >> You should be able to use either MPI_COMM_WORLD or PETSC_COMM_WORLD or >> any other communicator. There must be something else wrong in your >> code. Can't comment without looking at the code. >> >> Satish >> >> On Mon, 13 Mar 2006, ziemer at lncc.br wrote: >> >>> Hi, >>> >>> The Petsc installation examples run ok. >>> >>> The strange thing is if I change the parameter MPI_COMM_WORLD of the >> function >>> MPI_Comm_size() to PTESC_COMM_WORLD this function works, but at same time >> this >>> same strategy does not work with the MPI_Bcast() function. >>> >>> Thank you very much for your nice help. >>> >>> Paulo Ziemer. >>> >>> >>> Quoting Satish Balay : >>> >>>> According to the error message - the communicator is invalid. You >>>> might want to check that.. >>>> >>>> You should be able to call MPI_Comm_size() after PetscInitialize() >>>> Check src/sys/examples/tutorials/ex1.c for an example of this usage. >>>> >>>> BTW: Do PETSc examples run fine with your install? >>>> >>>> Satish >>>> >>>> >>>> On Mon, 13 Mar 2006, ziemer at lncc.br wrote: >>>> >>>>> Hello, >>>>> >>>>> I would be very glad if someone could give me some direction: >>>>> >>>>> After the MPI_Comm_size function is called, I got this error: >>>>> >>>>> aborting job: >>>>> Fatal error in MPI_Comm_size: Invalid communicator, error stack: >>>>> MPI_Comm_size(110): MPI_Comm_size(comm=0x1, size=0xbfffdf78) failed >>>>> MPI_Comm_size(69): Invalid communicator >>>>> >>>>> It seems that the MPI environment is not being correctly created by the >>>> function >>>>> PetscInitialize. >>>>> >>>>> >>>>> Does anyone have any idea? >>>>> >>>>> >>>>> Best Regards. >>>>> >>>>> ---------------------------------------------------------------- >>>>> This message was sent using IMP, the Internet Messaging Program. >>>>> >>>>> >>>> >>> >>> >>> >>> >>> ---------------------------------------------------------------- >>> This message was sent using IMP, the Internet Messaging Program. >>> >>> > > > > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > > From nilserik at gmail.com Tue Mar 14 14:37:27 2006 From: nilserik at gmail.com (=?ISO-8859-1?Q?Nils_Erik_Svang=E5rd?=) Date: Tue, 14 Mar 2006 21:37:27 +0100 Subject: SNES Problem In-Reply-To: References: <82f936c20602270607t775d7e03o6a37afa4c0b3d2a8@mail.gmail.com> <82f936c20603020529j6d4181c8pc75c980357df9aa3@mail.gmail.com> <82f936c20603030047m5f64406n1435ca60f306fa98@mail.gmail.com> <82f936c20603030158u33722ff0q3c50839df14841@mail.gmail.com> <82f936c20603140727k208100f8vcb8f5672f9e9284e@mail.gmail.com> <82f936c20603141202p77439573hf249e43c53ae4d45@mail.gmail.com> Message-ID: <82f936c20603141237q2989c5a1i996ccf4815ed7f45@mail.gmail.com> On 3/14/06, Barry Smith wrote: > > > Hmm.. Ok so I could use my back-euler SNES implementation with my old > > timestep calculation function (using time-accurate timestep)? And it > > might work better. > > Nisse, > > First I'd like to see the PETSc rk code behaving pretty much the > same as your RK (then move onto the implicit code). Do I understand > that the PETSc rk code goes "non-physical" while your RK does not? Yes > If so, I was suggesting putting in YOUR timestep control into the > PETSc rk (I listed the file below). Once the PETSc rk behaves like > your rk we can move onto the implicit code. Reason: I want to confirm > that the basic "translation" to PETSc is working, before dealing > with the implicitness (which introduces its own difficulties). > I understand your suggestion, however I'm a bit unsure how to do that. The timestep control function used in the old code (written in Fortran) compares values from neigboring cells computing a value that is scaled to proper size (which is then used as a timestep). The time-accurate version of this uses the same algorithm but uses the min() of all timesteps as timestep for all cells. I also dont have access to the source code from this computer :-/ In the back-euler implementation, I think I just have to add one line to get the stability checking of the timestep working. /nisse > Barry > > > > On Tue, 14 Mar 2006, Nils Erik Svang?rd wrote: > > >>> Yes, there is a difference between the old 3-stage RK-solver and the > >>> SNESsolver using RK. In the old a timestep was calculatade for each > >> ^^^^^^^^^^^^^^^ > >> Are you using PETSc's explicit RK? If so that does not use SNES. > >> > > > > Sorry, I meant TS. > > > >>> cell based on a stability criteria and if chosen it could run in > >>> time-accurate mode eg. the timestep is the same for each cell, in SNES > >> ^^^^^^^^^ > >> Do you mean for backward Euler for the explicit RK? Or both? > > > > Sorry again, using TS I use the same size of the timestep on every > > cell (both when trying use back-euler and RK). > > In my old 3-stage RK I can use both variable timestep and > > time-accurate timestep. > > In my seperate back-euler implementation using SNES I use the same > > timestep on every cell. > > > >> > >>> I use a timestep that is the same for all cells and > >>> changes only if it returns non-physical answers or the solution diverges. > >> > >> I think you need to put the "proper" computation of the time-step > >> based on the stability criteria that you have in the "old" code. > >> Unfortunately this is currently hardwired in src/ts/impls/explicit/rk/rk.c > >> (search for "Computing next stepsize"). I think you need to use the minimum > >> of the timestep computed here and what is needed for the "stability criteria". > >> > > Hmm.. Ok so I could use my back-euler SNES implementation with my old > > timestep calculation function (using time-accurate timestep)? And it > > might work better. > > > > > > Thanks > > /nisse > > > >>> > >>> Another interesting observation is that when using back euler at the > >>> moment when it bugs out petsc has assigned neigboring cells pressure > >>> values that differs about 1 ATM, which is a very non physical value, > >> > >> Likely some stability problem. > >> > >> Barry > >> > >>> but I have no clue as to why petsc want such a value in thesolution. > >>> > >>> /nisse > >>> > >>> On 3/3/06, Barry Smith wrote: > >>>> > >>>> There must be a difference between the two RKs. The initial > >>>> timestep it uses, or algorithm for changing time step or slight > >>>> difference in algorithms? > >>>> > >>>> Barry > >>>> > >>>> On Fri, 3 Mar 2006, Nils Erik Svang?rd wrote: > >>>> > >>>>> A interesting thing is when I change TS_BEULER to TS_RUNGE_KUTTA the > >>>>> solver exits fast due to the non physical values. My original solver > >>>>> is a 3-step Runge-Kutta which works flawlessly. > >>>>> > >>>>> The error when running RK: > >>>>> > >>>>> ./ImplicitG3D on a linux-gnu named sethnx004.vac.com by yy26539 Fri > >>>>> Mar 3 10:31:27 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] TS user right-hand-side function line 0 unknownunknown > >>>>> [0]PETSC ERROR: [0] TSComputeRHSFunction line 282 src/ts/interface/ts.c > >>>>> [0]PETSC ERROR: [0] TSRkqs line 256 src/ts/impls/explicit/rk/rk.c > >>>>> [0]PETSC ERROR: [0] TSStep_Rk line 322 src/ts/impls/explicit/rk/rk.c > >>>>> [0]PETSC ERROR: [0] TSStep line 1520 src/ts/interface/ts.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 > >>>>> > >>>>> On 3/3/06, Nils Erik Svang?rd wrote: > >>>>>> Hello again, > >>>>>> > >>>>>>> Is it just not compiling because PETSC_ERR_ARG_DOMAIN is not > >>>>>>> defined? Or does it still not work even when you have put the number in? > >>>>>>> What is the error? Or did you get it all working with SNES? > >>>>>>> > >>>>>> > >>>>>> > >>>>>> It is not compiling because PETSC_ERR_ARG_DOMAIN is not defined: > >>>>>> > >>>>>> error on line 585 of SNESG3D2.F: data type is undefined for variable > >>>>>> PETSC_ERR_ARG_DOMAIN > >>>>>> > >>>>>> I tried putting a number in, then it compiles but complains while > >>>>>> linking that the Push() and Pop() functions is not defined. I made a > >>>>>> workaround by adding a variable in a common block and setting it > >>>>>> before returning from a non physical value in the FormFunction. Now I > >>>>>> can compile and when there is a non-physical value it returns and > >>>>>> resumes with a smaller timestep. > >>>>>> SNES still give non physical values which are hard to add checks for > >>>>>> in the program (e.g sqrt(RO(L)-RO(L+1))). > >>>>>> > >>>>>> Did I understand correctly that SNES does a linesearch and probably > >>>>>> goes for a solution which isnt the one I looking for? Does SNES use > >>>>>> the linesearch algorithm when I use -snes_mf (which I use)? > >>>>>> > >>>>>>> It may work automatically with TS; you would just set TS with a > >>>>>>> smaller timestep and call TSSolve again? > >>>>>>> > >>>>>> > >>>>>> OK, I'll add a check and put TSSolve in a while loop. > >>>>>> > >>>>>> My SNESSolve loop looks like this right now: > >>>>>> call VecCreateSeq(PETSC_COMM_SELF,N,x,ierr) > >>>>>> call VecDuplicate(x,r,ierr) > >>>>>> call VecDuplicate(x,xb,ierr) > >>>>>> call SNESCreate(PETSC_COMM_SELF,snes,ierr) > >>>>>> call SNESSetFunction(snes,r,FormFunction,PETSC_NULL_OBJECT,ierr) > >>>>>> call SNESSetFromOptions(snes,ierr) > >>>>>> call FormInitialGuess(x,ierr) > >>>>>> call VecCopy(x,xb,ierr) > >>>>>> write(6,*)zero,dt,tmax,i1000 > >>>>>> step=0 > >>>>>> timestep=dt > >>>>>> bang=0 > >>>>>> C While loop > >>>>>> 10 if (step .le. 100) then > >>>>>> C call PetscExceptionPush(87,ierr) > >>>>>> C call PetscExceptionPush(PETSC_ERR_ARG_DOMAIN,ierr) > >>>>>> call SNESSolve(snes,PETSC_NULL_OBJECT,x,ierr) > >>>>>> ierr=bang > >>>>>> C call PetscExceptionPop(87,ierr2) > >>>>>> IF ( ierr .EQ. 87) THEN > >>>>>> timestep=timestep/2 > >>>>>> call VecCopy(xb,x,ierr) > >>>>>> write(6,*) "No physical solution, trying", > >>>>>> . " with smaller timestep: ",timestep > >>>>>> bang=0 > >>>>>> ELSE > >>>>>> call SNESGetConvergedReason(snes,reason,ierr) > >>>>>> IF ( reason .LT. 0 ) THEN > >>>>>> timestep=timestep/2 > >>>>>> call VecCopy(xb,x,ierr) > >>>>>> write(6,*)"Solution diverged, trying with", > >>>>>> . " smaller timestep: ",timestep > >>>>>> ELSE > >>>>>> timestep=dt > >>>>>> step=step+1 > >>>>>> call VecCopy(x,xb,ierr) > >>>>>> write(6,*) "Solve success, going for step: ",step > >>>>>> write(6,*) "Reason: ",reason," ierr: ",ierr > >>>>>> reason=0 > >>>>>> ierr=0 > >>>>>> ENDIF > >>>>>> ENDIF > >>>>>> goto 10 > >>>>>> endif > >>>>>> C End While loop > >>>>>> > >>>>>> And the check in the FormFunction: > >>>>>> > >>>>>> if (ET(L) .LT. 0) then > >>>>>> ierr = 87 > >>>>>> bang = 87 > >>>>>> C SETERRQ(87,"Non physical value!",ierr) > >>>>>> return > >>>>>> elseif ( RO(L) .LT. 0 ) then > >>>>>> ierr = 87 > >>>>>> bang = 87 > >>>>>> return > >>>>>> endif > >>>>>> > >>>>>> > >>>>>> /nisse > >>>>>> > >>>>>> > >>>>>> > >>>>>>> Barry > >>>>>>> > >>>>>>> I'm adding a petscerror.h for Fortran that includes these values > >>>>>>> Sorry I forgot we hadn't given them for Fortran. > >>>>>>> > >>>>>>> On Thu, 2 Mar 2006, Nils Erik Svang?rd wrote: > >>>>>>> > >>>>>>>> Hi again, > >>>>>>>> I realised that my implementation was a bit flawed so I have rewritten > >>>>>>>> it again, the push and pop() functions dont seem to work, and they are > >>>>>>>> keeping me from compiling the program, this is the main timestep loop: > >>>>>>>> > >>>>>>>> call VecCreateSeq(PETSC_COMM_SELF,N,x,ierr) > >>>>>>>> call VecDuplicate(x,r,ierr) > >>>>>>>> call VecDuplicate(x,xb,ierr) > >>>>>>>> call SNESCreate(PETSC_COMM_SELF,snes,ierr) > >>>>>>>> call SNESSetFunction(snes,r,FormFunction,PETSC_NULL_OBJECT,ierr) > >>>>>>>> call SNESSetFromOptions(snes,ierr) > >>>>>>>> call FormInitialGuess(x,ierr) > >>>>>>>> call VecCopy(x,xb,ierr) > >>>>>>>> write(6,*)zero,dt,tmax,i1000 > >>>>>>>> step=0 > >>>>>>>> timestep=dt > >>>>>>>> C While loop > >>>>>>>> 10 if (step .le. 100) then > >>>>>>>> call PetscExceptionPush(87,ierr) > >>>>>>>> call SNESSolve(snes,PETSC_NULL_OBJECT,x,ierr) > >>>>>>>> call PetscExceptionPop(87,ierr2) > >>>>>>>> > >>>>>>>> call SNESGetConvergedReason(snes,reason,ierr) > >>>>>>>> IF ( reason .LT. 0 ) THEN > >>>>>>>> timestep=timestep/2 > >>>>>>>> VecCopy(xb,x,ierr) > >>>>>>>> write(6,*)"Solution diverged, trying with", > >>>>>>>> . " smaller timestep: ",timestep > >>>>>>>> ELSE > >>>>>>>> IF ( ierr .EQ. 87) THEN > >>>>>>>> timestep=timestep/2 > >>>>>>>> VecCopy(xb,x,ierr) > >>>>>>>> write(6,*) "No physical solution, trying", > >>>>>>>> . " with smaller timestep: ",timestep > >>>>>>>> ELSE > >>>>>>>> timestep=dt > >>>>>>>> step=step+1 > >>>>>>>> VecCopy(x,xb,ierr) > >>>>>>>> write(6,*) "Solve success, going for step: ",step > >>>>>>>> ENDIF > >>>>>>>> ENDIF > >>>>>>>> goto 10 > >>>>>>>> endif > >>>>>>>> C End While loop > >>>>>>>> > >>>>>>>> And in my Formfunction I have added the following check: > >>>>>>>> if (ET(L) .LT. 0) then > >>>>>>>> ierr = 87 > >>>>>>>> return > >>>>>>>> endif > >>>>>>>> > >>>>>>>> PETSC_ERR_ARG_DOMAIN didnt work: error on line 6500 of SNESG3D2.F: > >>>>>>>> data type is undefined for variable PETSC_ERR_ARG_DOMAIN > >>>>>>>> Even thought I had petsc.h included. > >>>>>>>> > >>>>>>>> Can I do this check when I use TS also? I have the sameproblem with > >>>>>>>> the values being negative when using TS. > >>>>>>>> > >>>>>>>> > >>>>>>>> /nisse > >>>>>>>> > >>>>>>>> > >>>>>>>> On 2/27/06, Barry Smith wrote: > >>>>>>>>> > >>>>>>>>> SNES works by computing p = -approxinv(J)*F(uold) and > >>>>>>>>> then does a line search on unew = uold + lambda*p to get the > >>>>>>>>> new u. First it uses a test value of 1 for lambda so it > >>>>>>>>> tries to compute F(uold + p). It is possible that uold + p > >>>>>>>>> has some "non-physical" values in it. There are two ways > >>>>>>>>> you can try handling it: > >>>>>>>>> > >>>>>>>>> 1) Before doing the linesearch SNES calls a "precheck" function, > >>>>>>>>> that can change the step if it decides there is a problem > >>>>>>>>> with the step (like it is too long). You can provide your > >>>>>>>>> own precheck function with SNESLineSearchSetPreCheck() it could, > >>>>>>>>> for example, shrink the Newton direction to make it remain physical. > >>>>>>>>> > >>>>>>>>> or 2) when your form function detects an illegal value it calls > >>>>>>>>> SETERRQ(PETSC_ERR_ARG_DOMAIN,"Nonphysical function input"); Note: > >>>>>>>>> this is before it takes the square root of the negative number, > >>>>>>>>> so check the number and call the error before calling SETERRQ(). > >>>>>>>>> (If using Fortran then simply set ierr = PETSC_ERR_ARG_DOMAIN and > >>>>>>>>> then immediately return). Then replace your call to SNESSolve with > >>>>>>>>> ierr = PetscExceptionTry1(SNESSolve(snes,b,x),PETSC_ERR_ARG_DOMAIN); > >>>>>>>>> if (PetscExceptionCaught(ierr,PETSC_ERR_ARG_DOMAIN)) { > >>>>>>>>> /* this means your function found a non-physical value so > >>>>>>>>> cut your time-step and continue through the loop again. */ > >>>>>>>>> Put code to do this here. > >>>>>>>>> } > >>>>>>>>> If using fortran then do > >>>>>>>>> call PetscExceptionPush(PETSC_ERR_ARG_DOMAIN,ierr) > >>>>>>>>> call SNESSolve(snes,b,x,ierr) > >>>>>>>>> call PetscExceptionPop(PETSC_ERR_ARG_DOMAIN,anotherierr) > >>>>>>>>> if (ierr == PETSC_ERR_ARG_DOMAIN) then > >>>>>>>>> non-physical value so cut the time-step and try again > >>>>>>>>> else ! everything is normal so take the next time-step > >>>>>>>>> > >>>>>>>>> Barry > >>>>>>>>> > >>>>>>>>> The Fortran interface may be missing PetscExceptionPush() and Pop() > >>>>>>>>> if so let us know and we'll provide the patch. > >>>>>>>>> > >>>>>>>>> On Mon, 27 Feb 2006, Nils Erik Svang?rd wrote: > >>>>>>>>> > >>>>>>>>>> Hi all, > >>>>>>>>>> > >>>>>>>>>> I have problems solving some CFD problems using SNES and my custom > >>>>>>>>>> back-euler. I have 7 equations that I want to solve. > >>>>>>>>>> > >>>>>>>>>> First my FormFunction copies the values from the Vec that SNES uses to > >>>>>>>>>> the variables that my code use: > >>>>>>>>>> > >>>>>>>>>> RO(L)=xx(1,L) > >>>>>>>>>> RU(L)=xx(2,L) > >>>>>>>>>> RV(L)=xx(3,L) > >>>>>>>>>> RW(L)=xx(4,L) > >>>>>>>>>> ET(L)=xx(5,L) > >>>>>>>>>> RQ(L)= xx(6,L) > >>>>>>>>>> REPS(L)=xx(7,L) > >>>>>>>>>> > >>>>>>>>>> Here I also print the values of ET(2) for debugging: > >>>>>>>>>> > >>>>>>>>>> write(6,*)"ET(2) = xx(5,2) : ",ET(2)," = ",xx(5,2) > >>>>>>>>>> > >>>>>>>>>> Then I get the fluxes by calling custom functions > >>>>>>>>>> > >>>>>>>>>> call AUXVR > >>>>>>>>>> call VGRAD > >>>>>>>>>> call FLUX > >>>>>>>>>> call KESRC > >>>>>>>>>> > >>>>>>>>>> Then I perform back-euler save the new value to so that I can use it > >>>>>>>>>> in the next iterationi (TSF(L) is Time step function, which is set by > >>>>>>>>>> hand and is the same for all L): > >>>>>>>>>> > >>>>>>>>>> ff(1,L) = RO(L)-OLD(1,L)-TSF(L)*DRO(L) > >>>>>>>>>> ff(2,L) = RU(L)-OLD(2,L)-TSF(L)*DRU(L) > >>>>>>>>>> ff(3,L) = RV(L)-OLD(3,L)-TSF(L)*DRV(L) > >>>>>>>>>> ff(4,L) = RW(L)-OLD(4,L)-TSF(L)*DRW(L) > >>>>>>>>>> ff(5,L) = ET(L)-OLD(5,L)-TSF(L)*DET(L) > >>>>>>>>>> ff(6,L) = RQ(L)-OLD(6,L)-TSF(L)*DRQ(L) > >>>>>>>>>> ff(7,L) = REPS(L)-OLD(7,L)-TSF(L)*DREPS(L) > >>>>>>>>>> > >>>>>>>>>> And save the new value of RO-REPS to use in the next iteration of back-euler: > >>>>>>>>>> > >>>>>>>>>> OLD(1,L)=RO(L) > >>>>>>>>>> OLD(2,L)=RU(L) > >>>>>>>>>> OLD(3,L)=RV(L) > >>>>>>>>>> OLD(4,L)=RW(L) > >>>>>>>>>> OLD(5,L)=ET(L) > >>>>>>>>>> OLD(6,L)=RQ(L) > >>>>>>>>>> OLD(7,L)=REPS(L) > >>>>>>>>>> > >>>>>>>>>> Here I print the values of L=2 as above for debugging: > >>>>>>>>>> > >>>>>>>>>> write(6,*)ff(5,2)," = ",ET(2),"-",OLD(5,2),"-",TSF(2),"*",DET(2) > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> The program exit abnormaly after 33 runs of the FormFunction. The > >>>>>>>>>> cause of this is that AUXVR tries to perform sqrt(ET(2)) when ET(2) is > >>>>>>>>>> negative, ET is the total energy and should never be negative. It > >>>>>>>>>> seems that all of a sudden the PETSc SNES solver decides to supply the > >>>>>>>>>> FormFunction with a negative ET value. I need help understanding why > >>>>>>>>>> and how to fix it (if it is fixable). > >>>>>>>>>> > >>>>>>>>>> Here is the output of: > >>>>>>>>>> write(6,*)"ET(2) = xx(5,2) : ",ET(2)," = ",xx(5,2) > >>>>>>>>>> Which is in the beginning of my FormFunction. > >>>>>>>>>> And: > >>>>>>>>>> write(6,*)ff(5,2)," = ",ET(2),"-",OLD(5,2),"-",TSF(2),"*",DET(2) > >>>>>>>>>> Which is in the end of my Formfunction. > >>>>>>>>>> > >>>>>>>>>> 1. ET(2) = xx(5,2) : 253250. = 253250.000000000 > >>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > >>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > >>>>>>>>>> 2. ET(2) = xx(5,2) : 253250. = 253250.000010259 > >>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > >>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > >>>>>>>>>> 3. ET(2) = xx(5,2) : 253250. = 253249.999999988 > >>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4132419437260 = > >>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941324E+08 > >>>>>>>>>> 4. ET(2) = xx(5,2) : 253250. = 253250.000048432 > >>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > >>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > >>>>>>>>>> 5. ET(2) = xx(5,2) : 253250. = 253249.999999872 > >>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4177283437784 = > >>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941773E+08 > >>>>>>>>>> 6. ET(2) = xx(5,2) : 253250. = 253250.000071113 > >>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > >>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > >>>>>>>>>> 7. ET(2) = xx(5,2) : 253250. = 253249.999980115 > >>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4453347441010 = > >>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.944533E+08 > >>>>>>>>>> 8. ET(2) = xx(5,2) : 253250. = 253250.000037298 > >>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4082723436679 = > >>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940827E+08 > >>>>>>>>>> 9. ET(2) = xx(5,2) : 253250. = 253249.999942706 > >>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4082723436679 = > >>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940827E+08 > >>>>>>>>>> 10. ET(2) = xx(5,2) : 253250. = 253249.999948703 > >>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > >>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > >>>>>>>>>> 11. ET(2) = xx(5,2) : 253250. = 253250.000007808 > >>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.7283811474088 = > >>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.972838E+08 > >>>>>>>>>> 12. ET(2) = xx(5,2) : 253250. = 253250.000018146 > >>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > >>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > >>>>>>>>>> 13. ET(2) = xx(5,2) : 253250. = 253250.000001865 > >>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 28.3742819315846 = > >>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.837428E+08 > >>>>>>>>>> 14. ET(2) = xx(5,2) : 253250. = 253249.999997296 > >>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > >>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > >>>>>>>>>> 15. ET(2) = xx(5,2) : 253250. = 253250.000000049 > >>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 30.6548963582361 = > >>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -3.065490E+08 > >>>>>>>>>> 16. ET(2) = xx(5,2) : 253250. = 253250.000022870 > >>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > >>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > >>>>>>>>>> 17. ET(2) = xx(5,2) : 253250. = 253249.999999716 > >>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.5326051451209 = > >>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.953260E+08 > >>>>>>>>>> 18. ET(2) = xx(5,2) : 253250. = 253250.000074328 > >>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4165187437643 = > >>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941652E+08 > >>>>>>>>>> 19. ET(2) = xx(5,2) : 253250. = 253250.000049809 > >>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4085059436707 = > >>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940851E+08 > >>>>>>>>>> 20. ET(2) = xx(5,2) : 253250. = 253250.000019253 > >>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > >>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > >>>>>>>>>> 21. ET(2) = xx(5,2) : 253250. = 253250.000000189 > >>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.8851075492403 = > >>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.988511E+08 > >>>>>>>>>> 22. ET(2) = xx(5,2) : 253250. = 253249.999997897 > >>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4085059436707 = > >>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940851E+08 > >>>>>>>>>> 23. ET(2) = xx(5,2) : 253250. = 253249.999975142 > >>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.3961539435263 = > >>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.939615E+08 > >>>>>>>>>> 24. ET(2) = xx(5,2) : 253250. = 253250.000018324 > >>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4085059436707 = > >>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940851E+08 > >>>>>>>>>> 25. ET(2) = xx(5,2) : 253250. = 253249.999987073 > >>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4165187437643 = > >>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941652E+08 > >>>>>>>>>> 26. ET(2) = xx(5,2) : 253250. = 253249.999980982 > >>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4165187437643 = > >>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941652E+08 > >>>>>>>>>> 27. ET(2) = xx(5,2) : 253250. = 253249.999994645 > >>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > >>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > >>>>>>>>>> 28. ET(2) = xx(5,2) : 253250. = 253249.999962364 > >>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4165187437643 = > >>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941652E+08 > >>>>>>>>>> 29. ET(2) = xx(5,2) : 253250. = 253249.999999921 > >>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > >>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > >>>>>>>>>> 30. ET(2) = xx(5,2) : 253250. = 253250.000000058 > >>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 28.4019971319085 = > >>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.840200E+08 > >>>>>>>>>> 31. ET(2) = xx(5,2) : 253250. = 253250.000040348 > >>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4085059436707 = > >>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940851E+08 > >>>>>>>>>> 32. ET(2) = xx(5,2) : 253250. = 253250.000005245 > >>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > >>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > >>>>>>>>>> 33. ET(2) = xx(5,2) : 253250. = 253250.000005245 > >>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > >>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > >>>>>>>>>> 34. ET(2) = xx(5,2) : -848141. = -848141.388090847 > >>>>>>>>>> -------------------------------------------------------------------------- > >>>>>>>>>> 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. > >>>>>>>>>> ----------------------------------------------------------------------- > >>>>>>>>>> ./SNESG3D2 on a linux-gnu named sethnx004.vac.com by yy26539 Mon Feb > >>>>>>>>>> 27 14:21:13 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] SNES user function line 0 unknownunknown > >>>>>>>>>> [0]PETSC ERROR: [0] SNESComputeFunction line 788 src/snes/interface/snes.c > >>>>>>>>>> [0]PETSC ERROR: [0] SNESLineSearchCubic line 514 src/snes/impls/ls/ls.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: ! > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Suggestions and tips are very welcome! > >>>>>>>>>> /nisse > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> -- > >>>>>>>>>> Nils-Erik Svang???rd > >>>>>>>>>> MSN: schweingaard at hotmail.com > >>>>>>>>>> Skype: schweingaard > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> -- > >>>>>>>> Nils-Erik Svang?rd > >>>>>>>> MSN: schweingaard at hotmail.com > >>>>>>>> Skype: schweingaard > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> 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 From bsmith at mcs.anl.gov Tue Mar 14 15:10:41 2006 From: bsmith at mcs.anl.gov (Barry Smith) Date: Tue, 14 Mar 2006 15:10:41 -0600 (CST) Subject: SNES Problem In-Reply-To: <82f936c20603141237q2989c5a1i996ccf4815ed7f45@mail.gmail.com> References: <82f936c20602270607t775d7e03o6a37afa4c0b3d2a8@mail.gmail.com> <82f936c20603020529j6d4181c8pc75c980357df9aa3@mail.gmail.com> <82f936c20603030047m5f64406n1435ca60f306fa98@mail.gmail.com> <82f936c20603030158u33722ff0q3c50839df14841@mail.gmail.com> <82f936c20603140727k208100f8vcb8f5672f9e9284e@mail.gmail.com> <82f936c20603141202p77439573hf249e43c53ae4d45@mail.gmail.com> <82f936c20603141237q2989c5a1i996ccf4815ed7f45@mail.gmail.com> Message-ID: On Tue, 14 Mar 2006, Nils Erik Svang?rd wrote: > On 3/14/06, Barry Smith wrote: >> >>> Hmm.. Ok so I could use my back-euler SNES implementation with my old >>> timestep calculation function (using time-accurate timestep)? And it >>> might work better. >> >> Nisse, >> >> First I'd like to see the PETSc rk code behaving pretty much the >> same as your RK (then move onto the implicit code). Do I understand >> that the PETSc rk code goes "non-physical" while your RK does not? > > Yes > >> If so, I was suggesting putting in YOUR timestep control into the >> PETSc rk (I listed the file below). Once the PETSc rk behaves like >> your rk we can move onto the implicit code. Reason: I want to confirm >> that the basic "translation" to PETSc is working, before dealing >> with the implicitness (which introduces its own difficulties). >> > > I understand your suggestion, however I'm a bit unsure how to do that. > The timestep control function used in the old code (written in > Fortran) compares values from neigboring cells computing a value that > is scaled to proper size (which is then used as a timestep). The > time-accurate version of this uses the same algorithm but uses the > min() of all timesteps as timestep for all cells. I also dont have > access to the source code from this computer :-/ Just get a copy of rk.c and link it in with your code; you don't have to muck with the actual file that goes into the PETSc library. > In the back-euler implementation, I think I just have to add one line > to get the stability checking of the timestep working. If it is one line for backward Euler, why isn't one line for RK? You can simply call the code in fortran that computes the time-step, can't you then use MPI_Allreduce to get the min over all processors. Here is the issue: the ONLY reason to use an implicit method is to increase the timestep which you cannot do with the explicit code due to stability constraints. But if you use the same time-step with the implicit code as with the explicit code you gain nothing over using the explicit code (in fact you do worse because the implicit code is more expensive per timestep). Barry > > /nisse >> Barry >> >> >> >> On Tue, 14 Mar 2006, Nils Erik Svang?rd wrote: >> >>>>> Yes, there is a difference between the old 3-stage RK-solver and the >>>>> SNESsolver using RK. In the old a timestep was calculatade for each >>>> ^^^^^^^^^^^^^^^ >>>> Are you using PETSc's explicit RK? If so that does not use SNES. >>>> >>> >>> Sorry, I meant TS. >>> >>>>> cell based on a stability criteria and if chosen it could run in >>>>> time-accurate mode eg. the timestep is the same for each cell, in SNES >>>> ^^^^^^^^^ >>>> Do you mean for backward Euler for the explicit RK? Or both? >>> >>> Sorry again, using TS I use the same size of the timestep on every >>> cell (both when trying use back-euler and RK). >>> In my old 3-stage RK I can use both variable timestep and >>> time-accurate timestep. >>> In my seperate back-euler implementation using SNES I use the same >>> timestep on every cell. >>> >>>> >>>>> I use a timestep that is the same for all cells and >>>>> changes only if it returns non-physical answers or the solution diverges. >>>> >>>> I think you need to put the "proper" computation of the time-step >>>> based on the stability criteria that you have in the "old" code. >>>> Unfortunately this is currently hardwired in src/ts/impls/explicit/rk/rk.c >>>> (search for "Computing next stepsize"). I think you need to use the minimum >>>> of the timestep computed here and what is needed for the "stability criteria". >>>> >>> Hmm.. Ok so I could use my back-euler SNES implementation with my old >>> timestep calculation function (using time-accurate timestep)? And it >>> might work better. >>> >>> >>> Thanks >>> /nisse >>> >>>>> >>>>> Another interesting observation is that when using back euler at the >>>>> moment when it bugs out petsc has assigned neigboring cells pressure >>>>> values that differs about 1 ATM, which is a very non physical value, >>>> >>>> Likely some stability problem. >>>> >>>> Barry >>>> >>>>> but I have no clue as to why petsc want such a value in thesolution. >>>>> >>>>> /nisse >>>>> >>>>> On 3/3/06, Barry Smith wrote: >>>>>> >>>>>> There must be a difference between the two RKs. The initial >>>>>> timestep it uses, or algorithm for changing time step or slight >>>>>> difference in algorithms? >>>>>> >>>>>> Barry >>>>>> >>>>>> On Fri, 3 Mar 2006, Nils Erik Svang?rd wrote: >>>>>> >>>>>>> A interesting thing is when I change TS_BEULER to TS_RUNGE_KUTTA the >>>>>>> solver exits fast due to the non physical values. My original solver >>>>>>> is a 3-step Runge-Kutta which works flawlessly. >>>>>>> >>>>>>> The error when running RK: >>>>>>> >>>>>>> ./ImplicitG3D on a linux-gnu named sethnx004.vac.com by yy26539 Fri >>>>>>> Mar 3 10:31:27 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] TS user right-hand-side function line 0 unknownunknown >>>>>>> [0]PETSC ERROR: [0] TSComputeRHSFunction line 282 src/ts/interface/ts.c >>>>>>> [0]PETSC ERROR: [0] TSRkqs line 256 src/ts/impls/explicit/rk/rk.c >>>>>>> [0]PETSC ERROR: [0] TSStep_Rk line 322 src/ts/impls/explicit/rk/rk.c >>>>>>> [0]PETSC ERROR: [0] TSStep line 1520 src/ts/interface/ts.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 >>>>>>> >>>>>>> On 3/3/06, Nils Erik Svang?rd wrote: >>>>>>>> Hello again, >>>>>>>> >>>>>>>>> Is it just not compiling because PETSC_ERR_ARG_DOMAIN is not >>>>>>>>> defined? Or does it still not work even when you have put the number in? >>>>>>>>> What is the error? Or did you get it all working with SNES? >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> It is not compiling because PETSC_ERR_ARG_DOMAIN is not defined: >>>>>>>> >>>>>>>> error on line 585 of SNESG3D2.F: data type is undefined for variable >>>>>>>> PETSC_ERR_ARG_DOMAIN >>>>>>>> >>>>>>>> I tried putting a number in, then it compiles but complains while >>>>>>>> linking that the Push() and Pop() functions is not defined. I made a >>>>>>>> workaround by adding a variable in a common block and setting it >>>>>>>> before returning from a non physical value in the FormFunction. Now I >>>>>>>> can compile and when there is a non-physical value it returns and >>>>>>>> resumes with a smaller timestep. >>>>>>>> SNES still give non physical values which are hard to add checks for >>>>>>>> in the program (e.g sqrt(RO(L)-RO(L+1))). >>>>>>>> >>>>>>>> Did I understand correctly that SNES does a linesearch and probably >>>>>>>> goes for a solution which isnt the one I looking for? Does SNES use >>>>>>>> the linesearch algorithm when I use -snes_mf (which I use)? >>>>>>>> >>>>>>>>> It may work automatically with TS; you would just set TS with a >>>>>>>>> smaller timestep and call TSSolve again? >>>>>>>>> >>>>>>>> >>>>>>>> OK, I'll add a check and put TSSolve in a while loop. >>>>>>>> >>>>>>>> My SNESSolve loop looks like this right now: >>>>>>>> call VecCreateSeq(PETSC_COMM_SELF,N,x,ierr) >>>>>>>> call VecDuplicate(x,r,ierr) >>>>>>>> call VecDuplicate(x,xb,ierr) >>>>>>>> call SNESCreate(PETSC_COMM_SELF,snes,ierr) >>>>>>>> call SNESSetFunction(snes,r,FormFunction,PETSC_NULL_OBJECT,ierr) >>>>>>>> call SNESSetFromOptions(snes,ierr) >>>>>>>> call FormInitialGuess(x,ierr) >>>>>>>> call VecCopy(x,xb,ierr) >>>>>>>> write(6,*)zero,dt,tmax,i1000 >>>>>>>> step=0 >>>>>>>> timestep=dt >>>>>>>> bang=0 >>>>>>>> C While loop >>>>>>>> 10 if (step .le. 100) then >>>>>>>> C call PetscExceptionPush(87,ierr) >>>>>>>> C call PetscExceptionPush(PETSC_ERR_ARG_DOMAIN,ierr) >>>>>>>> call SNESSolve(snes,PETSC_NULL_OBJECT,x,ierr) >>>>>>>> ierr=bang >>>>>>>> C call PetscExceptionPop(87,ierr2) >>>>>>>> IF ( ierr .EQ. 87) THEN >>>>>>>> timestep=timestep/2 >>>>>>>> call VecCopy(xb,x,ierr) >>>>>>>> write(6,*) "No physical solution, trying", >>>>>>>> . " with smaller timestep: ",timestep >>>>>>>> bang=0 >>>>>>>> ELSE >>>>>>>> call SNESGetConvergedReason(snes,reason,ierr) >>>>>>>> IF ( reason .LT. 0 ) THEN >>>>>>>> timestep=timestep/2 >>>>>>>> call VecCopy(xb,x,ierr) >>>>>>>> write(6,*)"Solution diverged, trying with", >>>>>>>> . " smaller timestep: ",timestep >>>>>>>> ELSE >>>>>>>> timestep=dt >>>>>>>> step=step+1 >>>>>>>> call VecCopy(x,xb,ierr) >>>>>>>> write(6,*) "Solve success, going for step: ",step >>>>>>>> write(6,*) "Reason: ",reason," ierr: ",ierr >>>>>>>> reason=0 >>>>>>>> ierr=0 >>>>>>>> ENDIF >>>>>>>> ENDIF >>>>>>>> goto 10 >>>>>>>> endif >>>>>>>> C End While loop >>>>>>>> >>>>>>>> And the check in the FormFunction: >>>>>>>> >>>>>>>> if (ET(L) .LT. 0) then >>>>>>>> ierr = 87 >>>>>>>> bang = 87 >>>>>>>> C SETERRQ(87,"Non physical value!",ierr) >>>>>>>> return >>>>>>>> elseif ( RO(L) .LT. 0 ) then >>>>>>>> ierr = 87 >>>>>>>> bang = 87 >>>>>>>> return >>>>>>>> endif >>>>>>>> >>>>>>>> >>>>>>>> /nisse >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Barry >>>>>>>>> >>>>>>>>> I'm adding a petscerror.h for Fortran that includes these values >>>>>>>>> Sorry I forgot we hadn't given them for Fortran. >>>>>>>>> >>>>>>>>> On Thu, 2 Mar 2006, Nils Erik Svang?rd wrote: >>>>>>>>> >>>>>>>>>> Hi again, >>>>>>>>>> I realised that my implementation was a bit flawed so I have rewritten >>>>>>>>>> it again, the push and pop() functions dont seem to work, and they are >>>>>>>>>> keeping me from compiling the program, this is the main timestep loop: >>>>>>>>>> >>>>>>>>>> call VecCreateSeq(PETSC_COMM_SELF,N,x,ierr) >>>>>>>>>> call VecDuplicate(x,r,ierr) >>>>>>>>>> call VecDuplicate(x,xb,ierr) >>>>>>>>>> call SNESCreate(PETSC_COMM_SELF,snes,ierr) >>>>>>>>>> call SNESSetFunction(snes,r,FormFunction,PETSC_NULL_OBJECT,ierr) >>>>>>>>>> call SNESSetFromOptions(snes,ierr) >>>>>>>>>> call FormInitialGuess(x,ierr) >>>>>>>>>> call VecCopy(x,xb,ierr) >>>>>>>>>> write(6,*)zero,dt,tmax,i1000 >>>>>>>>>> step=0 >>>>>>>>>> timestep=dt >>>>>>>>>> C While loop >>>>>>>>>> 10 if (step .le. 100) then >>>>>>>>>> call PetscExceptionPush(87,ierr) >>>>>>>>>> call SNESSolve(snes,PETSC_NULL_OBJECT,x,ierr) >>>>>>>>>> call PetscExceptionPop(87,ierr2) >>>>>>>>>> >>>>>>>>>> call SNESGetConvergedReason(snes,reason,ierr) >>>>>>>>>> IF ( reason .LT. 0 ) THEN >>>>>>>>>> timestep=timestep/2 >>>>>>>>>> VecCopy(xb,x,ierr) >>>>>>>>>> write(6,*)"Solution diverged, trying with", >>>>>>>>>> . " smaller timestep: ",timestep >>>>>>>>>> ELSE >>>>>>>>>> IF ( ierr .EQ. 87) THEN >>>>>>>>>> timestep=timestep/2 >>>>>>>>>> VecCopy(xb,x,ierr) >>>>>>>>>> write(6,*) "No physical solution, trying", >>>>>>>>>> . " with smaller timestep: ",timestep >>>>>>>>>> ELSE >>>>>>>>>> timestep=dt >>>>>>>>>> step=step+1 >>>>>>>>>> VecCopy(x,xb,ierr) >>>>>>>>>> write(6,*) "Solve success, going for step: ",step >>>>>>>>>> ENDIF >>>>>>>>>> ENDIF >>>>>>>>>> goto 10 >>>>>>>>>> endif >>>>>>>>>> C End While loop >>>>>>>>>> >>>>>>>>>> And in my Formfunction I have added the following check: >>>>>>>>>> if (ET(L) .LT. 0) then >>>>>>>>>> ierr = 87 >>>>>>>>>> return >>>>>>>>>> endif >>>>>>>>>> >>>>>>>>>> PETSC_ERR_ARG_DOMAIN didnt work: error on line 6500 of SNESG3D2.F: >>>>>>>>>> data type is undefined for variable PETSC_ERR_ARG_DOMAIN >>>>>>>>>> Even thought I had petsc.h included. >>>>>>>>>> >>>>>>>>>> Can I do this check when I use TS also? I have the sameproblem with >>>>>>>>>> the values being negative when using TS. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> /nisse >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2/27/06, Barry Smith wrote: >>>>>>>>>>> >>>>>>>>>>> SNES works by computing p = -approxinv(J)*F(uold) and >>>>>>>>>>> then does a line search on unew = uold + lambda*p to get the >>>>>>>>>>> new u. First it uses a test value of 1 for lambda so it >>>>>>>>>>> tries to compute F(uold + p). It is possible that uold + p >>>>>>>>>>> has some "non-physical" values in it. There are two ways >>>>>>>>>>> you can try handling it: >>>>>>>>>>> >>>>>>>>>>> 1) Before doing the linesearch SNES calls a "precheck" function, >>>>>>>>>>> that can change the step if it decides there is a problem >>>>>>>>>>> with the step (like it is too long). You can provide your >>>>>>>>>>> own precheck function with SNESLineSearchSetPreCheck() it could, >>>>>>>>>>> for example, shrink the Newton direction to make it remain physical. >>>>>>>>>>> >>>>>>>>>>> or 2) when your form function detects an illegal value it calls >>>>>>>>>>> SETERRQ(PETSC_ERR_ARG_DOMAIN,"Nonphysical function input"); Note: >>>>>>>>>>> this is before it takes the square root of the negative number, >>>>>>>>>>> so check the number and call the error before calling SETERRQ(). >>>>>>>>>>> (If using Fortran then simply set ierr = PETSC_ERR_ARG_DOMAIN and >>>>>>>>>>> then immediately return). Then replace your call to SNESSolve with >>>>>>>>>>> ierr = PetscExceptionTry1(SNESSolve(snes,b,x),PETSC_ERR_ARG_DOMAIN); >>>>>>>>>>> if (PetscExceptionCaught(ierr,PETSC_ERR_ARG_DOMAIN)) { >>>>>>>>>>> /* this means your function found a non-physical value so >>>>>>>>>>> cut your time-step and continue through the loop again. */ >>>>>>>>>>> Put code to do this here. >>>>>>>>>>> } >>>>>>>>>>> If using fortran then do >>>>>>>>>>> call PetscExceptionPush(PETSC_ERR_ARG_DOMAIN,ierr) >>>>>>>>>>> call SNESSolve(snes,b,x,ierr) >>>>>>>>>>> call PetscExceptionPop(PETSC_ERR_ARG_DOMAIN,anotherierr) >>>>>>>>>>> if (ierr == PETSC_ERR_ARG_DOMAIN) then >>>>>>>>>>> non-physical value so cut the time-step and try again >>>>>>>>>>> else ! everything is normal so take the next time-step >>>>>>>>>>> >>>>>>>>>>> Barry >>>>>>>>>>> >>>>>>>>>>> The Fortran interface may be missing PetscExceptionPush() and Pop() >>>>>>>>>>> if so let us know and we'll provide the patch. >>>>>>>>>>> >>>>>>>>>>> On Mon, 27 Feb 2006, Nils Erik Svang?rd wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi all, >>>>>>>>>>>> >>>>>>>>>>>> I have problems solving some CFD problems using SNES and my custom >>>>>>>>>>>> back-euler. I have 7 equations that I want to solve. >>>>>>>>>>>> >>>>>>>>>>>> First my FormFunction copies the values from the Vec that SNES uses to >>>>>>>>>>>> the variables that my code use: >>>>>>>>>>>> >>>>>>>>>>>> RO(L)=xx(1,L) >>>>>>>>>>>> RU(L)=xx(2,L) >>>>>>>>>>>> RV(L)=xx(3,L) >>>>>>>>>>>> RW(L)=xx(4,L) >>>>>>>>>>>> ET(L)=xx(5,L) >>>>>>>>>>>> RQ(L)= xx(6,L) >>>>>>>>>>>> REPS(L)=xx(7,L) >>>>>>>>>>>> >>>>>>>>>>>> Here I also print the values of ET(2) for debugging: >>>>>>>>>>>> >>>>>>>>>>>> write(6,*)"ET(2) = xx(5,2) : ",ET(2)," = ",xx(5,2) >>>>>>>>>>>> >>>>>>>>>>>> Then I get the fluxes by calling custom functions >>>>>>>>>>>> >>>>>>>>>>>> call AUXVR >>>>>>>>>>>> call VGRAD >>>>>>>>>>>> call FLUX >>>>>>>>>>>> call KESRC >>>>>>>>>>>> >>>>>>>>>>>> Then I perform back-euler save the new value to so that I can use it >>>>>>>>>>>> in the next iterationi (TSF(L) is Time step function, which is set by >>>>>>>>>>>> hand and is the same for all L): >>>>>>>>>>>> >>>>>>>>>>>> ff(1,L) = RO(L)-OLD(1,L)-TSF(L)*DRO(L) >>>>>>>>>>>> ff(2,L) = RU(L)-OLD(2,L)-TSF(L)*DRU(L) >>>>>>>>>>>> ff(3,L) = RV(L)-OLD(3,L)-TSF(L)*DRV(L) >>>>>>>>>>>> ff(4,L) = RW(L)-OLD(4,L)-TSF(L)*DRW(L) >>>>>>>>>>>> ff(5,L) = ET(L)-OLD(5,L)-TSF(L)*DET(L) >>>>>>>>>>>> ff(6,L) = RQ(L)-OLD(6,L)-TSF(L)*DRQ(L) >>>>>>>>>>>> ff(7,L) = REPS(L)-OLD(7,L)-TSF(L)*DREPS(L) >>>>>>>>>>>> >>>>>>>>>>>> And save the new value of RO-REPS to use in the next iteration of back-euler: >>>>>>>>>>>> >>>>>>>>>>>> OLD(1,L)=RO(L) >>>>>>>>>>>> OLD(2,L)=RU(L) >>>>>>>>>>>> OLD(3,L)=RV(L) >>>>>>>>>>>> OLD(4,L)=RW(L) >>>>>>>>>>>> OLD(5,L)=ET(L) >>>>>>>>>>>> OLD(6,L)=RQ(L) >>>>>>>>>>>> OLD(7,L)=REPS(L) >>>>>>>>>>>> >>>>>>>>>>>> Here I print the values of L=2 as above for debugging: >>>>>>>>>>>> >>>>>>>>>>>> write(6,*)ff(5,2)," = ",ET(2),"-",OLD(5,2),"-",TSF(2),"*",DET(2) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> The program exit abnormaly after 33 runs of the FormFunction. The >>>>>>>>>>>> cause of this is that AUXVR tries to perform sqrt(ET(2)) when ET(2) is >>>>>>>>>>>> negative, ET is the total energy and should never be negative. It >>>>>>>>>>>> seems that all of a sudden the PETSc SNES solver decides to supply the >>>>>>>>>>>> FormFunction with a negative ET value. I need help understanding why >>>>>>>>>>>> and how to fix it (if it is fixable). >>>>>>>>>>>> >>>>>>>>>>>> Here is the output of: >>>>>>>>>>>> write(6,*)"ET(2) = xx(5,2) : ",ET(2)," = ",xx(5,2) >>>>>>>>>>>> Which is in the beginning of my FormFunction. >>>>>>>>>>>> And: >>>>>>>>>>>> write(6,*)ff(5,2)," = ",ET(2),"-",OLD(5,2),"-",TSF(2),"*",DET(2) >>>>>>>>>>>> Which is in the end of my Formfunction. >>>>>>>>>>>> >>>>>>>>>>>> 1. ET(2) = xx(5,2) : 253250. = 253250.000000000 >>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>>>>>>>>>>> 2. ET(2) = xx(5,2) : 253250. = 253250.000010259 >>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>>>>>>>>>>> 3. ET(2) = xx(5,2) : 253250. = 253249.999999988 >>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4132419437260 = >>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941324E+08 >>>>>>>>>>>> 4. ET(2) = xx(5,2) : 253250. = 253250.000048432 >>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>>>>>>>>>>> 5. ET(2) = xx(5,2) : 253250. = 253249.999999872 >>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4177283437784 = >>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941773E+08 >>>>>>>>>>>> 6. ET(2) = xx(5,2) : 253250. = 253250.000071113 >>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>>>>>>>>>>> 7. ET(2) = xx(5,2) : 253250. = 253249.999980115 >>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4453347441010 = >>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.944533E+08 >>>>>>>>>>>> 8. ET(2) = xx(5,2) : 253250. = 253250.000037298 >>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4082723436679 = >>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940827E+08 >>>>>>>>>>>> 9. ET(2) = xx(5,2) : 253250. = 253249.999942706 >>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4082723436679 = >>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940827E+08 >>>>>>>>>>>> 10. ET(2) = xx(5,2) : 253250. = 253249.999948703 >>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>>>>>>>>>>> 11. ET(2) = xx(5,2) : 253250. = 253250.000007808 >>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.7283811474088 = >>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.972838E+08 >>>>>>>>>>>> 12. ET(2) = xx(5,2) : 253250. = 253250.000018146 >>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>>>>>>>>>>> 13. ET(2) = xx(5,2) : 253250. = 253250.000001865 >>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 28.3742819315846 = >>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.837428E+08 >>>>>>>>>>>> 14. ET(2) = xx(5,2) : 253250. = 253249.999997296 >>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>>>>>>>>>>> 15. ET(2) = xx(5,2) : 253250. = 253250.000000049 >>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 30.6548963582361 = >>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -3.065490E+08 >>>>>>>>>>>> 16. ET(2) = xx(5,2) : 253250. = 253250.000022870 >>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>>>>>>>>>>> 17. ET(2) = xx(5,2) : 253250. = 253249.999999716 >>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.5326051451209 = >>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.953260E+08 >>>>>>>>>>>> 18. ET(2) = xx(5,2) : 253250. = 253250.000074328 >>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4165187437643 = >>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941652E+08 >>>>>>>>>>>> 19. ET(2) = xx(5,2) : 253250. = 253250.000049809 >>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4085059436707 = >>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940851E+08 >>>>>>>>>>>> 20. ET(2) = xx(5,2) : 253250. = 253250.000019253 >>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>>>>>>>>>>> 21. ET(2) = xx(5,2) : 253250. = 253250.000000189 >>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.8851075492403 = >>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.988511E+08 >>>>>>>>>>>> 22. ET(2) = xx(5,2) : 253250. = 253249.999997897 >>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4085059436707 = >>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940851E+08 >>>>>>>>>>>> 23. ET(2) = xx(5,2) : 253250. = 253249.999975142 >>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.3961539435263 = >>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.939615E+08 >>>>>>>>>>>> 24. ET(2) = xx(5,2) : 253250. = 253250.000018324 >>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4085059436707 = >>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940851E+08 >>>>>>>>>>>> 25. ET(2) = xx(5,2) : 253250. = 253249.999987073 >>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4165187437643 = >>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941652E+08 >>>>>>>>>>>> 26. ET(2) = xx(5,2) : 253250. = 253249.999980982 >>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4165187437643 = >>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941652E+08 >>>>>>>>>>>> 27. ET(2) = xx(5,2) : 253250. = 253249.999994645 >>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>>>>>>>>>>> 28. ET(2) = xx(5,2) : 253250. = 253249.999962364 >>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4165187437643 = >>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941652E+08 >>>>>>>>>>>> 29. ET(2) = xx(5,2) : 253250. = 253249.999999921 >>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>>>>>>>>>>> 30. ET(2) = xx(5,2) : 253250. = 253250.000000058 >>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 28.4019971319085 = >>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.840200E+08 >>>>>>>>>>>> 31. ET(2) = xx(5,2) : 253250. = 253250.000040348 >>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4085059436707 = >>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940851E+08 >>>>>>>>>>>> 32. ET(2) = xx(5,2) : 253250. = 253250.000005245 >>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>>>>>>>>>>> 33. ET(2) = xx(5,2) : 253250. = 253250.000005245 >>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>>>>>>>>>>> 34. ET(2) = xx(5,2) : -848141. = -848141.388090847 >>>>>>>>>>>> -------------------------------------------------------------------------- >>>>>>>>>>>> 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. >>>>>>>>>>>> ----------------------------------------------------------------------- >>>>>>>>>>>> ./SNESG3D2 on a linux-gnu named sethnx004.vac.com by yy26539 Mon Feb >>>>>>>>>>>> 27 14:21:13 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] SNES user function line 0 unknownunknown >>>>>>>>>>>> [0]PETSC ERROR: [0] SNESComputeFunction line 788 src/snes/interface/snes.c >>>>>>>>>>>> [0]PETSC ERROR: [0] SNESLineSearchCubic line 514 src/snes/impls/ls/ls.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: ! >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Suggestions and tips are very welcome! >>>>>>>>>>>> /nisse >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Nils-Erik Svang???rd >>>>>>>>>>>> MSN: schweingaard at hotmail.com >>>>>>>>>>>> Skype: schweingaard >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Nils-Erik Svang?rd >>>>>>>>>> MSN: schweingaard at hotmail.com >>>>>>>>>> Skype: schweingaard >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> 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 > > From nilserik at gmail.com Tue Mar 14 23:40:43 2006 From: nilserik at gmail.com (=?ISO-8859-1?Q?Nils_Erik_Svang=E5rd?=) Date: Wed, 15 Mar 2006 06:40:43 +0100 Subject: SNES Problem In-Reply-To: References: <82f936c20602270607t775d7e03o6a37afa4c0b3d2a8@mail.gmail.com> <82f936c20603030047m5f64406n1435ca60f306fa98@mail.gmail.com> <82f936c20603030158u33722ff0q3c50839df14841@mail.gmail.com> <82f936c20603140727k208100f8vcb8f5672f9e9284e@mail.gmail.com> <82f936c20603141202p77439573hf249e43c53ae4d45@mail.gmail.com> <82f936c20603141237q2989c5a1i996ccf4815ed7f45@mail.gmail.com> Message-ID: <82f936c20603142140o768183f7id7b6e210bc7d9b1@mail.gmail.com> > > Just get a copy of rk.c and link it in with your code; you don't have > to muck with the actual file that goes into the PETSc library. > Ok. > > In the back-euler implementation, I think I just have to add one line > > to get the stability checking of the timestep working. > > If it is one line for backward Euler, why isn't one line for RK? > You can simply call the code in fortran that computes the time-step, > can't you then use MPI_Allreduce to get the min over all processors. It is one line to add in the SNES implementation because there I set timestep for each iteration. The RK is used via TS which manage the timestep, and I am not sure how to manage the timestep myself in when using TS, > > Here is the issue: the ONLY reason to use an implicit method is to > increase the timestep which you cannot do with the explicit code due > to stability constraints. But if you use the same time-step with the > implicit code as with the explicit code you gain nothing over using > the explicit code (in fact you do worse because the implicit code > is more expensive per timestep). So using the old timestep control function might make the code to work but probably will reach the solution much slower. So if this work, I probably have to rewrite the stability check to fit the implicit timestepping? /nisse > > > Barry > > > > > /nisse > >> Barry > >> > >> > >> > >> On Tue, 14 Mar 2006, Nils Erik Svang?rd wrote: > >> > >>>>> Yes, there is a difference between the old 3-stage RK-solver and the > >>>>> SNESsolver using RK. In the old a timestep was calculatade for each > >>>> ^^^^^^^^^^^^^^^ > >>>> Are you using PETSc's explicit RK? If so that does not use SNES. > >>>> > >>> > >>> Sorry, I meant TS. > >>> > >>>>> cell based on a stability criteria and if chosen it could run in > >>>>> time-accurate mode eg. the timestep is the same for each cell, in SNES > >>>> ^^^^^^^^^ > >>>> Do you mean for backward Euler for the explicit RK? Or both? > >>> > >>> Sorry again, using TS I use the same size of the timestep on every > >>> cell (both when trying use back-euler and RK). > >>> In my old 3-stage RK I can use both variable timestep and > >>> time-accurate timestep. > >>> In my seperate back-euler implementation using SNES I use the same > >>> timestep on every cell. > >>> > >>>> > >>>>> I use a timestep that is the same for all cells and > >>>>> changes only if it returns non-physical answers or the solution diverges. > >>>> > >>>> I think you need to put the "proper" computation of the time-step > >>>> based on the stability criteria that you have in the "old" code. > >>>> Unfortunately this is currently hardwired in src/ts/impls/explicit/rk/rk.c > >>>> (search for "Computing next stepsize"). I think you need to use the minimum > >>>> of the timestep computed here and what is needed for the "stability criteria". > >>>> > >>> Hmm.. Ok so I could use my back-euler SNES implementation with my old > >>> timestep calculation function (using time-accurate timestep)? And it > >>> might work better. > >>> > >>> > >>> Thanks > >>> /nisse > >>> > >>>>> > >>>>> Another interesting observation is that when using back euler at the > >>>>> moment when it bugs out petsc has assigned neigboring cells pressure > >>>>> values that differs about 1 ATM, which is a very non physical value, > >>>> > >>>> Likely some stability problem. > >>>> > >>>> Barry > >>>> > >>>>> but I have no clue as to why petsc want such a value in thesolution. > >>>>> > >>>>> /nisse > >>>>> > >>>>> On 3/3/06, Barry Smith wrote: > >>>>>> > >>>>>> There must be a difference between the two RKs. The initial > >>>>>> timestep it uses, or algorithm for changing time step or slight > >>>>>> difference in algorithms? > >>>>>> > >>>>>> Barry > >>>>>> > >>>>>> On Fri, 3 Mar 2006, Nils Erik Svang?rd wrote: > >>>>>> > >>>>>>> A interesting thing is when I change TS_BEULER to TS_RUNGE_KUTTA the > >>>>>>> solver exits fast due to the non physical values. My original solver > >>>>>>> is a 3-step Runge-Kutta which works flawlessly. > >>>>>>> > >>>>>>> The error when running RK: > >>>>>>> > >>>>>>> ./ImplicitG3D on a linux-gnu named sethnx004.vac.com by yy26539 Fri > >>>>>>> Mar 3 10:31:27 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] TS user right-hand-side function line 0 unknownunknown > >>>>>>> [0]PETSC ERROR: [0] TSComputeRHSFunction line 282 src/ts/interface/ts.c > >>>>>>> [0]PETSC ERROR: [0] TSRkqs line 256 src/ts/impls/explicit/rk/rk.c > >>>>>>> [0]PETSC ERROR: [0] TSStep_Rk line 322 src/ts/impls/explicit/rk/rk.c > >>>>>>> [0]PETSC ERROR: [0] TSStep line 1520 src/ts/interface/ts.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 > >>>>>>> > >>>>>>> On 3/3/06, Nils Erik Svang?rd wrote: > >>>>>>>> Hello again, > >>>>>>>> > >>>>>>>>> Is it just not compiling because PETSC_ERR_ARG_DOMAIN is not > >>>>>>>>> defined? Or does it still not work even when you have put the number in? > >>>>>>>>> What is the error? Or did you get it all working with SNES? > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> It is not compiling because PETSC_ERR_ARG_DOMAIN is not defined: > >>>>>>>> > >>>>>>>> error on line 585 of SNESG3D2.F: data type is undefined for variable > >>>>>>>> PETSC_ERR_ARG_DOMAIN > >>>>>>>> > >>>>>>>> I tried putting a number in, then it compiles but complains while > >>>>>>>> linking that the Push() and Pop() functions is not defined. I made a > >>>>>>>> workaround by adding a variable in a common block and setting it > >>>>>>>> before returning from a non physical value in the FormFunction. Now I > >>>>>>>> can compile and when there is a non-physical value it returns and > >>>>>>>> resumes with a smaller timestep. > >>>>>>>> SNES still give non physical values which are hard to add checks for > >>>>>>>> in the program (e.g sqrt(RO(L)-RO(L+1))). > >>>>>>>> > >>>>>>>> Did I understand correctly that SNES does a linesearch and probably > >>>>>>>> goes for a solution which isnt the one I looking for? Does SNES use > >>>>>>>> the linesearch algorithm when I use -snes_mf (which I use)? > >>>>>>>> > >>>>>>>>> It may work automatically with TS; you would just set TS with a > >>>>>>>>> smaller timestep and call TSSolve again? > >>>>>>>>> > >>>>>>>> > >>>>>>>> OK, I'll add a check and put TSSolve in a while loop. > >>>>>>>> > >>>>>>>> My SNESSolve loop looks like this right now: > >>>>>>>> call VecCreateSeq(PETSC_COMM_SELF,N,x,ierr) > >>>>>>>> call VecDuplicate(x,r,ierr) > >>>>>>>> call VecDuplicate(x,xb,ierr) > >>>>>>>> call SNESCreate(PETSC_COMM_SELF,snes,ierr) > >>>>>>>> call SNESSetFunction(snes,r,FormFunction,PETSC_NULL_OBJECT,ierr) > >>>>>>>> call SNESSetFromOptions(snes,ierr) > >>>>>>>> call FormInitialGuess(x,ierr) > >>>>>>>> call VecCopy(x,xb,ierr) > >>>>>>>> write(6,*)zero,dt,tmax,i1000 > >>>>>>>> step=0 > >>>>>>>> timestep=dt > >>>>>>>> bang=0 > >>>>>>>> C While loop > >>>>>>>> 10 if (step .le. 100) then > >>>>>>>> C call PetscExceptionPush(87,ierr) > >>>>>>>> C call PetscExceptionPush(PETSC_ERR_ARG_DOMAIN,ierr) > >>>>>>>> call SNESSolve(snes,PETSC_NULL_OBJECT,x,ierr) > >>>>>>>> ierr=bang > >>>>>>>> C call PetscExceptionPop(87,ierr2) > >>>>>>>> IF ( ierr .EQ. 87) THEN > >>>>>>>> timestep=timestep/2 > >>>>>>>> call VecCopy(xb,x,ierr) > >>>>>>>> write(6,*) "No physical solution, trying", > >>>>>>>> . " with smaller timestep: ",timestep > >>>>>>>> bang=0 > >>>>>>>> ELSE > >>>>>>>> call SNESGetConvergedReason(snes,reason,ierr) > >>>>>>>> IF ( reason .LT. 0 ) THEN > >>>>>>>> timestep=timestep/2 > >>>>>>>> call VecCopy(xb,x,ierr) > >>>>>>>> write(6,*)"Solution diverged, trying with", > >>>>>>>> . " smaller timestep: ",timestep > >>>>>>>> ELSE > >>>>>>>> timestep=dt > >>>>>>>> step=step+1 > >>>>>>>> call VecCopy(x,xb,ierr) > >>>>>>>> write(6,*) "Solve success, going for step: ",step > >>>>>>>> write(6,*) "Reason: ",reason," ierr: ",ierr > >>>>>>>> reason=0 > >>>>>>>> ierr=0 > >>>>>>>> ENDIF > >>>>>>>> ENDIF > >>>>>>>> goto 10 > >>>>>>>> endif > >>>>>>>> C End While loop > >>>>>>>> > >>>>>>>> And the check in the FormFunction: > >>>>>>>> > >>>>>>>> if (ET(L) .LT. 0) then > >>>>>>>> ierr = 87 > >>>>>>>> bang = 87 > >>>>>>>> C SETERRQ(87,"Non physical value!",ierr) > >>>>>>>> return > >>>>>>>> elseif ( RO(L) .LT. 0 ) then > >>>>>>>> ierr = 87 > >>>>>>>> bang = 87 > >>>>>>>> return > >>>>>>>> endif > >>>>>>>> > >>>>>>>> > >>>>>>>> /nisse > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> Barry > >>>>>>>>> > >>>>>>>>> I'm adding a petscerror.h for Fortran that includes these values > >>>>>>>>> Sorry I forgot we hadn't given them for Fortran. > >>>>>>>>> > >>>>>>>>> On Thu, 2 Mar 2006, Nils Erik Svang?rd wrote: > >>>>>>>>> > >>>>>>>>>> Hi again, > >>>>>>>>>> I realised that my implementation was a bit flawed so I have rewritten > >>>>>>>>>> it again, the push and pop() functions dont seem to work, and they are > >>>>>>>>>> keeping me from compiling the program, this is the main timestep loop: > >>>>>>>>>> > >>>>>>>>>> call VecCreateSeq(PETSC_COMM_SELF,N,x,ierr) > >>>>>>>>>> call VecDuplicate(x,r,ierr) > >>>>>>>>>> call VecDuplicate(x,xb,ierr) > >>>>>>>>>> call SNESCreate(PETSC_COMM_SELF,snes,ierr) > >>>>>>>>>> call SNESSetFunction(snes,r,FormFunction,PETSC_NULL_OBJECT,ierr) > >>>>>>>>>> call SNESSetFromOptions(snes,ierr) > >>>>>>>>>> call FormInitialGuess(x,ierr) > >>>>>>>>>> call VecCopy(x,xb,ierr) > >>>>>>>>>> write(6,*)zero,dt,tmax,i1000 > >>>>>>>>>> step=0 > >>>>>>>>>> timestep=dt > >>>>>>>>>> C While loop > >>>>>>>>>> 10 if (step .le. 100) then > >>>>>>>>>> call PetscExceptionPush(87,ierr) > >>>>>>>>>> call SNESSolve(snes,PETSC_NULL_OBJECT,x,ierr) > >>>>>>>>>> call PetscExceptionPop(87,ierr2) > >>>>>>>>>> > >>>>>>>>>> call SNESGetConvergedReason(snes,reason,ierr) > >>>>>>>>>> IF ( reason .LT. 0 ) THEN > >>>>>>>>>> timestep=timestep/2 > >>>>>>>>>> VecCopy(xb,x,ierr) > >>>>>>>>>> write(6,*)"Solution diverged, trying with", > >>>>>>>>>> . " smaller timestep: ",timestep > >>>>>>>>>> ELSE > >>>>>>>>>> IF ( ierr .EQ. 87) THEN > >>>>>>>>>> timestep=timestep/2 > >>>>>>>>>> VecCopy(xb,x,ierr) > >>>>>>>>>> write(6,*) "No physical solution, trying", > >>>>>>>>>> . " with smaller timestep: ",timestep > >>>>>>>>>> ELSE > >>>>>>>>>> timestep=dt > >>>>>>>>>> step=step+1 > >>>>>>>>>> VecCopy(x,xb,ierr) > >>>>>>>>>> write(6,*) "Solve success, going for step: ",step > >>>>>>>>>> ENDIF > >>>>>>>>>> ENDIF > >>>>>>>>>> goto 10 > >>>>>>>>>> endif > >>>>>>>>>> C End While loop > >>>>>>>>>> > >>>>>>>>>> And in my Formfunction I have added the following check: > >>>>>>>>>> if (ET(L) .LT. 0) then > >>>>>>>>>> ierr = 87 > >>>>>>>>>> return > >>>>>>>>>> endif > >>>>>>>>>> > >>>>>>>>>> PETSC_ERR_ARG_DOMAIN didnt work: error on line 6500 of SNESG3D2.F: > >>>>>>>>>> data type is undefined for variable PETSC_ERR_ARG_DOMAIN > >>>>>>>>>> Even thought I had petsc.h included. > >>>>>>>>>> > >>>>>>>>>> Can I do this check when I use TS also? I have the sameproblem with > >>>>>>>>>> the values being negative when using TS. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> /nisse > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> On 2/27/06, Barry Smith wrote: > >>>>>>>>>>> > >>>>>>>>>>> SNES works by computing p = -approxinv(J)*F(uold) and > >>>>>>>>>>> then does a line search on unew = uold + lambda*p to get the > >>>>>>>>>>> new u. First it uses a test value of 1 for lambda so it > >>>>>>>>>>> tries to compute F(uold + p). It is possible that uold + p > >>>>>>>>>>> has some "non-physical" values in it. There are two ways > >>>>>>>>>>> you can try handling it: > >>>>>>>>>>> > >>>>>>>>>>> 1) Before doing the linesearch SNES calls a "precheck" function, > >>>>>>>>>>> that can change the step if it decides there is a problem > >>>>>>>>>>> with the step (like it is too long). You can provide your > >>>>>>>>>>> own precheck function with SNESLineSearchSetPreCheck() it could, > >>>>>>>>>>> for example, shrink the Newton direction to make it remain physical. > >>>>>>>>>>> > >>>>>>>>>>> or 2) when your form function detects an illegal value it calls > >>>>>>>>>>> SETERRQ(PETSC_ERR_ARG_DOMAIN,"Nonphysical function input"); Note: > >>>>>>>>>>> this is before it takes the square root of the negative number, > >>>>>>>>>>> so check the number and call the error before calling SETERRQ(). > >>>>>>>>>>> (If using Fortran then simply set ierr = PETSC_ERR_ARG_DOMAIN and > >>>>>>>>>>> then immediately return). Then replace your call to SNESSolve with > >>>>>>>>>>> ierr = PetscExceptionTry1(SNESSolve(snes,b,x),PETSC_ERR_ARG_DOMAIN); > >>>>>>>>>>> if (PetscExceptionCaught(ierr,PETSC_ERR_ARG_DOMAIN)) { > >>>>>>>>>>> /* this means your function found a non-physical value so > >>>>>>>>>>> cut your time-step and continue through the loop again. */ > >>>>>>>>>>> Put code to do this here. > >>>>>>>>>>> } > >>>>>>>>>>> If using fortran then do > >>>>>>>>>>> call PetscExceptionPush(PETSC_ERR_ARG_DOMAIN,ierr) > >>>>>>>>>>> call SNESSolve(snes,b,x,ierr) > >>>>>>>>>>> call PetscExceptionPop(PETSC_ERR_ARG_DOMAIN,anotherierr) > >>>>>>>>>>> if (ierr == PETSC_ERR_ARG_DOMAIN) then > >>>>>>>>>>> non-physical value so cut the time-step and try again > >>>>>>>>>>> else ! everything is normal so take the next time-step > >>>>>>>>>>> > >>>>>>>>>>> Barry > >>>>>>>>>>> > >>>>>>>>>>> The Fortran interface may be missing PetscExceptionPush() and Pop() > >>>>>>>>>>> if so let us know and we'll provide the patch. > >>>>>>>>>>> > >>>>>>>>>>> On Mon, 27 Feb 2006, Nils Erik Svang?rd wrote: > >>>>>>>>>>> > >>>>>>>>>>>> Hi all, > >>>>>>>>>>>> > >>>>>>>>>>>> I have problems solving some CFD problems using SNES and my custom > >>>>>>>>>>>> back-euler. I have 7 equations that I want to solve. > >>>>>>>>>>>> > >>>>>>>>>>>> First my FormFunction copies the values from the Vec that SNES uses to > >>>>>>>>>>>> the variables that my code use: > >>>>>>>>>>>> > >>>>>>>>>>>> RO(L)=xx(1,L) > >>>>>>>>>>>> RU(L)=xx(2,L) > >>>>>>>>>>>> RV(L)=xx(3,L) > >>>>>>>>>>>> RW(L)=xx(4,L) > >>>>>>>>>>>> ET(L)=xx(5,L) > >>>>>>>>>>>> RQ(L)= xx(6,L) > >>>>>>>>>>>> REPS(L)=xx(7,L) > >>>>>>>>>>>> > >>>>>>>>>>>> Here I also print the values of ET(2) for debugging: > >>>>>>>>>>>> > >>>>>>>>>>>> write(6,*)"ET(2) = xx(5,2) : ",ET(2)," = ",xx(5,2) > >>>>>>>>>>>> > >>>>>>>>>>>> Then I get the fluxes by calling custom functions > >>>>>>>>>>>> > >>>>>>>>>>>> call AUXVR > >>>>>>>>>>>> call VGRAD > >>>>>>>>>>>> call FLUX > >>>>>>>>>>>> call KESRC > >>>>>>>>>>>> > >>>>>>>>>>>> Then I perform back-euler save the new value to so that I can use it > >>>>>>>>>>>> in the next iterationi (TSF(L) is Time step function, which is set by > >>>>>>>>>>>> hand and is the same for all L): > >>>>>>>>>>>> > >>>>>>>>>>>> ff(1,L) = RO(L)-OLD(1,L)-TSF(L)*DRO(L) > >>>>>>>>>>>> ff(2,L) = RU(L)-OLD(2,L)-TSF(L)*DRU(L) > >>>>>>>>>>>> ff(3,L) = RV(L)-OLD(3,L)-TSF(L)*DRV(L) > >>>>>>>>>>>> ff(4,L) = RW(L)-OLD(4,L)-TSF(L)*DRW(L) > >>>>>>>>>>>> ff(5,L) = ET(L)-OLD(5,L)-TSF(L)*DET(L) > >>>>>>>>>>>> ff(6,L) = RQ(L)-OLD(6,L)-TSF(L)*DRQ(L) > >>>>>>>>>>>> ff(7,L) = REPS(L)-OLD(7,L)-TSF(L)*DREPS(L) > >>>>>>>>>>>> > >>>>>>>>>>>> And save the new value of RO-REPS to use in the next iteration of back-euler: > >>>>>>>>>>>> > >>>>>>>>>>>> OLD(1,L)=RO(L) > >>>>>>>>>>>> OLD(2,L)=RU(L) > >>>>>>>>>>>> OLD(3,L)=RV(L) > >>>>>>>>>>>> OLD(4,L)=RW(L) > >>>>>>>>>>>> OLD(5,L)=ET(L) > >>>>>>>>>>>> OLD(6,L)=RQ(L) > >>>>>>>>>>>> OLD(7,L)=REPS(L) > >>>>>>>>>>>> > >>>>>>>>>>>> Here I print the values of L=2 as above for debugging: > >>>>>>>>>>>> > >>>>>>>>>>>> write(6,*)ff(5,2)," = ",ET(2),"-",OLD(5,2),"-",TSF(2),"*",DET(2) > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> The program exit abnormaly after 33 runs of the FormFunction. The > >>>>>>>>>>>> cause of this is that AUXVR tries to perform sqrt(ET(2)) when ET(2) is > >>>>>>>>>>>> negative, ET is the total energy and should never be negative. It > >>>>>>>>>>>> seems that all of a sudden the PETSc SNES solver decides to supply the > >>>>>>>>>>>> FormFunction with a negative ET value. I need help understanding why > >>>>>>>>>>>> and how to fix it (if it is fixable). > >>>>>>>>>>>> > >>>>>>>>>>>> Here is the output of: > >>>>>>>>>>>> write(6,*)"ET(2) = xx(5,2) : ",ET(2)," = ",xx(5,2) > >>>>>>>>>>>> Which is in the beginning of my FormFunction. > >>>>>>>>>>>> And: > >>>>>>>>>>>> write(6,*)ff(5,2)," = ",ET(2),"-",OLD(5,2),"-",TSF(2),"*",DET(2) > >>>>>>>>>>>> Which is in the end of my Formfunction. > >>>>>>>>>>>> > >>>>>>>>>>>> 1. ET(2) = xx(5,2) : 253250. = 253250.000000000 > >>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > >>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > >>>>>>>>>>>> 2. ET(2) = xx(5,2) : 253250. = 253250.000010259 > >>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > >>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > >>>>>>>>>>>> 3. ET(2) = xx(5,2) : 253250. = 253249.999999988 > >>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4132419437260 = > >>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941324E+08 > >>>>>>>>>>>> 4. ET(2) = xx(5,2) : 253250. = 253250.000048432 > >>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > >>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > >>>>>>>>>>>> 5. ET(2) = xx(5,2) : 253250. = 253249.999999872 > >>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4177283437784 = > >>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941773E+08 > >>>>>>>>>>>> 6. ET(2) = xx(5,2) : 253250. = 253250.000071113 > >>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > >>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > >>>>>>>>>>>> 7. ET(2) = xx(5,2) : 253250. = 253249.999980115 > >>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4453347441010 = > >>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.944533E+08 > >>>>>>>>>>>> 8. ET(2) = xx(5,2) : 253250. = 253250.000037298 > >>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4082723436679 = > >>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940827E+08 > >>>>>>>>>>>> 9. ET(2) = xx(5,2) : 253250. = 253249.999942706 > >>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4082723436679 = > >>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940827E+08 > >>>>>>>>>>>> 10. ET(2) = xx(5,2) : 253250. = 253249.999948703 > >>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > >>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > >>>>>>>>>>>> 11. ET(2) = xx(5,2) : 253250. = 253250.000007808 > >>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.7283811474088 = > >>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.972838E+08 > >>>>>>>>>>>> 12. ET(2) = xx(5,2) : 253250. = 253250.000018146 > >>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > >>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > >>>>>>>>>>>> 13. ET(2) = xx(5,2) : 253250. = 253250.000001865 > >>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 28.3742819315846 = > >>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.837428E+08 > >>>>>>>>>>>> 14. ET(2) = xx(5,2) : 253250. = 253249.999997296 > >>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > >>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > >>>>>>>>>>>> 15. ET(2) = xx(5,2) : 253250. = 253250.000000049 > >>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 30.6548963582361 = > >>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -3.065490E+08 > >>>>>>>>>>>> 16. ET(2) = xx(5,2) : 253250. = 253250.000022870 > >>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > >>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > >>>>>>>>>>>> 17. ET(2) = xx(5,2) : 253250. = 253249.999999716 > >>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.5326051451209 = > >>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.953260E+08 > >>>>>>>>>>>> 18. ET(2) = xx(5,2) : 253250. = 253250.000074328 > >>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4165187437643 = > >>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941652E+08 > >>>>>>>>>>>> 19. ET(2) = xx(5,2) : 253250. = 253250.000049809 > >>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4085059436707 = > >>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940851E+08 > >>>>>>>>>>>> 20. ET(2) = xx(5,2) : 253250. = 253250.000019253 > >>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > >>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > >>>>>>>>>>>> 21. ET(2) = xx(5,2) : 253250. = 253250.000000189 > >>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.8851075492403 = > >>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.988511E+08 > >>>>>>>>>>>> 22. ET(2) = xx(5,2) : 253250. = 253249.999997897 > >>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4085059436707 = > >>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940851E+08 > >>>>>>>>>>>> 23. ET(2) = xx(5,2) : 253250. = 253249.999975142 > >>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.3961539435263 = > >>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.939615E+08 > >>>>>>>>>>>> 24. ET(2) = xx(5,2) : 253250. = 253250.000018324 > >>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4085059436707 = > >>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940851E+08 > >>>>>>>>>>>> 25. ET(2) = xx(5,2) : 253250. = 253249.999987073 > >>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4165187437643 = > >>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941652E+08 > >>>>>>>>>>>> 26. ET(2) = xx(5,2) : 253250. = 253249.999980982 > >>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4165187437643 = > >>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941652E+08 > >>>>>>>>>>>> 27. ET(2) = xx(5,2) : 253250. = 253249.999994645 > >>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > >>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > >>>>>>>>>>>> 28. ET(2) = xx(5,2) : 253250. = 253249.999962364 > >>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4165187437643 = > >>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941652E+08 > >>>>>>>>>>>> 29. ET(2) = xx(5,2) : 253250. = 253249.999999921 > >>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > >>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > >>>>>>>>>>>> 30. ET(2) = xx(5,2) : 253250. = 253250.000000058 > >>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 28.4019971319085 = > >>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.840200E+08 > >>>>>>>>>>>> 31. ET(2) = xx(5,2) : 253250. = 253250.000040348 > >>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4085059436707 = > >>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940851E+08 > >>>>>>>>>>>> 32. ET(2) = xx(5,2) : 253250. = 253250.000005245 > >>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > >>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > >>>>>>>>>>>> 33. ET(2) = xx(5,2) : 253250. = 253250.000005245 > >>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = > >>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 > >>>>>>>>>>>> 34. ET(2) = xx(5,2) : -848141. = -848141.388090847 > >>>>>>>>>>>> -------------------------------------------------------------------------- > >>>>>>>>>>>> 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. > >>>>>>>>>>>> ----------------------------------------------------------------------- > >>>>>>>>>>>> ./SNESG3D2 on a linux-gnu named sethnx004.vac.com by yy26539 Mon Feb > >>>>>>>>>>>> 27 14:21:13 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] SNES user function line 0 unknownunknown > >>>>>>>>>>>> [0]PETSC ERROR: [0] SNESComputeFunction line 788 src/snes/interface/snes.c > >>>>>>>>>>>> [0]PETSC ERROR: [0] SNESLineSearchCubic line 514 src/snes/impls/ls/ls.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: ! > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> Suggestions and tips are very welcome! > >>>>>>>>>>>> /nisse > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> -- > >>>>>>>>>>>> Nils-Erik Svang???rd > >>>>>>>>>>>> MSN: schweingaard at hotmail.com > >>>>>>>>>>>> Skype: schweingaard > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> -- > >>>>>>>>>> Nils-Erik Svang?rd > >>>>>>>>>> MSN: schweingaard at hotmail.com > >>>>>>>>>> Skype: schweingaard > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> -- > >>>>>>>> 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 From bsmith at mcs.anl.gov Wed Mar 15 07:14:25 2006 From: bsmith at mcs.anl.gov (Barry Smith) Date: Wed, 15 Mar 2006 07:14:25 -0600 (CST) Subject: SNES Problem In-Reply-To: <82f936c20603142140o768183f7id7b6e210bc7d9b1@mail.gmail.com> References: <82f936c20602270607t775d7e03o6a37afa4c0b3d2a8@mail.gmail.com> <82f936c20603030047m5f64406n1435ca60f306fa98@mail.gmail.com> <82f936c20603030158u33722ff0q3c50839df14841@mail.gmail.com> <82f936c20603140727k208100f8vcb8f5672f9e9284e@mail.gmail.com> <82f936c20603141202p77439573hf249e43c53ae4d45@mail.gmail.com> <82f936c20603141237q2989c5a1i996ccf4815ed7f45@mail.gmail.com> <82f936c20603142140o768183f7id7b6e210bc7d9b1@mail.gmail.com> Message-ID: On Wed, 15 Mar 2006, Nils Erik Svang?rd wrote: >> >> Just get a copy of rk.c and link it in with your code; you don't have >> to muck with the actual file that goes into the PETSc library. >> > > Ok. > >>> In the back-euler implementation, I think I just have to add one line >>> to get the stability checking of the timestep working. >> >> If it is one line for backward Euler, why isn't one line for RK? >> You can simply call the code in fortran that computes the time-step, >> can't you then use MPI_Allreduce to get the min over all processors. > > It is one line to add in the SNES implementation because there I set > timestep for each iteration. The RK is used via TS which manage the > timestep, and I am not sure how to manage the timestep myself in when > using TS, I see. Yes, it is a little harder since you have to edit rk.c but it is still pretty easy. > >> >> Here is the issue: the ONLY reason to use an implicit method is to >> increase the timestep which you cannot do with the explicit code due >> to stability constraints. But if you use the same time-step with the >> implicit code as with the explicit code you gain nothing over using >> the explicit code (in fact you do worse because the implicit code >> is more expensive per timestep). > > So using the old timestep control function might make the code to work > but probably will reach the solution much slower. So if this work, I > probably have to rewrite the stability check to fit the implicit > timestepping? Yes. Barry > > /nisse > >> >> >> Barry >> >>> >>> /nisse >>>> Barry >>>> >>>> >>>> >>>> On Tue, 14 Mar 2006, Nils Erik Svang?rd wrote: >>>> >>>>>>> Yes, there is a difference between the old 3-stage RK-solver and the >>>>>>> SNESsolver using RK. In the old a timestep was calculatade for each >>>>>> ^^^^^^^^^^^^^^^ >>>>>> Are you using PETSc's explicit RK? If so that does not use SNES. >>>>>> >>>>> >>>>> Sorry, I meant TS. >>>>> >>>>>>> cell based on a stability criteria and if chosen it could run in >>>>>>> time-accurate mode eg. the timestep is the same for each cell, in SNES >>>>>> ^^^^^^^^^ >>>>>> Do you mean for backward Euler for the explicit RK? Or both? >>>>> >>>>> Sorry again, using TS I use the same size of the timestep on every >>>>> cell (both when trying use back-euler and RK). >>>>> In my old 3-stage RK I can use both variable timestep and >>>>> time-accurate timestep. >>>>> In my seperate back-euler implementation using SNES I use the same >>>>> timestep on every cell. >>>>> >>>>>> >>>>>>> I use a timestep that is the same for all cells and >>>>>>> changes only if it returns non-physical answers or the solution diverges. >>>>>> >>>>>> I think you need to put the "proper" computation of the time-step >>>>>> based on the stability criteria that you have in the "old" code. >>>>>> Unfortunately this is currently hardwired in src/ts/impls/explicit/rk/rk.c >>>>>> (search for "Computing next stepsize"). I think you need to use the minimum >>>>>> of the timestep computed here and what is needed for the "stability criteria". >>>>>> >>>>> Hmm.. Ok so I could use my back-euler SNES implementation with my old >>>>> timestep calculation function (using time-accurate timestep)? And it >>>>> might work better. >>>>> >>>>> >>>>> Thanks >>>>> /nisse >>>>> >>>>>>> >>>>>>> Another interesting observation is that when using back euler at the >>>>>>> moment when it bugs out petsc has assigned neigboring cells pressure >>>>>>> values that differs about 1 ATM, which is a very non physical value, >>>>>> >>>>>> Likely some stability problem. >>>>>> >>>>>> Barry >>>>>> >>>>>>> but I have no clue as to why petsc want such a value in thesolution. >>>>>>> >>>>>>> /nisse >>>>>>> >>>>>>> On 3/3/06, Barry Smith wrote: >>>>>>>> >>>>>>>> There must be a difference between the two RKs. The initial >>>>>>>> timestep it uses, or algorithm for changing time step or slight >>>>>>>> difference in algorithms? >>>>>>>> >>>>>>>> Barry >>>>>>>> >>>>>>>> On Fri, 3 Mar 2006, Nils Erik Svang?rd wrote: >>>>>>>> >>>>>>>>> A interesting thing is when I change TS_BEULER to TS_RUNGE_KUTTA the >>>>>>>>> solver exits fast due to the non physical values. My original solver >>>>>>>>> is a 3-step Runge-Kutta which works flawlessly. >>>>>>>>> >>>>>>>>> The error when running RK: >>>>>>>>> >>>>>>>>> ./ImplicitG3D on a linux-gnu named sethnx004.vac.com by yy26539 Fri >>>>>>>>> Mar 3 10:31:27 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] TS user right-hand-side function line 0 unknownunknown >>>>>>>>> [0]PETSC ERROR: [0] TSComputeRHSFunction line 282 src/ts/interface/ts.c >>>>>>>>> [0]PETSC ERROR: [0] TSRkqs line 256 src/ts/impls/explicit/rk/rk.c >>>>>>>>> [0]PETSC ERROR: [0] TSStep_Rk line 322 src/ts/impls/explicit/rk/rk.c >>>>>>>>> [0]PETSC ERROR: [0] TSStep line 1520 src/ts/interface/ts.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 >>>>>>>>> >>>>>>>>> On 3/3/06, Nils Erik Svang?rd wrote: >>>>>>>>>> Hello again, >>>>>>>>>> >>>>>>>>>>> Is it just not compiling because PETSC_ERR_ARG_DOMAIN is not >>>>>>>>>>> defined? Or does it still not work even when you have put the number in? >>>>>>>>>>> What is the error? Or did you get it all working with SNES? >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> It is not compiling because PETSC_ERR_ARG_DOMAIN is not defined: >>>>>>>>>> >>>>>>>>>> error on line 585 of SNESG3D2.F: data type is undefined for variable >>>>>>>>>> PETSC_ERR_ARG_DOMAIN >>>>>>>>>> >>>>>>>>>> I tried putting a number in, then it compiles but complains while >>>>>>>>>> linking that the Push() and Pop() functions is not defined. I made a >>>>>>>>>> workaround by adding a variable in a common block and setting it >>>>>>>>>> before returning from a non physical value in the FormFunction. Now I >>>>>>>>>> can compile and when there is a non-physical value it returns and >>>>>>>>>> resumes with a smaller timestep. >>>>>>>>>> SNES still give non physical values which are hard to add checks for >>>>>>>>>> in the program (e.g sqrt(RO(L)-RO(L+1))). >>>>>>>>>> >>>>>>>>>> Did I understand correctly that SNES does a linesearch and probably >>>>>>>>>> goes for a solution which isnt the one I looking for? Does SNES use >>>>>>>>>> the linesearch algorithm when I use -snes_mf (which I use)? >>>>>>>>>> >>>>>>>>>>> It may work automatically with TS; you would just set TS with a >>>>>>>>>>> smaller timestep and call TSSolve again? >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> OK, I'll add a check and put TSSolve in a while loop. >>>>>>>>>> >>>>>>>>>> My SNESSolve loop looks like this right now: >>>>>>>>>> call VecCreateSeq(PETSC_COMM_SELF,N,x,ierr) >>>>>>>>>> call VecDuplicate(x,r,ierr) >>>>>>>>>> call VecDuplicate(x,xb,ierr) >>>>>>>>>> call SNESCreate(PETSC_COMM_SELF,snes,ierr) >>>>>>>>>> call SNESSetFunction(snes,r,FormFunction,PETSC_NULL_OBJECT,ierr) >>>>>>>>>> call SNESSetFromOptions(snes,ierr) >>>>>>>>>> call FormInitialGuess(x,ierr) >>>>>>>>>> call VecCopy(x,xb,ierr) >>>>>>>>>> write(6,*)zero,dt,tmax,i1000 >>>>>>>>>> step=0 >>>>>>>>>> timestep=dt >>>>>>>>>> bang=0 >>>>>>>>>> C While loop >>>>>>>>>> 10 if (step .le. 100) then >>>>>>>>>> C call PetscExceptionPush(87,ierr) >>>>>>>>>> C call PetscExceptionPush(PETSC_ERR_ARG_DOMAIN,ierr) >>>>>>>>>> call SNESSolve(snes,PETSC_NULL_OBJECT,x,ierr) >>>>>>>>>> ierr=bang >>>>>>>>>> C call PetscExceptionPop(87,ierr2) >>>>>>>>>> IF ( ierr .EQ. 87) THEN >>>>>>>>>> timestep=timestep/2 >>>>>>>>>> call VecCopy(xb,x,ierr) >>>>>>>>>> write(6,*) "No physical solution, trying", >>>>>>>>>> . " with smaller timestep: ",timestep >>>>>>>>>> bang=0 >>>>>>>>>> ELSE >>>>>>>>>> call SNESGetConvergedReason(snes,reason,ierr) >>>>>>>>>> IF ( reason .LT. 0 ) THEN >>>>>>>>>> timestep=timestep/2 >>>>>>>>>> call VecCopy(xb,x,ierr) >>>>>>>>>> write(6,*)"Solution diverged, trying with", >>>>>>>>>> . " smaller timestep: ",timestep >>>>>>>>>> ELSE >>>>>>>>>> timestep=dt >>>>>>>>>> step=step+1 >>>>>>>>>> call VecCopy(x,xb,ierr) >>>>>>>>>> write(6,*) "Solve success, going for step: ",step >>>>>>>>>> write(6,*) "Reason: ",reason," ierr: ",ierr >>>>>>>>>> reason=0 >>>>>>>>>> ierr=0 >>>>>>>>>> ENDIF >>>>>>>>>> ENDIF >>>>>>>>>> goto 10 >>>>>>>>>> endif >>>>>>>>>> C End While loop >>>>>>>>>> >>>>>>>>>> And the check in the FormFunction: >>>>>>>>>> >>>>>>>>>> if (ET(L) .LT. 0) then >>>>>>>>>> ierr = 87 >>>>>>>>>> bang = 87 >>>>>>>>>> C SETERRQ(87,"Non physical value!",ierr) >>>>>>>>>> return >>>>>>>>>> elseif ( RO(L) .LT. 0 ) then >>>>>>>>>> ierr = 87 >>>>>>>>>> bang = 87 >>>>>>>>>> return >>>>>>>>>> endif >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> /nisse >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Barry >>>>>>>>>>> >>>>>>>>>>> I'm adding a petscerror.h for Fortran that includes these values >>>>>>>>>>> Sorry I forgot we hadn't given them for Fortran. >>>>>>>>>>> >>>>>>>>>>> On Thu, 2 Mar 2006, Nils Erik Svang?rd wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi again, >>>>>>>>>>>> I realised that my implementation was a bit flawed so I have rewritten >>>>>>>>>>>> it again, the push and pop() functions dont seem to work, and they are >>>>>>>>>>>> keeping me from compiling the program, this is the main timestep loop: >>>>>>>>>>>> >>>>>>>>>>>> call VecCreateSeq(PETSC_COMM_SELF,N,x,ierr) >>>>>>>>>>>> call VecDuplicate(x,r,ierr) >>>>>>>>>>>> call VecDuplicate(x,xb,ierr) >>>>>>>>>>>> call SNESCreate(PETSC_COMM_SELF,snes,ierr) >>>>>>>>>>>> call SNESSetFunction(snes,r,FormFunction,PETSC_NULL_OBJECT,ierr) >>>>>>>>>>>> call SNESSetFromOptions(snes,ierr) >>>>>>>>>>>> call FormInitialGuess(x,ierr) >>>>>>>>>>>> call VecCopy(x,xb,ierr) >>>>>>>>>>>> write(6,*)zero,dt,tmax,i1000 >>>>>>>>>>>> step=0 >>>>>>>>>>>> timestep=dt >>>>>>>>>>>> C While loop >>>>>>>>>>>> 10 if (step .le. 100) then >>>>>>>>>>>> call PetscExceptionPush(87,ierr) >>>>>>>>>>>> call SNESSolve(snes,PETSC_NULL_OBJECT,x,ierr) >>>>>>>>>>>> call PetscExceptionPop(87,ierr2) >>>>>>>>>>>> >>>>>>>>>>>> call SNESGetConvergedReason(snes,reason,ierr) >>>>>>>>>>>> IF ( reason .LT. 0 ) THEN >>>>>>>>>>>> timestep=timestep/2 >>>>>>>>>>>> VecCopy(xb,x,ierr) >>>>>>>>>>>> write(6,*)"Solution diverged, trying with", >>>>>>>>>>>> . " smaller timestep: ",timestep >>>>>>>>>>>> ELSE >>>>>>>>>>>> IF ( ierr .EQ. 87) THEN >>>>>>>>>>>> timestep=timestep/2 >>>>>>>>>>>> VecCopy(xb,x,ierr) >>>>>>>>>>>> write(6,*) "No physical solution, trying", >>>>>>>>>>>> . " with smaller timestep: ",timestep >>>>>>>>>>>> ELSE >>>>>>>>>>>> timestep=dt >>>>>>>>>>>> step=step+1 >>>>>>>>>>>> VecCopy(x,xb,ierr) >>>>>>>>>>>> write(6,*) "Solve success, going for step: ",step >>>>>>>>>>>> ENDIF >>>>>>>>>>>> ENDIF >>>>>>>>>>>> goto 10 >>>>>>>>>>>> endif >>>>>>>>>>>> C End While loop >>>>>>>>>>>> >>>>>>>>>>>> And in my Formfunction I have added the following check: >>>>>>>>>>>> if (ET(L) .LT. 0) then >>>>>>>>>>>> ierr = 87 >>>>>>>>>>>> return >>>>>>>>>>>> endif >>>>>>>>>>>> >>>>>>>>>>>> PETSC_ERR_ARG_DOMAIN didnt work: error on line 6500 of SNESG3D2.F: >>>>>>>>>>>> data type is undefined for variable PETSC_ERR_ARG_DOMAIN >>>>>>>>>>>> Even thought I had petsc.h included. >>>>>>>>>>>> >>>>>>>>>>>> Can I do this check when I use TS also? I have the sameproblem with >>>>>>>>>>>> the values being negative when using TS. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> /nisse >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 2/27/06, Barry Smith wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> SNES works by computing p = -approxinv(J)*F(uold) and >>>>>>>>>>>>> then does a line search on unew = uold + lambda*p to get the >>>>>>>>>>>>> new u. First it uses a test value of 1 for lambda so it >>>>>>>>>>>>> tries to compute F(uold + p). It is possible that uold + p >>>>>>>>>>>>> has some "non-physical" values in it. There are two ways >>>>>>>>>>>>> you can try handling it: >>>>>>>>>>>>> >>>>>>>>>>>>> 1) Before doing the linesearch SNES calls a "precheck" function, >>>>>>>>>>>>> that can change the step if it decides there is a problem >>>>>>>>>>>>> with the step (like it is too long). You can provide your >>>>>>>>>>>>> own precheck function with SNESLineSearchSetPreCheck() it could, >>>>>>>>>>>>> for example, shrink the Newton direction to make it remain physical. >>>>>>>>>>>>> >>>>>>>>>>>>> or 2) when your form function detects an illegal value it calls >>>>>>>>>>>>> SETERRQ(PETSC_ERR_ARG_DOMAIN,"Nonphysical function input"); Note: >>>>>>>>>>>>> this is before it takes the square root of the negative number, >>>>>>>>>>>>> so check the number and call the error before calling SETERRQ(). >>>>>>>>>>>>> (If using Fortran then simply set ierr = PETSC_ERR_ARG_DOMAIN and >>>>>>>>>>>>> then immediately return). Then replace your call to SNESSolve with >>>>>>>>>>>>> ierr = PetscExceptionTry1(SNESSolve(snes,b,x),PETSC_ERR_ARG_DOMAIN); >>>>>>>>>>>>> if (PetscExceptionCaught(ierr,PETSC_ERR_ARG_DOMAIN)) { >>>>>>>>>>>>> /* this means your function found a non-physical value so >>>>>>>>>>>>> cut your time-step and continue through the loop again. */ >>>>>>>>>>>>> Put code to do this here. >>>>>>>>>>>>> } >>>>>>>>>>>>> If using fortran then do >>>>>>>>>>>>> call PetscExceptionPush(PETSC_ERR_ARG_DOMAIN,ierr) >>>>>>>>>>>>> call SNESSolve(snes,b,x,ierr) >>>>>>>>>>>>> call PetscExceptionPop(PETSC_ERR_ARG_DOMAIN,anotherierr) >>>>>>>>>>>>> if (ierr == PETSC_ERR_ARG_DOMAIN) then >>>>>>>>>>>>> non-physical value so cut the time-step and try again >>>>>>>>>>>>> else ! everything is normal so take the next time-step >>>>>>>>>>>>> >>>>>>>>>>>>> Barry >>>>>>>>>>>>> >>>>>>>>>>>>> The Fortran interface may be missing PetscExceptionPush() and Pop() >>>>>>>>>>>>> if so let us know and we'll provide the patch. >>>>>>>>>>>>> >>>>>>>>>>>>> On Mon, 27 Feb 2006, Nils Erik Svang?rd wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I have problems solving some CFD problems using SNES and my custom >>>>>>>>>>>>>> back-euler. I have 7 equations that I want to solve. >>>>>>>>>>>>>> >>>>>>>>>>>>>> First my FormFunction copies the values from the Vec that SNES uses to >>>>>>>>>>>>>> the variables that my code use: >>>>>>>>>>>>>> >>>>>>>>>>>>>> RO(L)=xx(1,L) >>>>>>>>>>>>>> RU(L)=xx(2,L) >>>>>>>>>>>>>> RV(L)=xx(3,L) >>>>>>>>>>>>>> RW(L)=xx(4,L) >>>>>>>>>>>>>> ET(L)=xx(5,L) >>>>>>>>>>>>>> RQ(L)= xx(6,L) >>>>>>>>>>>>>> REPS(L)=xx(7,L) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Here I also print the values of ET(2) for debugging: >>>>>>>>>>>>>> >>>>>>>>>>>>>> write(6,*)"ET(2) = xx(5,2) : ",ET(2)," = ",xx(5,2) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Then I get the fluxes by calling custom functions >>>>>>>>>>>>>> >>>>>>>>>>>>>> call AUXVR >>>>>>>>>>>>>> call VGRAD >>>>>>>>>>>>>> call FLUX >>>>>>>>>>>>>> call KESRC >>>>>>>>>>>>>> >>>>>>>>>>>>>> Then I perform back-euler save the new value to so that I can use it >>>>>>>>>>>>>> in the next iterationi (TSF(L) is Time step function, which is set by >>>>>>>>>>>>>> hand and is the same for all L): >>>>>>>>>>>>>> >>>>>>>>>>>>>> ff(1,L) = RO(L)-OLD(1,L)-TSF(L)*DRO(L) >>>>>>>>>>>>>> ff(2,L) = RU(L)-OLD(2,L)-TSF(L)*DRU(L) >>>>>>>>>>>>>> ff(3,L) = RV(L)-OLD(3,L)-TSF(L)*DRV(L) >>>>>>>>>>>>>> ff(4,L) = RW(L)-OLD(4,L)-TSF(L)*DRW(L) >>>>>>>>>>>>>> ff(5,L) = ET(L)-OLD(5,L)-TSF(L)*DET(L) >>>>>>>>>>>>>> ff(6,L) = RQ(L)-OLD(6,L)-TSF(L)*DRQ(L) >>>>>>>>>>>>>> ff(7,L) = REPS(L)-OLD(7,L)-TSF(L)*DREPS(L) >>>>>>>>>>>>>> >>>>>>>>>>>>>> And save the new value of RO-REPS to use in the next iteration of back-euler: >>>>>>>>>>>>>> >>>>>>>>>>>>>> OLD(1,L)=RO(L) >>>>>>>>>>>>>> OLD(2,L)=RU(L) >>>>>>>>>>>>>> OLD(3,L)=RV(L) >>>>>>>>>>>>>> OLD(4,L)=RW(L) >>>>>>>>>>>>>> OLD(5,L)=ET(L) >>>>>>>>>>>>>> OLD(6,L)=RQ(L) >>>>>>>>>>>>>> OLD(7,L)=REPS(L) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Here I print the values of L=2 as above for debugging: >>>>>>>>>>>>>> >>>>>>>>>>>>>> write(6,*)ff(5,2)," = ",ET(2),"-",OLD(5,2),"-",TSF(2),"*",DET(2) >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> The program exit abnormaly after 33 runs of the FormFunction. The >>>>>>>>>>>>>> cause of this is that AUXVR tries to perform sqrt(ET(2)) when ET(2) is >>>>>>>>>>>>>> negative, ET is the total energy and should never be negative. It >>>>>>>>>>>>>> seems that all of a sudden the PETSc SNES solver decides to supply the >>>>>>>>>>>>>> FormFunction with a negative ET value. I need help understanding why >>>>>>>>>>>>>> and how to fix it (if it is fixable). >>>>>>>>>>>>>> >>>>>>>>>>>>>> Here is the output of: >>>>>>>>>>>>>> write(6,*)"ET(2) = xx(5,2) : ",ET(2)," = ",xx(5,2) >>>>>>>>>>>>>> Which is in the beginning of my FormFunction. >>>>>>>>>>>>>> And: >>>>>>>>>>>>>> write(6,*)ff(5,2)," = ",ET(2),"-",OLD(5,2),"-",TSF(2),"*",DET(2) >>>>>>>>>>>>>> Which is in the end of my Formfunction. >>>>>>>>>>>>>> >>>>>>>>>>>>>> 1. ET(2) = xx(5,2) : 253250. = 253250.000000000 >>>>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>>>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>>>>>>>>>>>>> 2. ET(2) = xx(5,2) : 253250. = 253250.000010259 >>>>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>>>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>>>>>>>>>>>>> 3. ET(2) = xx(5,2) : 253250. = 253249.999999988 >>>>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4132419437260 = >>>>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941324E+08 >>>>>>>>>>>>>> 4. ET(2) = xx(5,2) : 253250. = 253250.000048432 >>>>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>>>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>>>>>>>>>>>>> 5. ET(2) = xx(5,2) : 253250. = 253249.999999872 >>>>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4177283437784 = >>>>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941773E+08 >>>>>>>>>>>>>> 6. ET(2) = xx(5,2) : 253250. = 253250.000071113 >>>>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>>>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>>>>>>>>>>>>> 7. ET(2) = xx(5,2) : 253250. = 253249.999980115 >>>>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4453347441010 = >>>>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.944533E+08 >>>>>>>>>>>>>> 8. ET(2) = xx(5,2) : 253250. = 253250.000037298 >>>>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4082723436679 = >>>>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940827E+08 >>>>>>>>>>>>>> 9. ET(2) = xx(5,2) : 253250. = 253249.999942706 >>>>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4082723436679 = >>>>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940827E+08 >>>>>>>>>>>>>> 10. ET(2) = xx(5,2) : 253250. = 253249.999948703 >>>>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>>>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>>>>>>>>>>>>> 11. ET(2) = xx(5,2) : 253250. = 253250.000007808 >>>>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.7283811474088 = >>>>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.972838E+08 >>>>>>>>>>>>>> 12. ET(2) = xx(5,2) : 253250. = 253250.000018146 >>>>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>>>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>>>>>>>>>>>>> 13. ET(2) = xx(5,2) : 253250. = 253250.000001865 >>>>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 28.3742819315846 = >>>>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.837428E+08 >>>>>>>>>>>>>> 14. ET(2) = xx(5,2) : 253250. = 253249.999997296 >>>>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>>>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>>>>>>>>>>>>> 15. ET(2) = xx(5,2) : 253250. = 253250.000000049 >>>>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 30.6548963582361 = >>>>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -3.065490E+08 >>>>>>>>>>>>>> 16. ET(2) = xx(5,2) : 253250. = 253250.000022870 >>>>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>>>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>>>>>>>>>>>>> 17. ET(2) = xx(5,2) : 253250. = 253249.999999716 >>>>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.5326051451209 = >>>>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.953260E+08 >>>>>>>>>>>>>> 18. ET(2) = xx(5,2) : 253250. = 253250.000074328 >>>>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4165187437643 = >>>>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941652E+08 >>>>>>>>>>>>>> 19. ET(2) = xx(5,2) : 253250. = 253250.000049809 >>>>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4085059436707 = >>>>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940851E+08 >>>>>>>>>>>>>> 20. ET(2) = xx(5,2) : 253250. = 253250.000019253 >>>>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>>>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>>>>>>>>>>>>> 21. ET(2) = xx(5,2) : 253250. = 253250.000000189 >>>>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.8851075492403 = >>>>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.988511E+08 >>>>>>>>>>>>>> 22. ET(2) = xx(5,2) : 253250. = 253249.999997897 >>>>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4085059436707 = >>>>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940851E+08 >>>>>>>>>>>>>> 23. ET(2) = xx(5,2) : 253250. = 253249.999975142 >>>>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.3961539435263 = >>>>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.939615E+08 >>>>>>>>>>>>>> 24. ET(2) = xx(5,2) : 253250. = 253250.000018324 >>>>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4085059436707 = >>>>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940851E+08 >>>>>>>>>>>>>> 25. ET(2) = xx(5,2) : 253250. = 253249.999987073 >>>>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4165187437643 = >>>>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941652E+08 >>>>>>>>>>>>>> 26. ET(2) = xx(5,2) : 253250. = 253249.999980982 >>>>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4165187437643 = >>>>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941652E+08 >>>>>>>>>>>>>> 27. ET(2) = xx(5,2) : 253250. = 253249.999994645 >>>>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>>>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>>>>>>>>>>>>> 28. ET(2) = xx(5,2) : 253250. = 253249.999962364 >>>>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4165187437643 = >>>>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941652E+08 >>>>>>>>>>>>>> 29. ET(2) = xx(5,2) : 253250. = 253249.999999921 >>>>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>>>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>>>>>>>>>>>>> 30. ET(2) = xx(5,2) : 253250. = 253250.000000058 >>>>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 28.4019971319085 = >>>>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.840200E+08 >>>>>>>>>>>>>> 31. ET(2) = xx(5,2) : 253250. = 253250.000040348 >>>>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4085059436707 = >>>>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.940851E+08 >>>>>>>>>>>>>> 32. ET(2) = xx(5,2) : 253250. = 253250.000005245 >>>>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>>>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>>>>>>>>>>>>> 33. ET(2) = xx(5,2) : 253250. = 253250.000005245 >>>>>>>>>>>>>> ff(5,2) = ET(2)-OLD(5,2)-TSF(2)*DET(2) : 29.4126563437192 = >>>>>>>>>>>>>> 253250. - 253250.000000000 - 1.000000E-07 * -2.941266E+08 >>>>>>>>>>>>>> 34. ET(2) = xx(5,2) : -848141. = -848141.388090847 >>>>>>>>>>>>>> -------------------------------------------------------------------------- >>>>>>>>>>>>>> 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. >>>>>>>>>>>>>> ----------------------------------------------------------------------- >>>>>>>>>>>>>> ./SNESG3D2 on a linux-gnu named sethnx004.vac.com by yy26539 Mon Feb >>>>>>>>>>>>>> 27 14:21:13 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] SNES user function line 0 unknownunknown >>>>>>>>>>>>>> [0]PETSC ERROR: [0] SNESComputeFunction line 788 src/snes/interface/snes.c >>>>>>>>>>>>>> [0]PETSC ERROR: [0] SNESLineSearchCubic line 514 src/snes/impls/ls/ls.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: ! >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Suggestions and tips are very welcome! >>>>>>>>>>>>>> /nisse >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Nils-Erik Svang???rd >>>>>>>>>>>>>> MSN: schweingaard at hotmail.com >>>>>>>>>>>>>> Skype: schweingaard >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Nils-Erik Svang?rd >>>>>>>>>>>> MSN: schweingaard at hotmail.com >>>>>>>>>>>> Skype: schweingaard >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> 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 > > From ziemer at lncc.br Wed Mar 15 08:26:46 2006 From: ziemer at lncc.br (ziemer at lncc.br) Date: Wed, 15 Mar 2006 11:26:46 -0300 Subject: ***LOOPING MAIL*** PetscInitialize problem? In-Reply-To: References: <1142275120.4415bc30c005d@webmail.lncc.br> <1142279432.4415cd08d6d72@webmail.lncc.br> <1142337786.4416b0fabfdb5@webmail.lncc.br> Message-ID: <1142432806.44182426c00b1@webmail.lncc.br> Yes, I have already tried to include the file mpif.h and them the compiler indicated that there was some variables that were already had been declared (doubled declaration). Thank you very much. Paulo Ziemer Quoting Barry Smith : > > Are you sure that mpif.h is actually being included > by include/finclude/petsc.h? > > Barry > > > On Tue, 14 Mar 2006, ziemer at lncc.br wrote: > > > This is part of the source code where the problem happens: > > > > Thank you for your patience. > > > > ***************************************************************** > > PROGRAM Premain > > C ------------------------------------------------------------------ > > ! Use ModuloLectura > > IMPLICIT REAL*8 (A-H,O-Z) > > ! > > ! Parallel begin > > ! petsc include files > > #include "include/finclude/petsc.h" > > ! Parallel end > > ! > > Logical Sym, NonLinearProblem,Iterative > > INTEGER ERR_ALLOC > > Parameter (Lch=16) > > Character Str*120 > > double precision noMPI_Wtime > > C > > ! INTERFACE ReadMat > > ! MODULE PROCEDURE ReadMat > > ! END INTERFACE > > ! INTERFACE ReadCoupling > > ! MODULE PROCEDURE ReadCoupling > > ! END INTERFACE > > ! INTERFACE Dimen > > ! MODULE PROCEDURE Dimen > > ! END INTERFACE > > C > > Allocatable X (:) > > Allocatable Ie__Param (:) > > Allocatable Ie_JParam (:) > > Allocatable Param (:) > > > > ! Parallel begin > > call PetscInitialize (PETSC_NULL_CHARACTER, iError) > > if (iError.ne.0) then > > Write (6,*) "Can't initialize PETSC" > > Stop > > End if > > ! Ask total number of proccesses > > ! > > ! PROBLEM BEGINS IN THE NEXT FUNCTION - MPI_COMM_WORLD IS NOT SET!! > > call MPI_Comm_size (MPI_COMM_WORLD, iSize, iError) > > ! ID of this proccess > > call MPI_Comm_rank (MPI_COMM_WORLD, iRank, iError) > > ! > > ********************************************************** > > > > > > Quoting Satish Balay : > > > >> > >> You should be able to use either MPI_COMM_WORLD or PETSC_COMM_WORLD or > >> any other communicator. There must be something else wrong in your > >> code. Can't comment without looking at the code. > >> > >> Satish > >> > >> On Mon, 13 Mar 2006, ziemer at lncc.br wrote: > >> > >>> Hi, > >>> > >>> The Petsc installation examples run ok. > >>> > >>> The strange thing is if I change the parameter MPI_COMM_WORLD of the > >> function > >>> MPI_Comm_size() to PTESC_COMM_WORLD this function works, but at same time > >> this > >>> same strategy does not work with the MPI_Bcast() function. > >>> > >>> Thank you very much for your nice help. > >>> > >>> Paulo Ziemer. > >>> > >>> > >>> Quoting Satish Balay : > >>> > >>>> According to the error message - the communicator is invalid. You > >>>> might want to check that.. > >>>> > >>>> You should be able to call MPI_Comm_size() after PetscInitialize() > >>>> Check src/sys/examples/tutorials/ex1.c for an example of this usage. > >>>> > >>>> BTW: Do PETSc examples run fine with your install? > >>>> > >>>> Satish > >>>> > >>>> > >>>> On Mon, 13 Mar 2006, ziemer at lncc.br wrote: > >>>> > >>>>> Hello, > >>>>> > >>>>> I would be very glad if someone could give me some direction: > >>>>> > >>>>> After the MPI_Comm_size function is called, I got this error: > >>>>> > >>>>> aborting job: > >>>>> Fatal error in MPI_Comm_size: Invalid communicator, error stack: > >>>>> MPI_Comm_size(110): MPI_Comm_size(comm=0x1, size=0xbfffdf78) failed > >>>>> MPI_Comm_size(69): Invalid communicator > >>>>> > >>>>> It seems that the MPI environment is not being correctly created by the > >>>> function > >>>>> PetscInitialize. > >>>>> > >>>>> > >>>>> Does anyone have any idea? > >>>>> > >>>>> > >>>>> Best Regards. > >>>>> > >>>>> ---------------------------------------------------------------- > >>>>> This message was sent using IMP, the Internet Messaging Program. > >>>>> > >>>>> > >>>> > >>> > >>> > >>> > >>> > >>> ---------------------------------------------------------------- > >>> This message was sent using IMP, the Internet Messaging Program. > >>> > >>> > > > > > > > > > > ---------------------------------------------------------------- > > This message was sent using IMP, the Internet Messaging Program. > > > > > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From balay at mcs.anl.gov Wed Mar 15 08:52:12 2006 From: balay at mcs.anl.gov (Satish Balay) Date: Wed, 15 Mar 2006 08:52:12 -0600 (CST) Subject: ***LOOPING MAIL*** PetscInitialize problem? In-Reply-To: <1142432806.44182426c00b1@webmail.lncc.br> References: <1142275120.4415bc30c005d@webmail.lncc.br> <1142279432.4415cd08d6d72@webmail.lncc.br> <1142337786.4416b0fabfdb5@webmail.lncc.br> <1142432806.44182426c00b1@webmail.lncc.br> Message-ID: Please try reproducing this in a PETSc example say src/sys/examples/tutorials/ex5f.F Are you using PETSc makefiles to compile your code? Send us complete make output from compiling this PETSc example - and compiling your code [which will include compile commands - compiler messages etc..] Satish On Wed, 15 Mar 2006, ziemer at lncc.br wrote: > Yes, I have already tried to include the file mpif.h and them the compiler > indicated that there was some variables that were already had been declared > (doubled declaration). > > > Thank you very much. > Paulo Ziemer > > Quoting Barry Smith : > > > > > Are you sure that mpif.h is actually being included > > by include/finclude/petsc.h? > > > > Barry > > > > > > On Tue, 14 Mar 2006, ziemer at lncc.br wrote: > > > > > This is part of the source code where the problem happens: > > > > > > Thank you for your patience. > > > > > > ***************************************************************** > > > PROGRAM Premain > > > C ------------------------------------------------------------------ > > > ! Use ModuloLectura > > > IMPLICIT REAL*8 (A-H,O-Z) > > > ! > > > ! Parallel begin > > > ! petsc include files > > > #include "include/finclude/petsc.h" > > > ! Parallel end > > > ! > > > Logical Sym, NonLinearProblem,Iterative > > > INTEGER ERR_ALLOC > > > Parameter (Lch=16) > > > Character Str*120 > > > double precision noMPI_Wtime > > > C > > > ! INTERFACE ReadMat > > > ! MODULE PROCEDURE ReadMat > > > ! END INTERFACE > > > ! INTERFACE ReadCoupling > > > ! MODULE PROCEDURE ReadCoupling > > > ! END INTERFACE > > > ! INTERFACE Dimen > > > ! MODULE PROCEDURE Dimen > > > ! END INTERFACE > > > C > > > Allocatable X (:) > > > Allocatable Ie__Param (:) > > > Allocatable Ie_JParam (:) > > > Allocatable Param (:) > > > > > > ! Parallel begin > > > call PetscInitialize (PETSC_NULL_CHARACTER, iError) > > > if (iError.ne.0) then > > > Write (6,*) "Can't initialize PETSC" > > > Stop > > > End if > > > ! Ask total number of proccesses > > > ! > > > ! PROBLEM BEGINS IN THE NEXT FUNCTION - MPI_COMM_WORLD IS NOT SET!! > > > call MPI_Comm_size (MPI_COMM_WORLD, iSize, iError) > > > ! ID of this proccess > > > call MPI_Comm_rank (MPI_COMM_WORLD, iRank, iError) > > > ! > > > ********************************************************** > > > > > > > > > Quoting Satish Balay : > > > > > >> > > >> You should be able to use either MPI_COMM_WORLD or PETSC_COMM_WORLD or > > >> any other communicator. There must be something else wrong in your > > >> code. Can't comment without looking at the code. > > >> > > >> Satish > > >> > > >> On Mon, 13 Mar 2006, ziemer at lncc.br wrote: > > >> > > >>> Hi, > > >>> > > >>> The Petsc installation examples run ok. > > >>> > > >>> The strange thing is if I change the parameter MPI_COMM_WORLD of the > > >> function > > >>> MPI_Comm_size() to PTESC_COMM_WORLD this function works, but at same time > > >> this > > >>> same strategy does not work with the MPI_Bcast() function. > > >>> > > >>> Thank you very much for your nice help. > > >>> > > >>> Paulo Ziemer. > > >>> > > >>> > > >>> Quoting Satish Balay : > > >>> > > >>>> According to the error message - the communicator is invalid. You > > >>>> might want to check that.. > > >>>> > > >>>> You should be able to call MPI_Comm_size() after PetscInitialize() > > >>>> Check src/sys/examples/tutorials/ex1.c for an example of this usage. > > >>>> > > >>>> BTW: Do PETSc examples run fine with your install? > > >>>> > > >>>> Satish > > >>>> > > >>>> > > >>>> On Mon, 13 Mar 2006, ziemer at lncc.br wrote: > > >>>> > > >>>>> Hello, > > >>>>> > > >>>>> I would be very glad if someone could give me some direction: > > >>>>> > > >>>>> After the MPI_Comm_size function is called, I got this error: > > >>>>> > > >>>>> aborting job: > > >>>>> Fatal error in MPI_Comm_size: Invalid communicator, error stack: > > >>>>> MPI_Comm_size(110): MPI_Comm_size(comm=0x1, size=0xbfffdf78) failed > > >>>>> MPI_Comm_size(69): Invalid communicator > > >>>>> > > >>>>> It seems that the MPI environment is not being correctly created by the > > >>>> function > > >>>>> PetscInitialize. > > >>>>> > > >>>>> > > >>>>> Does anyone have any idea? > > >>>>> > > >>>>> > > >>>>> Best Regards. > > >>>>> > > >>>>> ---------------------------------------------------------------- > > >>>>> This message was sent using IMP, the Internet Messaging Program. > > >>>>> > > >>>>> > > >>>> > > >>> > > >>> > > >>> > > >>> > > >>> ---------------------------------------------------------------- > > >>> This message was sent using IMP, the Internet Messaging Program. > > >>> > > >>> > > > > > > > > > > > > > > > ---------------------------------------------------------------- > > > This message was sent using IMP, the Internet Messaging Program. > > > > > > > > > > > > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > > From balay at mcs.anl.gov Wed Mar 15 08:54:26 2006 From: balay at mcs.anl.gov (Satish Balay) Date: Wed, 15 Mar 2006 08:54:26 -0600 (CST) Subject: ***LOOPING MAIL*** PetscInitialize problem? In-Reply-To: References: <1142275120.4415bc30c005d@webmail.lncc.br> <1142279432.4415cd08d6d72@webmail.lncc.br> <1142337786.4416b0fabfdb5@webmail.lncc.br> <1142432806.44182426c00b1@webmail.lncc.br> Message-ID: On Wed, 15 Mar 2006, Satish Balay wrote: > Please try reproducing this in a PETSc example say > src/sys/examples/tutorials/ex5f.F That should be src/sys/examples/tests/ex5f.F Satish > > Are you using PETSc makefiles to compile your code? Send us complete > make output from compiling this PETSc example - and compiling your > code [which will include compile commands - compiler messages etc..] From nilserik at gmail.com Wed Mar 15 10:47:01 2006 From: nilserik at gmail.com (=?ISO-8859-1?Q?Nils_Erik_Svang=E5rd?=) Date: Wed, 15 Mar 2006 17:47:01 +0100 Subject: SNES Problem In-Reply-To: References: <82f936c20602270607t775d7e03o6a37afa4c0b3d2a8@mail.gmail.com> <82f936c20603140727k208100f8vcb8f5672f9e9284e@mail.gmail.com> <82f936c20603141202p77439573hf249e43c53ae4d45@mail.gmail.com> <82f936c20603141237q2989c5a1i996ccf4815ed7f45@mail.gmail.com> <82f936c20603142140o768183f7id7b6e210bc7d9b1@mail.gmail.com> Message-ID: <82f936c20603150847s4b0a027aw7a2077723f5e86c9@mail.gmail.com> > > It is one line to add in the SNES implementation because there I set > > timestep for each iteration. The RK is used via TS which manage the > > timestep, and I am not sure how to manage the timestep myself in when > > using TS, > > I see. Yes, it is a little harder since you have to edit rk.c > but it is still pretty easy. > Ok, I edited my SNES back-euler implementation to use time-accurate timestep with the stability criteria of the old code. Petsc bugs out again, it does this on the first step, I have never solved even the first step. About 163 iterations and the input vector gets strange non-physical values. I have looked at rk.c, and I'm not sure how to use it. Have I understood correctly that I should: get at copy of rk.c put it in my working dir, somehow change it so it uses some global variables or neigboring cellvalues to compute the timestep with the same algorithm used in the old fortran code, then compile rk.c and make sure the object file gets linked when compiling my fortran program (or should I rebuild petsc also?) /nisse From bsmith at mcs.anl.gov Wed Mar 15 12:41:14 2006 From: bsmith at mcs.anl.gov (Barry Smith) Date: Wed, 15 Mar 2006 12:41:14 -0600 (CST) Subject: SNES Problem In-Reply-To: <82f936c20603150847s4b0a027aw7a2077723f5e86c9@mail.gmail.com> References: <82f936c20602270607t775d7e03o6a37afa4c0b3d2a8@mail.gmail.com> <82f936c20603140727k208100f8vcb8f5672f9e9284e@mail.gmail.com> <82f936c20603141202p77439573hf249e43c53ae4d45@mail.gmail.com> <82f936c20603141237q2989c5a1i996ccf4815ed7f45@mail.gmail.com> <82f936c20603142140o768183f7id7b6e210bc7d9b1@mail.gmail.com> <82f936c20603150847s4b0a027aw7a2077723f5e86c9@mail.gmail.com> Message-ID: On Wed, 15 Mar 2006, Nils Erik Svang?rd wrote: >>> It is one line to add in the SNES implementation because there I set >>> timestep for each iteration. The RK is used via TS which manage the >>> timestep, and I am not sure how to manage the timestep myself in when >>> using TS, >> >> I see. Yes, it is a little harder since you have to edit rk.c >> but it is still pretty easy. >> > > Ok, I edited my SNES back-euler implementation to use time-accurate > timestep with the stability criteria of the old code. Petsc bugs out > again, it does this on the first step, I have never solved even the > first step. About 163 iterations and the input vector gets strange > non-physical values. It doesn't like the nonlinear system. If you run on one process with -pc_type lu -snes_monitor what happens? Same problem or does it get past the first timestep? If it fails what if you use a much smaller time step, does it convergen then? > > I have looked at rk.c, and I'm not sure how to use it. > Have I understood correctly that I should: get at copy of rk.c put it > in my working dir, somehow change it so it uses some global variables > or neigboring cellvalues to compute the timestep with the same > algorithm used in the old fortran code, then compile rk.c and make > sure the object file gets linked when compiling my fortran program Yes, >(or > should I rebuild petsc also?) You don't need to rebuild PETSc. > > /nisse > > From nilserik at gmail.com Wed Mar 15 16:31:51 2006 From: nilserik at gmail.com (=?ISO-8859-1?Q?Nils_Erik_Svang=E5rd?=) Date: Wed, 15 Mar 2006 23:31:51 +0100 Subject: SNES Problem In-Reply-To: References: <82f936c20602270607t775d7e03o6a37afa4c0b3d2a8@mail.gmail.com> <82f936c20603141202p77439573hf249e43c53ae4d45@mail.gmail.com> <82f936c20603141237q2989c5a1i996ccf4815ed7f45@mail.gmail.com> <82f936c20603142140o768183f7id7b6e210bc7d9b1@mail.gmail.com> <82f936c20603150847s4b0a027aw7a2077723f5e86c9@mail.gmail.com> Message-ID: <82f936c20603151431t45e675f4hf664822d91bd72af@mail.gmail.com> > > It doesn't like the nonlinear system. If you run on one process with > -pc_type lu -snes_monitor what happens? Same problem or does it get > past the first timestep? If it fails what if you use a much smaller time > step, does it convergen then? I'll try that when I have access to the code and compiler again, however I use -snes_mf because I dont have any jacobian and I seem to remember that using -pc_type lu dosent work when using -snes_mf, but I might have understood wrong. I have used the same timestep I use for the old 3-stage RK I can try a really small timestep instead. And it fails both when using TS or SNES, which probably almost the same thing considering they both try to solve the first timestep. > > > > I have looked at rk.c, and I'm not sure how to use it. > > Have I understood correctly that I should: get at copy of rk.c put it > > in my working dir, somehow change it so it uses some global variables > > or neigboring cellvalues to compute the timestep with the same > > algorithm used in the old fortran code, then compile rk.c and make > > sure the object file gets linked when compiling my fortran program > > Yes, > OK, I will try my best, I have never tried something like that before. I rebuild petsc also?) /nisse -- Nils-Erik Svang?rd E-Mail: nilserik at gmail.com MSN: schweingaard at hotmail.com Skype: schweingaard Mobil: +46-(0)70-3612178 From bsmith at mcs.anl.gov Wed Mar 15 16:45:39 2006 From: bsmith at mcs.anl.gov (Barry Smith) Date: Wed, 15 Mar 2006 16:45:39 -0600 (CST) Subject: SNES Problem In-Reply-To: <82f936c20603151431t45e675f4hf664822d91bd72af@mail.gmail.com> References: <82f936c20602270607t775d7e03o6a37afa4c0b3d2a8@mail.gmail.com> <82f936c20603141202p77439573hf249e43c53ae4d45@mail.gmail.com> <82f936c20603141237q2989c5a1i996ccf4815ed7f45@mail.gmail.com> <82f936c20603142140o768183f7id7b6e210bc7d9b1@mail.gmail.com> <82f936c20603150847s4b0a027aw7a2077723f5e86c9@mail.gmail.com> <82f936c20603151431t45e675f4hf664822d91bd72af@mail.gmail.com> Message-ID: On Wed, 15 Mar 2006, Nils Erik Svang?rd wrote: >> >> It doesn't like the nonlinear system. If you run on one process with >> -pc_type lu -snes_monitor what happens? Same problem or does it get >> past the first timestep? If it fails what if you use a much smaller time >> step, does it convergen then? > > I'll try that when I have access to the code and compiler again, > however I use -snes_mf because I dont have any jacobian and I seem to > remember that using -pc_type lu dosent work when using -snes_mf, but I > might have understood wrong. 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. Barry > I have used the same timestep I use for the old 3-stage RK I can try a > really small timestep instead. > And it fails both when using TS or SNES, which probably almost the > same thing considering they both try to solve the first timestep. > >>> >>> I have looked at rk.c, and I'm not sure how to use it. >>> Have I understood correctly that I should: get at copy of rk.c put it >>> in my working dir, somehow change it so it uses some global variables >>> or neigboring cellvalues to compute the timestep with the same >>> algorithm used in the old fortran code, then compile rk.c and make >>> sure the object file gets linked when compiling my fortran program >> >> Yes, >> > > OK, I will try my best, I have never tried something like that before. > I rebuild petsc also?) > > /nisse > > > -- > Nils-Erik Svang?rd > E-Mail: nilserik at gmail.com > MSN: schweingaard at hotmail.com > Skype: schweingaard > Mobil: +46-(0)70-3612178 > > From nilserik at gmail.com Wed Mar 15 16:50:55 2006 From: nilserik at gmail.com (=?ISO-8859-1?Q?Nils_Erik_Svang=E5rd?=) Date: Wed, 15 Mar 2006 23:50:55 +0100 Subject: SNES Problem In-Reply-To: References: <82f936c20602270607t775d7e03o6a37afa4c0b3d2a8@mail.gmail.com> <82f936c20603141237q2989c5a1i996ccf4815ed7f45@mail.gmail.com> <82f936c20603142140o768183f7id7b6e210bc7d9b1@mail.gmail.com> <82f936c20603150847s4b0a027aw7a2077723f5e86c9@mail.gmail.com> <82f936c20603151431t45e675f4hf664822d91bd72af@mail.gmail.com> Message-ID: <82f936c20603151450u23910e93pe3c518eea288d216@mail.gmail.com> > > 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 From bsmith at mcs.anl.gov Wed Mar 15 16:53:08 2006 From: bsmith at mcs.anl.gov (Barry Smith) Date: Wed, 15 Mar 2006 16:53:08 -0600 (CST) Subject: SNES Problem In-Reply-To: <82f936c20603151450u23910e93pe3c518eea288d216@mail.gmail.com> References: <82f936c20602270607t775d7e03o6a37afa4c0b3d2a8@mail.gmail.com> <82f936c20603141237q2989c5a1i996ccf4815ed7f45@mail.gmail.com> <82f936c20603142140o768183f7id7b6e210bc7d9b1@mail.gmail.com> <82f936c20603150847s4b0a027aw7a2077723f5e86c9@mail.gmail.com> <82f936c20603151431t45e675f4hf664822d91bd72af@mail.gmail.com> <82f936c20603151450u23910e93pe3c518eea288d216@mail.gmail.com> Message-ID: 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 > > From abdul-rahman at tu-harburg.de Thu Mar 16 12:33:07 2006 From: abdul-rahman at tu-harburg.de (abdul-rahman at tu-harburg.de) Date: Thu, 16 Mar 2006 19:33:07 +0100 (MET) Subject: -ksp_monitor Message-ID: Hi all, Is there a simple way to control the output of residual monitor ? i.e., instead of every iteration, can I output every N iterations to screen ? As for the true residuals, can I store them? I know how to get the preconditioned residuals. Seems to me the true residuals are in the vt2 temp variable I saw in KSPInitialResidual. Many thanks, Razi From bsmith at mcs.anl.gov Thu Mar 16 12:50:53 2006 From: bsmith at mcs.anl.gov (Barry Smith) Date: Thu, 16 Mar 2006 12:50:53 -0600 (CST) Subject: -ksp_monitor In-Reply-To: References: Message-ID: On Thu, 16 Mar 2006, abdul-rahman at tu-harburg.de wrote: > Hi all, > > Is there a simple way to control the output of residual monitor ? i.e., > instead of every iteration, can I output every N iterations to screen ? > Yes, you simply provide your own KSPMonitor routine and then set it with KSPSetMonitor() see manual page. KSP in src/ksp/ksp/interface/iterativ.c > As for the true residuals, can I store them? I know how to get the > preconditioned residuals. Seems to me the true residuals are in the vt2 > temp variable I saw in KSPInitialResidual. You must obtain the true residuals with KSPBuildResidual(). For some methods, such as GMRES, the true residual and its norm are NEVER computed (they are not part of the algorithm), so you cannot just pull it out of some data structure you need to call KSPBuildResidual(). Note that if you use right preconditioning the true residual is the preconditioned residual, making life easy. Barry > > Many thanks, > > Razi > > From knepley at gmail.com Thu Mar 16 12:42:45 2006 From: knepley at gmail.com (Matthew Knepley) Date: Thu, 16 Mar 2006 12:42:45 -0600 Subject: -ksp_monitor In-Reply-To: References: Message-ID: You can use -ksp_truemonitor for the true residual. I don't think we have something to output every N iterations, but adding a custom monitor is not that hard. You use KSPSetMonitor(): http://www-unix.mcs.anl.gov/petsc/petsc-as/snapshots/petsc-current/docs/manualpages/KSP/KSPSetMonitor.html Matt On 3/16/06, abdul-rahman at tu-harburg.de wrote: > > Hi all, > > Is there a simple way to control the output of residual monitor ? i.e., > instead of every iteration, can I output every N iterations to screen ? > > As for the true residuals, can I store them? I know how to get the > preconditioned residuals. Seems to me the true residuals are in the vt2 > temp variable I saw in KSPInitialResidual. > > Many thanks, > > Razi > > -- "Failure has a thousand explanations. Success doesn't need one" -- Sir Alec Guiness -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilserik at gmail.com Thu Mar 16 13:17:02 2006 From: nilserik at gmail.com (=?ISO-8859-1?Q?Nils_Erik_Svang=E5rd?=) Date: Thu, 16 Mar 2006 20:17:02 +0100 Subject: SNES Problem In-Reply-To: References: <82f936c20602270607t775d7e03o6a37afa4c0b3d2a8@mail.gmail.com> <82f936c20603142140o768183f7id7b6e210bc7d9b1@mail.gmail.com> <82f936c20603150847s4b0a027aw7a2077723f5e86c9@mail.gmail.com> <82f936c20603151431t45e675f4hf664822d91bd72af@mail.gmail.com> <82f936c20603151450u23910e93pe3c518eea288d216@mail.gmail.com> Message-ID: <82f936c20603161117j23c6997bt6ed179a82be12a17@mail.gmail.com> 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 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 From knepley at gmail.com Thu Mar 16 12:42:45 2006 From: knepley at gmail.com (Matthew Knepley) Date: Thu, 16 Mar 2006 12:42:45 -0600 Subject: -ksp_monitor In-Reply-To: References: Message-ID: You can use -ksp_truemonitor for the true residual. I don't think we have something to output every N iterations, but adding a custom monitor is not that hard. You use KSPSetMonitor(): http://www-unix.mcs.anl.gov/petsc/petsc-as/snapshots/petsc-current/docs/manualpages/KSP/KSPSetMonitor.html Matt On 3/16/06, abdul-rahman at tu-harburg.de wrote: > > Hi all, > > Is there a simple way to control the output of residual monitor ? i.e., > instead of every iteration, can I output every N iterations to screen ? > > As for the true residuals, can I store them? I know how to get the > preconditioned residuals. Seems to me the true residuals are in the vt2 > temp variable I saw in KSPInitialResidual. > > Many thanks, > > Razi > > -- "Failure has a thousand explanations. Success doesn't need one" -- Sir Alec Guiness -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsmith at mcs.anl.gov Thu Mar 16 13:27:19 2006 From: bsmith at mcs.anl.gov (Barry Smith) Date: Thu, 16 Mar 2006 13:27:19 -0600 (CST) Subject: SNES Problem In-Reply-To: <82f936c20603161117j23c6997bt6ed179a82be12a17@mail.gmail.com> References: <82f936c20602270607t775d7e03o6a37afa4c0b3d2a8@mail.gmail.com> <82f936c20603142140o768183f7id7b6e210bc7d9b1@mail.gmail.com> <82f936c20603150847s4b0a027aw7a2077723f5e86c9@mail.gmail.com> <82f936c20603151431t45e675f4hf664822d91bd72af@mail.gmail.com> <82f936c20603151450u23910e93pe3c518eea288d216@mail.gmail.com> <82f936c20603161117j23c6997bt6ed179a82be12a17@mail.gmail.com> Message-ID: 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 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 > > From abdul-rahman at tu-harburg.de Thu Mar 16 13:42:42 2006 From: abdul-rahman at tu-harburg.de (abdul-rahman at tu-harburg.de) Date: Thu, 16 Mar 2006 20:42:42 +0100 (MET) Subject: -ksp_monitor In-Reply-To: References: Message-ID: On Thu, 16 Mar 2006, Barry Smith wrote: > Yes, you simply provide your own KSPMonitor routine and then set it with > KSPSetMonitor() see manual page. KSP in src/ksp/ksp/interface/iterativ.c Thanks Matt and Barry. Sorry I've overlooked. There's even an example, MyKSPMonitor, in the doc. Razi From knepley at gmail.com Thu Mar 16 12:42:45 2006 From: knepley at gmail.com (Matthew Knepley) Date: Thu, 16 Mar 2006 12:42:45 -0600 Subject: -ksp_monitor In-Reply-To: References: Message-ID: You can use -ksp_truemonitor for the true residual. I don't think we have something to output every N iterations, but adding a custom monitor is not that hard. You use KSPSetMonitor(): http://www-unix.mcs.anl.gov/petsc/petsc-as/snapshots/petsc-current/docs/manualpages/KSP/KSPSetMonitor.html Matt On 3/16/06, abdul-rahman at tu-harburg.de wrote: > > Hi all, > > Is there a simple way to control the output of residual monitor ? i.e., > instead of every iteration, can I output every N iterations to screen ? > > As for the true residuals, can I store them? I know how to get the > preconditioned residuals. Seems to me the true residuals are in the vt2 > temp variable I saw in KSPInitialResidual. > > Many thanks, > > Razi > > -- "Failure has a thousand explanations. Success doesn't need one" -- Sir Alec Guiness -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilserik at gmail.com Thu Mar 16 16:45:28 2006 From: nilserik at gmail.com (=?ISO-8859-1?Q?Nils_Erik_Svang=E5rd?=) Date: Thu, 16 Mar 2006 23:45:28 +0100 Subject: SNES Problem In-Reply-To: References: <82f936c20602270607t775d7e03o6a37afa4c0b3d2a8@mail.gmail.com> <82f936c20603150847s4b0a027aw7a2077723f5e86c9@mail.gmail.com> <82f936c20603151431t45e675f4hf664822d91bd72af@mail.gmail.com> <82f936c20603151450u23910e93pe3c518eea288d216@mail.gmail.com> <82f936c20603161117j23c6997bt6ed179a82be12a17@mail.gmail.com> Message-ID: <82f936c20603161445i60f1ac8cvcdbf35c191d62603@mail.gmail.com> 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 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 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 From nilserik at gmail.com Fri Mar 17 03:56:47 2006 From: nilserik at gmail.com (=?ISO-8859-1?Q?Nils_Erik_Svang=E5rd?=) Date: Fri, 17 Mar 2006 10:56:47 +0100 Subject: SNES Problem In-Reply-To: <82f936c20603161445i60f1ac8cvcdbf35c191d62603@mail.gmail.com> References: <82f936c20602270607t775d7e03o6a37afa4c0b3d2a8@mail.gmail.com> <82f936c20603150847s4b0a027aw7a2077723f5e86c9@mail.gmail.com> <82f936c20603151431t45e675f4hf664822d91bd72af@mail.gmail.com> <82f936c20603151450u23910e93pe3c518eea288d216@mail.gmail.com> <82f936c20603161117j23c6997bt6ed179a82be12a17@mail.gmail.com> <82f936c20603161445i60f1ac8cvcdbf35c191d62603@mail.gmail.com> Message-ID: <82f936c20603170156p42b1d4ecucde71da67053e517@mail.gmail.com> 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 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 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 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 From nilserik at gmail.com Fri Mar 17 17:27:39 2006 From: nilserik at gmail.com (=?ISO-8859-1?Q?Nils_Erik_Svang=E5rd?=) Date: Sat, 18 Mar 2006 00:27:39 +0100 Subject: SNES Problem In-Reply-To: References: <82f936c20602270607t775d7e03o6a37afa4c0b3d2a8@mail.gmail.com> <82f936c20603151431t45e675f4hf664822d91bd72af@mail.gmail.com> <82f936c20603151450u23910e93pe3c518eea288d216@mail.gmail.com> <82f936c20603161117j23c6997bt6ed179a82be12a17@mail.gmail.com> <82f936c20603161445i60f1ac8cvcdbf35c191d62603@mail.gmail.com> <82f936c20603170156p42b1d4ecucde71da67053e517@mail.gmail.com> Message-ID: <82f936c20603171527x111b7954rb3998128b34cdde7@mail.gmail.com> On 3/17/06, Barry Smith 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 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 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 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 From bsmith at mcs.anl.gov Fri Mar 17 17:45:57 2006 From: bsmith at mcs.anl.gov (Barry Smith) Date: Fri, 17 Mar 2006 17:45:57 -0600 (CST) Subject: SNES Problem In-Reply-To: <82f936c20603171527x111b7954rb3998128b34cdde7@mail.gmail.com> References: <82f936c20602270607t775d7e03o6a37afa4c0b3d2a8@mail.gmail.com> <82f936c20603151431t45e675f4hf664822d91bd72af@mail.gmail.com> <82f936c20603151450u23910e93pe3c518eea288d216@mail.gmail.com> <82f936c20603161117j23c6997bt6ed179a82be12a17@mail.gmail.com> <82f936c20603161445i60f1ac8cvcdbf35c191d62603@mail.gmail.com> <82f936c20603170156p42b1d4ecucde71da67053e517@mail.gmail.com> <82f936c20603171527x111b7954rb3998128b34cdde7@mail.gmail.com> Message-ID: 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 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 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 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 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 > > From nilserik at gmail.com Fri Mar 17 18:05:29 2006 From: nilserik at gmail.com (=?ISO-8859-1?Q?Nils_Erik_Svang=E5rd?=) Date: Sat, 18 Mar 2006 01:05:29 +0100 Subject: SNES Problem In-Reply-To: References: <82f936c20602270607t775d7e03o6a37afa4c0b3d2a8@mail.gmail.com> <82f936c20603151450u23910e93pe3c518eea288d216@mail.gmail.com> <82f936c20603161117j23c6997bt6ed179a82be12a17@mail.gmail.com> <82f936c20603161445i60f1ac8cvcdbf35c191d62603@mail.gmail.com> <82f936c20603170156p42b1d4ecucde71da67053e517@mail.gmail.com> <82f936c20603171527x111b7954rb3998128b34cdde7@mail.gmail.com> Message-ID: <82f936c20603171605t2731e3b1g24ca578ac6196cc4@mail.gmail.com> On 3/18/06, Barry Smith 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 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 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 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 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 From nilserik at gmail.com Mon Mar 20 03:26:52 2006 From: nilserik at gmail.com (=?ISO-8859-1?Q?Nils_Erik_Svang=E5rd?=) Date: Mon, 20 Mar 2006 10:26:52 +0100 Subject: SNES Problem In-Reply-To: <82f936c20603171605t2731e3b1g24ca578ac6196cc4@mail.gmail.com> References: <82f936c20602270607t775d7e03o6a37afa4c0b3d2a8@mail.gmail.com> <82f936c20603161117j23c6997bt6ed179a82be12a17@mail.gmail.com> <82f936c20603161445i60f1ac8cvcdbf35c191d62603@mail.gmail.com> <82f936c20603170156p42b1d4ecucde71da67053e517@mail.gmail.com> <82f936c20603171527x111b7954rb3998128b34cdde7@mail.gmail.com> <82f936c20603171605t2731e3b1g24ca578ac6196cc4@mail.gmail.com> Message-ID: <82f936c20603200126m6913dc24r5ac07f579a2fcb2c@mail.gmail.com> 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 wrote: > On 3/18/06, Barry Smith 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 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 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 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 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 From nilserik at gmail.com Mon Mar 20 07:36:18 2006 From: nilserik at gmail.com (=?ISO-8859-1?Q?Nils_Erik_Svang=E5rd?=) Date: Mon, 20 Mar 2006 14:36:18 +0100 Subject: SNES Problem In-Reply-To: <82f936c20603200126m6913dc24r5ac07f579a2fcb2c@mail.gmail.com> References: <82f936c20602270607t775d7e03o6a37afa4c0b3d2a8@mail.gmail.com> <82f936c20603161117j23c6997bt6ed179a82be12a17@mail.gmail.com> <82f936c20603161445i60f1ac8cvcdbf35c191d62603@mail.gmail.com> <82f936c20603170156p42b1d4ecucde71da67053e517@mail.gmail.com> <82f936c20603171527x111b7954rb3998128b34cdde7@mail.gmail.com> <82f936c20603171605t2731e3b1g24ca578ac6196cc4@mail.gmail.com> <82f936c20603200126m6913dc24r5ac07f579a2fcb2c@mail.gmail.com> Message-ID: <82f936c20603200536u1505d435i273a035c3a59f11b@mail.gmail.com> 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 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 wrote: > > On 3/18/06, Barry Smith 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 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 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 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 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 From bsmith at mcs.anl.gov Mon Mar 20 07:41:48 2006 From: bsmith at mcs.anl.gov (Barry Smith) Date: Mon, 20 Mar 2006 07:41:48 -0600 (CST) Subject: SNES Problem In-Reply-To: <82f936c20603200536u1505d435i273a035c3a59f11b@mail.gmail.com> References: <82f936c20602270607t775d7e03o6a37afa4c0b3d2a8@mail.gmail.com> <82f936c20603161117j23c6997bt6ed179a82be12a17@mail.gmail.com> <82f936c20603161445i60f1ac8cvcdbf35c191d62603@mail.gmail.com> <82f936c20603170156p42b1d4ecucde71da67053e517@mail.gmail.com> <82f936c20603171527x111b7954rb3998128b34cdde7@mail.gmail.com> <82f936c20603171605t2731e3b1g24ca578ac6196cc4@mail.gmail.com> <82f936c20603200126m6913dc24r5ac07f579a2fcb2c@mail.gmail.com> <82f936c20603200536u1505d435i273a035c3a59f11b@mail.gmail.com> Message-ID: 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 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 wrote: >>> On 3/18/06, Barry Smith 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 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 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 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 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 > > From nilserik at gmail.com Mon Mar 20 08:58:36 2006 From: nilserik at gmail.com (=?ISO-8859-1?Q?Nils_Erik_Svang=E5rd?=) Date: Mon, 20 Mar 2006 15:58:36 +0100 Subject: SNES Problem In-Reply-To: References: <82f936c20602270607t775d7e03o6a37afa4c0b3d2a8@mail.gmail.com> <82f936c20603161445i60f1ac8cvcdbf35c191d62603@mail.gmail.com> <82f936c20603170156p42b1d4ecucde71da67053e517@mail.gmail.com> <82f936c20603171527x111b7954rb3998128b34cdde7@mail.gmail.com> <82f936c20603171605t2731e3b1g24ca578ac6196cc4@mail.gmail.com> <82f936c20603200126m6913dc24r5ac07f579a2fcb2c@mail.gmail.com> <82f936c20603200536u1505d435i273a035c3a59f11b@mail.gmail.com> Message-ID: <82f936c20603200658g69dcee1al72cf75b11449865b@mail.gmail.com> Barry, I have now rewritten the code do 1:i do 1:j do 1:k l= old_numbering m++ newnumbering xx(1,m)=RO(l) xx(2,m)=RU(l) ... end dos The vectors are created by running, where m is the number of iterations in the do loop times 7 because we have 7 diffs to solve (DOF = 7). m=m*7 call VecCreateSeq(PETSC_COMM_SELF,m,x,ierr) could this be a source of trouble, solving 7 diffs at the same time? Petsc still supply get_DRO with strange values, RK crashes directly but beuler does about the double amount of iterations but still doesnt to complete a timestep. /nisse On 3/20/06, Barry Smith wrote: > > 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 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 wrote: > >>> On 3/18/06, Barry Smith 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 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 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 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 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 > > > > > -- Nils-Erik Svang?rd E-Mail: nilserik at gmail.com MSN: schweingaard at hotmail.com Skype: schweingaard Mobil: +46-(0)70-3612178 From bsmith at mcs.anl.gov Mon Mar 20 11:30:30 2006 From: bsmith at mcs.anl.gov (Barry Smith) Date: Mon, 20 Mar 2006 11:30:30 -0600 (CST) Subject: SNES Problem In-Reply-To: <82f936c20603200658g69dcee1al72cf75b11449865b@mail.gmail.com> References: <82f936c20602270607t775d7e03o6a37afa4c0b3d2a8@mail.gmail.com> <82f936c20603161445i60f1ac8cvcdbf35c191d62603@mail.gmail.com> <82f936c20603170156p42b1d4ecucde71da67053e517@mail.gmail.com> <82f936c20603171527x111b7954rb3998128b34cdde7@mail.gmail.com> <82f936c20603171605t2731e3b1g24ca578ac6196cc4@mail.gmail.com> <82f936c20603200126m6913dc24r5ac07f579a2fcb2c@mail.gmail.com> <82f936c20603200536u1505d435i273a035c3a59f11b@mail.gmail.com> <82f936c20603200658g69dcee1al72cf75b11449865b@mail.gmail.com> Message-ID: Nisse, Is there any way you can bundle everything up so you could send it to me and I could easily compile it and make? This approach to trying to discover the problem is taking too long. Barry On Mon, 20 Mar 2006, Nils Erik Svang?rd wrote: > Barry, > I have now rewritten the code > > do 1:i > do 1:j > do 1:k > l= old_numbering > m++ newnumbering > xx(1,m)=RO(l) > xx(2,m)=RU(l) > ... > end dos > > The vectors are created by running, where m is the number of > iterations in the do loop times 7 because we have 7 diffs to solve > (DOF = 7). > > m=m*7 > call VecCreateSeq(PETSC_COMM_SELF,m,x,ierr) > > could this be a source of trouble, solving 7 diffs at the same time? > > Petsc still supply get_DRO with strange values, RK crashes directly > but beuler does about the double amount of iterations but still doesnt > to complete a timestep. > > /nisse > > > On 3/20/06, Barry Smith wrote: >> >> 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 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 wrote: >>>>> On 3/18/06, Barry Smith 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 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 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 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 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 >>> >>> >> > > > -- > Nils-Erik Svang?rd > E-Mail: nilserik at gmail.com > MSN: schweingaard at hotmail.com > Skype: schweingaard > Mobil: +46-(0)70-3612178 > > From nilserik at gmail.com Mon Mar 20 11:38:38 2006 From: nilserik at gmail.com (=?ISO-8859-1?Q?Nils_Erik_Svang=E5rd?=) Date: Mon, 20 Mar 2006 18:38:38 +0100 Subject: SNES Problem In-Reply-To: References: <82f936c20602270607t775d7e03o6a37afa4c0b3d2a8@mail.gmail.com> <82f936c20603171527x111b7954rb3998128b34cdde7@mail.gmail.com> <82f936c20603171605t2731e3b1g24ca578ac6196cc4@mail.gmail.com> <82f936c20603200126m6913dc24r5ac07f579a2fcb2c@mail.gmail.com> <82f936c20603200536u1505d435i273a035c3a59f11b@mail.gmail.com> <82f936c20603200658g69dcee1al72cf75b11449865b@mail.gmail.com> Message-ID: <82f936c20603200938r15e2d316x2aa864ccdf56686a@mail.gmail.com> I will investigate the possibilty and get back to you offlist. /nisse On 3/20/06, Barry Smith wrote: > > Nisse, > > Is there any way you can bundle everything up so you could send > it to me and I could easily compile it and make? This approach to > trying to discover the problem is taking too long. > > Barry > > > On Mon, 20 Mar 2006, Nils Erik Svang?rd wrote: > > > Barry, > > I have now rewritten the code > > > > do 1:i > > do 1:j > > do 1:k > > l= old_numbering > > m++ newnumbering > > xx(1,m)=RO(l) > > xx(2,m)=RU(l) > > ... > > end dos > > > > The vectors are created by running, where m is the number of > > iterations in the do loop times 7 because we have 7 diffs to solve > > (DOF = 7). > > > > m=m*7 > > call VecCreateSeq(PETSC_COMM_SELF,m,x,ierr) > > > > could this be a source of trouble, solving 7 diffs at the same time? > > > > Petsc still supply get_DRO with strange values, RK crashes directly > > but beuler does about the double amount of iterations but still doesnt > > to complete a timestep. > > > > /nisse > > > > > > On 3/20/06, Barry Smith wrote: > >> > >> 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 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 wrote: > >>>>> On 3/18/06, Barry Smith 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 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 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 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 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 > >>> > >>> > >> > > > > > > -- > > 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 From buket at be.itu.edu.tr Mon Mar 20 13:09:32 2006 From: buket at be.itu.edu.tr (buket at be.itu.edu.tr) Date: Mon, 20 Mar 2006 21:09:32 +0200 (EET) Subject: divergence? In-Reply-To: References: <4267.160.75.90.192.1140370474.squirrel@www.be.itu.edu.tr> Message-ID: <1224.160.75.78.141.1142881772.squirrel@www.be.itu.edu.tr> Hello again, I want to compare the iterative methods with direct methods in terms of time. What functions can I use for direct solution? Best Regards, Buket Benek From bsmith at mcs.anl.gov Mon Mar 20 13:12:37 2006 From: bsmith at mcs.anl.gov (Barry Smith) Date: Mon, 20 Mar 2006 13:12:37 -0600 (CST) Subject: divergence? In-Reply-To: <1224.160.75.78.141.1142881772.squirrel@www.be.itu.edu.tr> References: <4267.160.75.90.192.1140370474.squirrel@www.be.itu.edu.tr> <1224.160.75.78.141.1142881772.squirrel@www.be.itu.edu.tr> Message-ID: For sequential runs use -ksp_type preonly -pc_type lu For parallel runs you need to first config/configure.py PETSc to use a parallel direct solver. See http://www-unix.mcs.anl.gov/petsc/petsc-as/documentation/linearsolvertable.html for the choices. Barry On Mon, 20 Mar 2006, buket at be.itu.edu.tr wrote: > Hello again, > > I want to compare the iterative methods with direct methods in terms of time. > What functions can I use for direct solution? > > Best Regards, > Buket Benek > > > From balay at mcs.anl.gov Mon Mar 20 13:13:33 2006 From: balay at mcs.anl.gov (Satish Balay) Date: Mon, 20 Mar 2006 13:13:33 -0600 (CST) Subject: divergence? In-Reply-To: <1224.160.75.78.141.1142881772.squirrel@www.be.itu.edu.tr> References: <4267.160.75.90.192.1140370474.squirrel@www.be.itu.edu.tr> <1224.160.75.78.141.1142881772.squirrel@www.be.itu.edu.tr> Message-ID: On Mon, 20 Mar 2006, buket at be.itu.edu.tr wrote: > Hello again, > > I want to compare the iterative methods with direct methods in terms of time. > What functions can I use for direct solution? -pc_type lu -ksp_type preonly To use parallel direct solvers - you'll have to install PETSc with one of the direct solver external packages [SuperLU_DIST, spooles, MPUMPS] With these - you can do - for eg: -mat_type superlu_dist -pc_type lu -ksp_type preonly Satish From knepley at gmail.com Mon Mar 20 14:08:48 2006 From: knepley at gmail.com (Matthew Knepley) Date: Mon, 20 Mar 2006 14:08:48 -0600 Subject: divergence? In-Reply-To: <1224.160.75.78.141.1142881772.squirrel@www.be.itu.edu.tr> References: <4267.160.75.90.192.1140370474.squirrel@www.be.itu.edu.tr> <1224.160.75.78.141.1142881772.squirrel@www.be.itu.edu.tr> Message-ID: You can use -pc_type lu -ksp_type preonly. There are also third-party packages like MUMPS which you can install automatically with configure. Matt On 3/20/06, buket at be.itu.edu.tr wrote: > > Hello again, > > I want to compare the iterative methods with direct methods in terms of > time. > What functions can I use for direct solution? > > Best Regards, > Buket Benek > > > -- "Failure has a thousand explanations. Success doesn't need one" -- Sir Alec Guiness -------------- next part -------------- An HTML attachment was scrubbed... URL: From billy at dem.uminho.pt Wed Mar 22 14:07:06 2006 From: billy at dem.uminho.pt (billy at dem.uminho.pt) Date: Wed, 22 Mar 2006 20:07:06 +0000 Subject: VecGetValues. Message-ID: <1143058026.4421ae6ae8c54@serv-g1.ccom.uminho.pt> VecGetValues(Vec x,PetscInt ni,const PetscInt ix[],PetscScalar y[]) The documentation says ix is global index, isn't it the local index? Billy From balay at mcs.anl.gov Wed Mar 22 14:15:31 2006 From: balay at mcs.anl.gov (Satish Balay) Date: Wed, 22 Mar 2006 14:15:31 -0600 (CST) Subject: VecGetValues. In-Reply-To: <1143058026.4421ae6ae8c54@serv-g1.ccom.uminho.pt> References: <1143058026.4421ae6ae8c54@serv-g1.ccom.uminho.pt> Message-ID: On Wed, 22 Mar 2006, billy at dem.uminho.pt wrote: > > > VecGetValues(Vec x,PetscInt ni,const PetscInt ix[],PetscScalar y[]) > > The documentation says ix is global index, isn't it the local index? No - its the global index. Internally it subtracts 'rstat' - to get the local offset [within the array used for internal storage]. You can check the code in VecGetValues_MPI() [src/vec/vec/impls/mpi/pdvec.c] Satish From bsmith at mcs.anl.gov Wed Mar 22 14:17:33 2006 From: bsmith at mcs.anl.gov (Barry Smith) Date: Wed, 22 Mar 2006 14:17:33 -0600 (CST) Subject: VecGetValues. In-Reply-To: <1143058026.4421ae6ae8c54@serv-g1.ccom.uminho.pt> References: <1143058026.4421ae6ae8c54@serv-g1.ccom.uminho.pt> Message-ID: Billy, It is the global index. But, yes, you can only "get" values that belong to your process. Barry On Wed, 22 Mar 2006, billy at dem.uminho.pt wrote: > > > VecGetValues(Vec x,PetscInt ni,const PetscInt ix[],PetscScalar y[]) > > The documentation says ix is global index, isn't it the local index? > > > Billy > > From nilserik at gmail.com Wed Mar 29 14:57:03 2006 From: nilserik at gmail.com (=?ISO-8859-1?Q?Nils_Erik_Svang=E5rd?=) Date: Wed, 29 Mar 2006 22:57:03 +0200 Subject: SNES Problem In-Reply-To: References: <82f936c20602270607t775d7e03o6a37afa4c0b3d2a8@mail.gmail.com> <82f936c20603171527x111b7954rb3998128b34cdde7@mail.gmail.com> <82f936c20603171605t2731e3b1g24ca578ac6196cc4@mail.gmail.com> <82f936c20603200126m6913dc24r5ac07f579a2fcb2c@mail.gmail.com> <82f936c20603200536u1505d435i273a035c3a59f11b@mail.gmail.com> <82f936c20603200658g69dcee1al72cf75b11449865b@mail.gmail.com> Message-ID: <82f936c20603291257t186c3d8fl8b283cc035663c03@mail.gmail.com> Barry, You wrote this a couple of mails back: SNES works by computing p = -approxinv(J)*F(uold) and then does a line search on unew = uold + lambda*p to get the new u. First it uses a test value of 1 for lambda so it tries to compute F(uold + p). It is possible that uold + p has some "non-physical" values in it. Does SNES do the same thing when -snes_mf is used? /nisse On 3/20/06, Barry Smith wrote: > > Nisse, > > Is there any way you can bundle everything up so you could send > it to me and I could easily compile it and make? This approach to > trying to discover the problem is taking too long. > > Barry > > > On Mon, 20 Mar 2006, Nils Erik Svang?rd wrote: > > > Barry, > > I have now rewritten the code > > > > do 1:i > > do 1:j > > do 1:k > > l= old_numbering > > m++ newnumbering > > xx(1,m)=RO(l) > > xx(2,m)=RU(l) > > ... > > end dos > > > > The vectors are created by running, where m is the number of > > iterations in the do loop times 7 because we have 7 diffs to solve > > (DOF = 7). > > > > m=m*7 > > call VecCreateSeq(PETSC_COMM_SELF,m,x,ierr) > > > > could this be a source of trouble, solving 7 diffs at the same time? > > > > Petsc still supply get_DRO with strange values, RK crashes directly > > but beuler does about the double amount of iterations but still doesnt > > to complete a timestep. > > > > /nisse > > > > > > On 3/20/06, Barry Smith wrote: > >> > >> 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 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 wrote: > >>>>> On 3/18/06, Barry Smith 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 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 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 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 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 > >>> > >>> > >> > > > > > > -- > > 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 From knepley at gmail.com Wed Mar 29 16:34:52 2006 From: knepley at gmail.com (Matthew Knepley) Date: Wed, 29 Mar 2006 16:34:52 -0600 Subject: SNES Problem In-Reply-To: <82f936c20603291257t186c3d8fl8b283cc035663c03@mail.gmail.com> References: <82f936c20602270607t775d7e03o6a37afa4c0b3d2a8@mail.gmail.com> <82f936c20603171527x111b7954rb3998128b34cdde7@mail.gmail.com> <82f936c20603171605t2731e3b1g24ca578ac6196cc4@mail.gmail.com> <82f936c20603200126m6913dc24r5ac07f579a2fcb2c@mail.gmail.com> <82f936c20603200536u1505d435i273a035c3a59f11b@mail.gmail.com> <82f936c20603200658g69dcee1al72cf75b11449865b@mail.gmail.com> <82f936c20603291257t186c3d8fl8b283cc035663c03@mail.gmail.com> Message-ID: On 3/29/06, Nils Erik Svang?rd wrote: > > Barry, > You wrote this a couple of mails back: > > SNES works by computing p = -approxinv(J)*F(uold) and > then does a line search on unew = uold + lambda*p to get the > new u. First it uses a test value of 1 for lambda so it > tries to compute F(uold + p). It is possible that uold + p > has some "non-physical" values in it. > > Does SNES do the same thing when -snes_mf is used? Yes, the line search is independent of the Jacobian approximation. Matt /nisse > > On 3/20/06, Barry Smith wrote: > > > > Nisse, > > > > Is there any way you can bundle everything up so you could send > > it to me and I could easily compile it and make? This approach to > > trying to discover the problem is taking too long. > > > > Barry > -- "Failure has a thousand explanations. Success doesn't need one" -- Sir Alec Guiness -------------- next part -------------- An HTML attachment was scrubbed... URL: From li76pan at yahoo.com Thu Mar 30 07:45:27 2006 From: li76pan at yahoo.com (li pan) Date: Thu, 30 Mar 2006 05:45:27 -0800 (PST) Subject: simple question Message-ID: <20060330134527.75291.qmail@web36803.mail.mud.yahoo.com> sorry, I forgot it. Just want to be sure. How could I make *.so file. There are only *.a files in my linux_gnu directory. best pan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From balay at mcs.anl.gov Thu Mar 30 10:05:46 2006 From: balay at mcs.anl.gov (Satish Balay) Date: Thu, 30 Mar 2006 10:05:46 -0600 (CST) Subject: simple question In-Reply-To: <20060330134527.75291.qmail@web36803.mail.mud.yahoo.com> References: <20060330134527.75291.qmail@web36803.mail.mud.yahoo.com> Message-ID: You have to configure PETSc with the additional option --with-shared=1. This is no longer the default as sharedlibary build doesn't work cleanly on some arches/compiler combinations. [but should work fine with linux. BTW: what version of PETSc are you using? linux_gnu some old pre-configure version. In this case the targets should already be there - and you might just need to do: make shared Satish On Thu, 30 Mar 2006, li pan wrote: > sorry, I forgot it. Just want to be sure. How could I > make *.so file. There are only *.a files in my > linux_gnu directory. > > best > > pan > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > From nilserik at gmail.com Fri Mar 31 02:53:58 2006 From: nilserik at gmail.com (=?ISO-8859-1?Q?Nils_Erik_Svang=E5rd?=) Date: Fri, 31 Mar 2006 10:53:58 +0200 Subject: SNES Problem In-Reply-To: References: <82f936c20602270607t775d7e03o6a37afa4c0b3d2a8@mail.gmail.com> <82f936c20603171605t2731e3b1g24ca578ac6196cc4@mail.gmail.com> <82f936c20603200126m6913dc24r5ac07f579a2fcb2c@mail.gmail.com> <82f936c20603200536u1505d435i273a035c3a59f11b@mail.gmail.com> <82f936c20603200658g69dcee1al72cf75b11449865b@mail.gmail.com> <82f936c20603291257t186c3d8fl8b283cc035663c03@mail.gmail.com> Message-ID: <82f936c20603310053j565d1bb5pfded583e483e7ce5@mail.gmail.com> This might be a stupid question: I create a Vec using VecCreateSeq(comm_self,size,X,ierr) I fill the X vector with PetscScalar values using PetscScalar lx_v(0:1) PetscOffset lx_i call VecGetArray(X,lx_v,lx_i,ierr) call SetValues(lx_v(lx_i),ierr) call VecRestoreArray(X,lx_v,lx_i,ierr) And set values puts the PetscScalars in th right place: PetscScalar xx(7,1:549000) do x=1,NKL-1 do y=1,NJL-1 do z=1,NIL-1 L=x+NIL*(y-1)+NIL*NJL*(z-1) xx(1,L)=RO(L) xx(2,L)=RU(L) xx(3,L)=RV(L) xx(4,L)=RW(L) xx(5,L)=ET(L) xx(6,L)=RQ(L) xx(7,L)=REPS(L) end do end do end do Now the Vec object have lots of values and I want to solve the system of non-linear equations. SNES does this by using a approximated jacobian and doing some newtonsteps. I dont understand how SNES can use the values in the Vec without knowing which values are connected, now there is 7 diffrent arrays in 3 dimensions in the Vec. I hope this question wasnt to blurry. /nisse On 3/30/06, Matthew Knepley wrote: > > > > On 3/29/06, Nils Erik Svang?rd wrote: > > Barry, > > You wrote this a couple of mails back: > > SNES works by computing p = -approxinv(J)*F(uold) and > then does a line search on unew = uold + lambda*p to get the > new u. First it uses a test value of 1 for lambda so it > tries to compute F(uold + p). It is possible that uold + p > has some "non-physical" values in it. > > Does SNES do the same thing when -snes_mf is used? > > Yes, the line search is independent of the Jacobian approximation. > > Matt > > > > /nisse > > > > On 3/20/06, Barry Smith wrote: > > > > > > Nisse, > > > > > > Is there any way you can bundle everything up so you could send > > > it to me and I could easily compile it and make? This approach to > > > trying to discover the problem is taking too long. > > > > > > Barry > > > > > -- > "Failure has a thousand explanations. Success doesn't need one" -- Sir Alec > Guiness -- Nils-Erik Svang?rd E-Mail: nilserik at gmail.com MSN: schweingaard at hotmail.com Skype: schweingaard Mobil: +46-(0)70-3612178