time_step, implicit scheme, number of iterations
 

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

Re: time_step, implicit scheme, number of iteratio
 

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

Re: time_step, implicit scheme, number of iteratio
 

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

Re: time_step, implicit scheme, number of iteratio
 

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