
[Sponsors] 
How can Implicit Time Marching algorithms NOT be Time Accurate?! 

LinkBack  Thread Tools  Display Modes 
July 30, 2010, 07:19 
How can Implicit Time Marching algorithms NOT be Time Accurate?!

#1 
New Member
Freddie Sizer
Join Date: Apr 2009
Posts: 19
Rep Power: 10 
Sponsored Links
The nature of the scramjet combustion chamber gives rise to an oscillatory motion. Using the sceme that I have I am unable to reach a well converged solution. The algorithm is Line Implicit with a choice of local or global time steps. My question is that I am unsure how a code that time marches can be time inaccurate? Can one of the numerical methods experts please explain this to me? Thank you. 

Sponsored Links 
July 30, 2010, 08:55 

#2 
Senior Member
Join Date: Jul 2009
Posts: 245
Rep Power: 12 
Why should it necessarily be time accurate? Timemarching implies that you are essentially extrapolating forward in time. The accuracy of that extrapolation is going to be determined by the starting point of the approximate solution, the slope of the function (again approximate), and how far forward you extrapolate (the time step). This of course does not even bring to consideration the approximation error due to such things as roundoff error or the implementation of boundary conditions or other possible sources of error.


July 30, 2010, 09:56 
Unsteady case?

#3 
New Member
Freddie Sizer
Join Date: Apr 2009
Posts: 19
Rep Power: 10 
Thank you for your reply agd.
So in essence, you are using values in the current cell and surrounding cells, such as rho, u,v,w etc. at (t) to then calculate the new values at (t+1). If this is the case my logic says that when you then recalculate at (t+1) the values should then be reasonably accurate, especially in an inviscid example. I don't think I'm explaining myself very well, so I'll try to explain what I am doing in a bit more detail: I have a paper that reports an experiment carried out in a gun tunnel. The paper gives schlieren images at different time steps during the duration of the wind tunnel run time (of order ~15ms). I am trying to numerically replicate these results using a line implicit, second order, time marching solution. The code seeks a steady solution as far as I understand. How can I use this type of code to obtain an accurate representation of the Schlieren images. Particularly if the solution is unsteady. I have thought that I might be able to stop the code at a certain time to produce a snapshot, but if it is not time accurate, then this snapshot will not be accurate. Otherwise if I wait for the code to converge I can't understand what it will be converging to (again assuming it is unsteady). An explanation to this would be most helpful because at the moment my head is unsteady!!! 

July 30, 2010, 10:42 

#4 
New Member
Anonymous
Join Date: Jul 2010
Posts: 3
Rep Power: 9 
Are you using local or global time stepping?
Local time stepping  the max stable time step based on the specified CFL number will be used at each grid point. This means each point is advancing in time at a different rate. This is not a time accurate method. If the flow is steady, you will likely converge to a steady answer. However, there is potential for a numerical unsteadiness because each point is advancing at different rates. Global time stepping  Every point advances at the same global time step. This is a time accurate method. You will still get a steady answer if the flow is steady or if you do not adequately resolve the flow, or if your solution is too dissipative. If you are running local time stepping and not converging, a good check is to switch to global time stepping. This sometimes removes the numerical oscillations that can occur and helps you converge to a steady state. If you are running global time stepping and getting an unsteady answer and you think that the flow really is unsteady, then you need to do some sort of averaging to compare to the experiment (assuming the experimentalists used some sort of averaging also). 

July 30, 2010, 10:57 

#5 
Senior Member
Join Date: Jul 2009
Posts: 245
Rep Power: 12 
Not knowing the formulation of the algorithm you are using, all I can do is speak in generalities. Most implicit solvers that I am familiar with basically follow the pattern of expressing the change from time n to time n+1 as a perturbation from the solution at time n developed by linearizing the conservation equations about time level n. Thus you get (formally) a set of linear equations (after discretization) that look like
A*dx = R, where the right hand side R is the discrete representation of conservation equations at time level n. Obviously, if the state x at time n satisfies the conservation equations, then R should equal zero, and then dx = 0, so x(n+1) = x(n) and so forth at convergence. Obviously, an unsteady flowfield would not yield this result. If the physics are steady but your simulation is not, then there are a whole host of possible reasons why your simulation is acting odd. This is a very rough outline, but it should give you a good idea of why things don't always go as planned. The discrete representation of R contains discretization errors, the solution of the linear system is generally an iterative operation that contains its own errors, and boundary conditions have to be included somehow along with their commensurate approximations. Additionally, no implicit algorithm that I am aware of is truly unlimited in timestep size. I am not sure how familiar you are with the code you are using, but based on your posts it seems like you are not wellversed in how it performs for different problems. It can be very useful to run a variety of simple test cases of wellestablished flows to gain experience with a code and get to understand the peculiarities associated with any algorithm. If I has to wager a guess right now, and this is truly a wild shot, I would recommend dropping the time step down until you are sure that it is smaller than any relevant physical time scale (assuming your code can handle unsteady flows) and see if it converges to the steady physical solution. It may be for your problem (flow in a gun tunnel) that an explicit scheme might be preferable if the requisite time step is small enough. 

August 3, 2010, 18:33 
Thank you!

#6 
New Member
Freddie Sizer
Join Date: Apr 2009
Posts: 19
Rep Power: 10 
Thank you both so much. Your help is much appreciated!


August 5, 2010, 11:06 

#7 
Senior Member
Join Date: Feb 2010
Posts: 145
Rep Power: 10 
agd's recommendation to drop the time step down is a good one. f_sizer, my guess is that you might be confusing the concepts of stability versus accuracy. In general, implicit time integration algorithms are stable. This is in contract to explicit time integration which has a stability criteria. However, "grid independence" for the time step must also be demonstrated just as grid independence needs to be demonstrated for the mesh. Good luck!


August 19, 2010, 09:32 

#8 
New Member
Freddie Sizer
Join Date: Apr 2009
Posts: 19
Rep Power: 10 
Thank you Jade M. I don't suppose you know how to estimate cfl numbers for use with implicit algorithms do you?
I understand fully the explicit way of life, but am a bit fuzzy on why implicit algorithms can handle much higher cfl numbers? 

August 19, 2010, 09:40 

#9 
Senior Member
Join Date: Feb 2010
Posts: 145
Rep Power: 10 
Which software are you using, CFX? I'm sorry as I cannot tell which forum this is posted in.
What type of analysis are you conducting, LES? As far as implicit algorithms being able to handle higher CFL numbers, I suppose it is probably really due to numerical stability issues. Implicit methods simply have less restrictions on them. I know this is not a precise explanation. I'll see if I can find some information. It looks like there is some good discussion at http://www.cfdonline.com/Forums/mai...condition.html In particular, for practical use, see the very last post by John Chien. There is also some good information on wikipedia at http://en.wikipedia.org/wiki/Courant...Lewy_condition Last edited by Jade M; August 19, 2010 at 11:24. 

August 19, 2010, 10:14 

#10 
Senior Member
Join Date: Feb 2010
Posts: 145
Rep Power: 10 
For LES with implicit time integration, the CFX documentation states
• For accuracy, the average Courant (or CFL) number should be in the range of 0.51. Larger values can give stable results, but the turbulence may be damped. For compressible flows where the acoustic behavior is being modeled (e.g., for noise calculations), this conclusion still holds, but for the CFL number based on the acoustic velocity as well as the convective velocity. • 1,000  10,000 time steps are typically required for getting converged statistics. More steps are required for second order quantities (for example, variances) than for means. Check the convergence of the statistics. For a vortexshedding problem, several cycles of the vortex shedding are required. • The implicit coupled solver used in CFX requires the equations to be converged within each time step to guarantee conservation. The number of coefficient loops required to achieve this is a function of the time step size. With CFL numbers of order 0.51, convergence within each time step should be achieved quickly. It is advisable to test the sensitivity of the solution to the number of coefficient loops, to avoid using more coefficient loops (and hence longer run times) than necessary. LES tests involving incompressible flow past circular cylinders indicate that one coefficient loop per time step is sufficient if the average CFL number is about 0.75. If the physics or geometry is more complicated, additional coefficient loops (35) may be required. Time step sizes which require more coefficient loops than this will tend to degrade solution accuracy. Since the Courant number is equal to U*Dt/Dx, the time step Dt can be calculated based on the grid spacing Dx and the characteristic velocity U. Demonstrating grid independence prior would probably minimize computational time. Last edited by Jade M; August 19, 2010 at 12:15. 

Thread Tools  
Display Modes  


Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
TimeVaryingMappedFixedValue  irishdave  OpenFOAM Running, Solving & CFD  29  May 3, 2017 08:59 
Convergence moving mesh  lr103476  OpenFOAM Running, Solving & CFD  30  November 19, 2007 15:09 
Physical Reason for stability of Implicit Schemes?  radhakrishnan  Main CFD Forum  25  December 7, 2000 16:25 
Implicit vs. Explicit  Praveen C.  Main CFD Forum  1  December 14, 1999 10:35 
unsteady calcs in FLUENT  Sanjay Padhiar  Main CFD Forum  1  March 31, 1999 12:32 
Sponsored Links 