Author Topic: What does a local timestep factor (LTF) in the CFX solver mean?  (Read 13665 times)

Offline pitney1

  • Jr. Member
  • **
  • Posts: 65
  • Reputation: +0/-0
  • Searching for solution
    • View Profile
Advertisement
What does a local timestep factor (LTF) in the CFX solver mean?

Offline william

  • Full Member
  • ***
  • Posts: 159
  • Reputation: +15/-0
  • Know it, share it.
    • View Profile
Re: What does a local timestep factor (LTF) in the CFX solver mean?
« Reply #1 on: May 11, 2012, 10:38:53 PM »
When you run local timestep factor the solver does not assemble a pseudo transient term because it is not needed. Local timestep factor is a different approach (to the default) for controlling how fast we solve the equations in the non-linear loop. This factor is applied to the central coefficient of the linear equation only after the linear equation has been completely assembled, with all it's contributions. eg: advection, diffusion, gradient & body forces in the momentum equation. Each of these individual terms will contribute to the central coefficient and imply a grid/physics based timescale.

The numerical method is not explicit when you run this way. A correct assessment would be to say that usage of the local timestep factor can limit the rate at which you can approach steady state solution to an explicit timescale, for each coefficient loop iteration. We still assemble & solve coupled implicit linear equations; however, once the LTF is applied the problem can only go forward at the rate of the smallest timescale for each iteration. This usually means you are limited by regions where the grid is "fine".

Local timestep factor, like the pseudo timescale approach, is a relaxation in the sense that it controls how fast the solution can change at each coefficient loop. This is the traditional definition of under relaxation. While an equation for LTF may not be written in the form phi = phi_new*urf + (1-urf)*phi_old it could be rewritten that way.

When you run in the default mode, with a pseudo transient, there is a transient term. If you use a small timestep then the central coefficient, Ap, will be large (because the transient coefficient is rho*vol/dt) and the case can only be solved at the rate allowed by that small timestep. There is no implied timescale in this case because you are telling the code what that timescale is.

With localtimestep factor, when you multiply the central coefficient by (1+1/E),we modify the "implied" timescale in the linear equation. This is similar to the pseudo transient except that the unmodified "raw" timescale is implied by the Ap that we came up with by assembling advection, diffusion, gradient, etc... If E is large (>>1) then you basically get the raw "implied" timescale. If E is small, say O(1), then you get a modification to the raw implied timescale.

In an equation form the new Ap is this:

Ap_new = Ap_raw * (1 + 1/E) = Ap_raw + Ap_raw/E (1)

The term "Ap/E" can be interpreted as a transient term because it has the same form as "rho*vol/dt". So, the timescale implied by the local timestep factor is:

rho*vol/dt = Ap_raw/E (2)

or

dt = rho*vol*E/Ap_raw (3)

Several properties can be stated by inspecting equation (3):
- Large E (>>1) implies a larger timestep, maximum is the amount given by Ap_raw though.
- Small E, O(1), implies a smaller timestep
- The timestep will spatially vary throughout the volume
- The timestep will be small where you have small control volumes, larger where the control volumes are larger
- Most practical boundary layer grids don't work well with local timestep factor because the volumes in the boundary layer tend to be so small relative to the volumes in the core flow regions.
- High aspect ratio grids also don't work so well because the raw Ap will be significant in these regions and if you use by an O(1) E you make the modified Ap even larger which slows things down even more.
- Because of the last two points you can generally say that LTF can cause you nowhere because it freezes the solution where the grid volumes are large. It might make things even worse in some cases because you are not actually solving the problem.

A reference for the implementation it the following paper:

J. P. Van Doormaal and G. D. Raithby.
Enhancements of the simple method for predicting incompressible fluid flows.
Numerical Heat Transfer, 7:147-163, 1984