CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Main CFD Forum

time_step, implicit scheme, number of iterations

Register Blogs Members List Search Today's Posts Mark Forums Read

Reply
 
LinkBack Thread Tools Display Modes
Old   May 10, 2006, 09:51
Default time_step, implicit scheme, number of iterations
  #1
Isa
Guest
 
Posts: n/a
Hello to eveybody!

I am trying to solve 3D viscous incompressible Navier-Stokes 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 e-mails 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 <= 5e-5.

Some results: If I use time_step_value =1e-3 or 1e-4, with 10000 iterations, it doesn't reach the right solution (the steady one). If I take time_step_value=1e-5, it takes around 7700 iterations to reach the right solution. If I choose time_step_value=1e-6, 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. Thank-you for your time. Regards Isa
  Reply With Quote

Old   May 11, 2006, 02:50
Default Re: time_step, implicit scheme, number of iteratio
  #2
ganesh
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 1e-3 or 1e-4 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 1e-3 and 1e-4 are bigger than delt*. They may show a code blow up at a later time. Moreover, 1e-5 could be in a small vicinity of delt*, so could be converging to the steady solution. 1e-6 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 1e-6. 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 bug--free, chances are that there are non--linear stabilities picking up, that seems to hamper the convergence to the solution. This is causing poor convergence (1e-5) or no convergence at all(1e-3 or 1e-4). 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
  Reply With Quote

Old   May 11, 2006, 03:53
Default Re: time_step, implicit scheme, number of iteratio
  #3
Darren
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 semi-implicit update - RK2 for advection and Crank-Nicholson 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 non-linear terms and again as you said effectively removed any time-step restrictions.

The catch was that when I used much larger time-steps with the implicit code (CFL of 50 as opposed to 2), I started to get different results at steady-state. 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
  Reply With Quote

Old   May 11, 2006, 12:27
Default Re: time_step, implicit scheme, number of iteratio
  #4
Isa
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 1e-6. 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 1e-7, 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.

Thank-you for your help and time.

Best regards Isa

  Reply With Quote

Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


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


All times are GMT -4. The time now is 17:02.