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

How can Implicit Time Marching algorithms NOT be Time Accurate?!

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

Reply
 
LinkBack Thread Tools Display Modes
Old   July 30, 2010, 07:19
Default How can Implicit Time Marching algorithms NOT be Time Accurate?!
  #1
New Member
 
Freddie Sizer
Join Date: Apr 2009
Posts: 19
Rep Power: 8
f_sizer is on a distinguished road
This is probably a very simple question for someone in the know, but I'm trying to simulate flow in a Scramjet for my final year project and can not reach a converged solution.

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.
f_sizer is offline   Reply With Quote

Old   July 30, 2010, 08:55
Default
  #2
agd
Senior Member
 
Join Date: Jul 2009
Posts: 191
Rep Power: 7
agd is on a distinguished road
Why should it necessarily be time accurate? Time-marching 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 round-off error or the implementation of boundary conditions or other possible sources of error.
agd is offline   Reply With Quote

Old   July 30, 2010, 09:56
Default Unsteady case?
  #3
New Member
 
Freddie Sizer
Join Date: Apr 2009
Posts: 19
Rep Power: 8
f_sizer is on a distinguished road
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!!!
f_sizer is offline   Reply With Quote

Old   July 30, 2010, 10:42
Default
  #4
New Member
 
Anonymous
Join Date: Jul 2010
Posts: 3
Rep Power: 6
LESter is on a distinguished road
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).
LESter is offline   Reply With Quote

Old   July 30, 2010, 10:57
Default
  #5
agd
Senior Member
 
Join Date: Jul 2009
Posts: 191
Rep Power: 7
agd is on a distinguished road
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 time-step 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 well-versed in how it performs for different problems. It can be very useful to run a variety of simple test cases of well-established 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.
agd is offline   Reply With Quote

Old   August 3, 2010, 18:33
Default Thank you!
  #6
New Member
 
Freddie Sizer
Join Date: Apr 2009
Posts: 19
Rep Power: 8
f_sizer is on a distinguished road
Thank you both so much. Your help is much appreciated!
f_sizer is offline   Reply With Quote

Old   August 5, 2010, 11:06
Default
  #7
Senior Member
 
Join Date: Feb 2010
Posts: 145
Rep Power: 8
Jade M is on a distinguished road
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!
Jade M is offline   Reply With Quote

Old   August 19, 2010, 09:32
Default
  #8
New Member
 
Freddie Sizer
Join Date: Apr 2009
Posts: 19
Rep Power: 8
f_sizer is on a distinguished road
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?
f_sizer is offline   Reply With Quote

Old   August 19, 2010, 09:40
Default
  #9
Senior Member
 
Join Date: Feb 2010
Posts: 145
Rep Power: 8
Jade M is on a distinguished road
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
CFL Condition
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.
Jade M is offline   Reply With Quote

Old   August 19, 2010, 10:14
Default
  #10
Senior Member
 
Join Date: Feb 2010
Posts: 145
Rep Power: 8
Jade M is on a distinguished road
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.5-1. 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 vortex-shedding 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.5-1, 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 (3-5) 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.
Jade M is offline   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
TimeVaryingMappedFixedValue irishdave OpenFOAM Running, Solving & CFD 28 May 28, 2015 13:37
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


All times are GMT -4. The time now is 21:13.