
[Sponsors] 
May 10, 2006, 09:51 
time_step, implicit scheme, number of iterations

#1 
Guest
Posts: n/a

Hello to eveybody!
I am trying to solve 3D viscous incompressible NavierStokes equations. For it , I use a first order incremental projection scheme with finite element method. The scheme is implicit with linearized convection term. So, as I have understood by the emails posted previous to this one, the time step value must only guarantee the accuracy I want for my solution since I am using an implicit technique. So, CFL (a convective stability) and diffusive stability constraint ( visc*incrt/((incrx)^2)<=(1/8)) don't need to be imposed since I am working with an implicit method. Anyway, in my domain, if I apply CFL along with diffusive stability constraint, I obtain a time_step_value <= 5e5. Some results: If I use time_step_value =1e3 or 1e4, with 10000 iterations, it doesn't reach the right solution (the steady one). If I take time_step_value=1e5, it takes around 7700 iterations to reach the right solution. If I choose time_step_value=1e6, it takes around 3700 iterations to reach the right solution (i.e. less than a half of the previous one with a smaller time_step_value¿?) I would like someone to explain to me this behaviour or any advice about possibly misunderstood concepts. Thankyou for your time. Regards Isa 

May 11, 2006, 02:50 
Re: time_step, implicit scheme, number of iteratio

#2 
Guest
Posts: n/a

Dear Isa,
I think there is a possible explanation for this. To begin with, implicit schemes are not "unconditionally stable" as many say. You are right when you say that the CFL constraint need not be used, but this "unconditional stability" is purely from the viewpoint of a linear stability analysis. So, there is definitely an upper bound on the time step being used. Next, the time step you use need not guarantee any temporal accuracy if you are looking at steady state solutions. It needs to guarantee you only stability. However, it does not mean that numerically any time step can be used. In fact what possibly happens in your case with 1e3 or 1e4 is essentially some possible instability, which could actually show up at a late r time ( more than 10000 iter, say 12000 or so). At lower time steps, you are getting the right solution, but seemingly faster at a lower time step. Well, this is not quite right, but you could possibly explain it this way. There is some delt say delt*, below which there is stability and above which there is instability. Possibly your 1e3 and 1e4 are bigger than delt*. They may show a code blow up at a later time. Moreover, 1e5 could be in a small vicinity of delt*, so could be converging to the steady solution. 1e6 is much smaller than delt* and therefore again converges, but at a faster rate. You could possibly look at the following: 1. The residue fall plots. See if the fall is smooth or not. If there are considerable increases and decreases in the plot, it is a sign of loss in stability. Check for the Cd convergence in these cases. This is also a good indicator of how time step affects the solution. 2. Check for lower time steps than 1e6. You must see that you are taking more time, in tune with the arguments that you are taking more time steps. 3. If your problem is a complex one, I suggest moving to a simpler one to make observations more clearer. Also, you could try changing the grid too. All that I would hypothesise is that provided your code is truly bugfree, chances are that there are nonlinear stabilities picking up, that seems to hamper the convergence to the solution. This is causing poor convergence (1e5) or no convergence at all(1e3 or 1e4). However, any implicit scheme must allow for larger time steps than corressponding explicit scheme and be much faster fo a larger permissible time step, which seems to have been violated in your case, which is a disturbing situation. Please note that the explanation is a HYPOTHESIS, and I have reasons why it could be true and reasons why it could be wrong too. In my part, if I were to give a frank opinion on the limited information given to me in this post, I would suspect the code more than the theory. Hope this helps Regards, Ganesh 

May 11, 2006, 03:53 
Re: time_step, implicit scheme, number of iteratio

#3 
Guest
Posts: n/a

I have seen something that might be similar with one of my fractional step codes (2D unstructured FVM).
My initial code used a semiimplicit update  RK2 for advection and CrankNicholson for viscous. As you said, the CFL stability requirements need to be satisfied here. I was playing around with fully implicit updates (2nd order) for both the linear and nonlinear terms and again as you said effectively removed any timestep restrictions. The catch was that when I used much larger timesteps with the implicit code (CFL of 50 as opposed to 2), I started to get different results at steadystate. The results were less accurate with the fully implicit code (but they still converged). If I used the same step size with both codes I got equivalent results... Basically, I couldn't sort this out properly and put the implicit code on the shelf. I explored the problem a little and it seemed to me that the pressure gradient on the boundary was weakly coupled to the step size. I was thinking that this might be the numerical boundary layer in the pressure that people talk about with projection methods... Anyway, this doesn't get you any closer to a solution, sorry. If you or anyone else has some idea how to fix this can you let me know too. Darren 

May 11, 2006, 12:27 
Re: time_step, implicit scheme, number of iteratio

#4 
Guest
Posts: n/a

First of all, thank you, Ganesh and Darren, for your replies. I would like to reply according to recommendations suggested by Ganesh in order to manage to find the problem.
Ganesh said: 1. The residue fall plots. See if the fall is smooth or not. If there are considerable increases and decreases in the plot, it is a sign of loss in stability. Check for the Cd convergence in these cases. This is also a good indicator of how time step affects the solution. I know the method converges because the solution, in the end, is the good one and the residuals go down as the number of iterations go up without many oscilations. But I don't really know what you mean with "Cd convergence". Could you explain it to me, please? (sorry) 2. Check for lower time steps than 1e6. You must see that you are taking more time, in tune with the arguments that you are taking more time steps. You are right, if I run the program with 1e7, it takes more time, as it had to happen. But what strikes me it is the fact of slower convergence with permissible larger time step. I have looked into my code to find the bug but I cannot see where the problem is. As I said before, I am using a first order Backward Euler, I am not sure if the use of second order Backward Euler scheme could solve the problem. More features: Simulation is running over a 3D rectangular tube of Re=68, with 512 elements. Thankyou for your help and time. Best regards Isa 

Thread Tools  
Display Modes  


Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
icoLagrangianFoam OF1.6 myNewParticleSolver  heavy_user  OpenFOAM  16  February 11, 2012 05:15 
directMapped problem  panda60  OpenFOAM Bugs  4  July 8, 2010 10:23 
Differences between serial and parallel runs  carsten  OpenFOAM Bugs  11  September 12, 2008 11:16 
Convergence moving mesh  lr103476  OpenFOAM Running, Solving & CFD  30  November 19, 2007 14:09 
Modeling in micron scale using icoFoam  m9819348  OpenFOAM Running, Solving & CFD  7  October 27, 2007 00:36 