fds accuracy/convergence/stability
Julien
I am a fluid mechanics engineer working for the parisian metro. We are
currently using FDS to simulate fire scenarios in trains and to
improve the smoke control in our facilities. We are also working
(numerically and experimentally) on the pyrolysis model to simulate
the behaviour of our materials. I can't say that I am an old FDS user
but I've been working on Fluent since 4 years.
I have been recently observing some oscillations on simulations
devices results which made me question the accuracy of the solution
provided by FDS and the stabilty of the model. It would really help me
if you could answer these questions.
Contrary to Fluent, FDS uses a non-iterative process (or a single-
iteration process) to solve the hydrodynamic equation system on each
time-step. The time-step is calculated thanks to the CFL condition
which is a necessary but not sufficient condition to ensure
convergence. So there is no criteria to evaluate the results provided
at the end of the time step. I can check the CFL number value given in
the .out file (and lock the time step at a low value) but I have to
trust FDS on the quality of the results.
1- Am I making mistakes in my analysis ?
2- Can a lack of convergence or a lack of stability be the reason why
I am observing strange oscillations on my results ?
3- How is working the hydrodynamic resolution algorithm ? (Maybe I
didn't look well in the documentation but I couldn't find the name of
the algorithm)
4- How can I be sure that the solution provided at the end of each
time-step is right ? And more globally, are there numerical criterias
(as in using Fluent) to evaluate the quality of the results (only from
a numerical point of view, of course I can compare to experimental
results) ?
I know that this kind of unstabilities can be particularly important
when energy (fire) is introduced in the system. It tends to make the
establishment of a solution difficult. That's why the time-step is
always reduced by FDS when a fire starts. But is this enough to affirm
that the solution is correct ?
Regards
Kevin
equations. FDS uses LES (Large Eddy Simulation). The oscillations that
you observe are not numerical instabilities, but rather turbulent
fluctuations that are captured by the model. This is not evidence of
error -- this is reality. If you look at time-resolved experimental
fire test data, you will see similar oscillations.
FDS uses a non-iterative pressure solver to properly couple the
pressure and velocity fields. It is not a SIMPLE-type algorithm. FDS
is second order accurate in space and time, thus better accuracy is
achieved with finer grids. A grid resolution study, in addition to
comparisons to large scale fire test data, is a good way to ensure
that your calculations are accurate enough for your application.
rmcdermo
Just to add to what Kevin said, it is possible that the oscillations
you are observing are a result of the difference between a RANS and
LES calculation. But let's assume for the moment that you are running
LES with Fluent (is this correct?), there are subtleties in your
questions that are worth discussing.
The first is the meaning of the term 'convergence'. There are two
very different definitions of this term that are easily confused:
1. A numerical scheme is said to be 'consistent' if the discretized
equations recover the partial differential equation (PDE) of interest
as dx and dt --> 0. The Lax convergence theorem states that if a
scheme is both consistent and stable the numerical solution of the
discretized equations will 'converge' to the exact solution of the PDE
as dx and dt --> 0. Presumably, this is the version of 'convergence'
that you are referring to when you say that the CFL condition is a
necessary but not sufficient condition to ensure convergence. But,
depending on the PDE and the scheme the CFL may be sufficient. Of
course, there are no proofs for Navier-Stokes... but it is a good bet
that (unless there is a bug) the combination of the CFL, the von
Neumann, and the divergence time-step restrictions are sufficient to
ensure stability and (given that our numerical schemes are consistent)
therefore convergence. (Note: there are some subtle violations of
consistency in the case of the Superbee flux limiter, which is why the
CHARM limiter--which is consistent--is preferred for DNS; Superbee has
advantages over CHARM for LES).
2. A wholly different meaning of 'convergence' is used in implicit
schemes for both linear and nonlinear systems. We could solve the
Poisson equation with an iterative method and we would judge the
quality of the solution based on the 'convergence criterion', i.e.,
whether the residual of the left and right hand sides of the equation
was below a certain error tolerance. This issue also comes up in
implicit schemes used to solve for the steady-state solution of a non-
linear equation. This is what Fluent does when it tries to find a
RANS solution. The procedure for unsteady RANS (Fluent's version of
LES) is nearly identical. It is extremely important to understand
that convergence of a time step in the sense discussed here does not
make the resulting numerical solution more accurate than the solution
obtained by a stable explicit method! As I will discuss in a moment,
most of the time it is just the opposite.
This brings us to the pros and cons of explicit versus implicit
numerical methods, which is practically a religious debate, and we do
not have the time to go into all the details here. The main point to
appreciate is that most of the time when implicit schemes are employed
it is because the user wants to take time steps which are much larger
than the eddy turnover times required to obtain an accurate LES
(which--if the flow is turbulent--should have oscillations [the
question is whether the oscillations are physical or numerical; in
general we want to encourage the former and suppress the latter]).
The result is an inaccurate solution that is stable. Do not be fooled
into thinking the solution is more accurate because the residual of
the implicit equation is small. Accuracy depends on the values of the
O(dx^p) and O(dt^p) truncation terms in the modified PDEs. Implicit
schemes (even once converged--in the #2 sense above) still have the O
(dt^p) error. What is worse is that it is so hard sometimes to find
the non-linear solution that two things happen: (a) the residual is
not converged tightly, and (b) developers often try to get away with a
first-order (i.e. Backward Euler) scheme (i.e. p=1). We could go
on... (as well could those who oppose explicit schemes).
So, now let's get to your specific questions...
1. See above.
2. Could be. But not definitive. Need to see the case. If you think
there is a problem, submit to Issue Tracker.
3. Our scheme is best thought of as a projection method (semi-
implicit) set within a strong-stability preserving second-order Runge-
Kutta time integration (see Gottlieb et al. SIAM 2001).
4. First, I am not sure what numerical criteria from Fluent lets you
know you have sufficient numerical accuracy. As I discussed above the
convergence of the residual is meaningless in this regard. For LES
this issue falls squarely in the lap of what we call 'Quality and
Reliability' of the LES (see Meyers, Geurts, and Sagaut, Springer
2008). We are working to add measures to FDS to help assess quality.
One measure is MTR (measure of turbulence resolution). Set
CHECK_KINETIC_ENERGY=T on MISC and output a slice of TURBULENCE
RESOLUTION. Try to get the time average <MTR>=0.2 roughly. We have
also bundled a package called Smokediff in with the latest release.
With this package you can easily compare the results from cases with
different resolutions and/or different parameters. You should be more
concerned with the time averages since the chaotic solutions diverge
quickly to different realizations of the turbulent flow.
Regarding your final paragraph, as I alluded to above, the CFL is not
the only time step restriction needed to ensure stability. We also
must worry about von Neumann and the divergence constraint. It is the
divergence (expansion) that restricts the time step when combustion is
occurring. The reduced time step should be sufficient to keep you
stable and therefore give you a reasonable solution. Whether the
solution is "correct", as you say, is more difficult to assess. It
should be fine numerically. As you mentioned, you have to compare
with data so see if you have sufficient grid resolution.
So, there is a lot of information and some subtle issues here. I
think the main thing is to make sure you have an appreciation for the
differences between RANS and LES, and then to ask whether the
oscillations you are seeing are physical or numerical. We can go from
there.
Cheers,
Randy
rmcdermo
One more thing I forgot to mention. I would not lock your time step
in a production run. We use this for special error analysis, but you
should let the routine CHECK_STABILITY take care of things during a
run. If you want a lower value of CFL or VN, then set it on MISC.
R
Julien
Thank you for your answer. There is a lot of informations in it.
Just one little thing, for LES calculation, the VN condition is only
applied to meshes with cells smaller than 5mm.
Most of my grids are bigger than that and I guess it is the same thing
for a lot of people.
So this means that the VN condition is hardly ever used. Am I right ?
rmcdermo a écrit :
rmcdermo
used. However, we have diagnosed several stability problems where
this turned out to be the cause. Further, 5 mm is an arbitrary
number, and we are trying very hard to exorcise FDS of such parameters
in hopes of evolving toward 'LES to DNS convergence'. (This is yet a
third meaning of the term convergence, the idea being that as you
reduce your grid spacing, dx, you ultimately recover a DNS
formulation. The practical result of this idea is simply that
increasing resolution should always give you a better answer. From a
development point of view, it means that we must be very careful that
our modeled subgrid terms vanish [quadratically] as dx --> 0.)
In order to force FDS to check VN for an LES calculation, set
CHECK_VN=T on MISC.
> ...
>
> read more »
cwood
I would like to better understand one of your original comments
regarding judging convergence in Fluent. If by that you mean
monitoring the residuals until the energy residual < 10^-6 and all
others at < 10^-3, then I do not agree that that is necessarily the
measure of convergence. While in most cases a problem resolved to
that level of residuals is "converged," it is not a guarantee and
results with higher residuals may be converged and ones with lesser
residuals may not be converged. So I think if your premise is that we
can compare the calculated residuals to these trigger values, I do not
think I would agree and observed transients in the flow do not equate
to numerical (either due to numeric processing or model formulation)
instabilities. While not necessarily "arbitrary" there are
limitations to which the residual value can be used to assess the
"goodness" of convergence.
Christopher
Julien
I totally agree with you. If the residuals reach the trigger values,
that does not mean that the solution is "converged". However, in my
opinion, monitoring these values (without setting any trigger level)
is important and give a first clue of the "goodness" of the solution.
In a nutshell, my original question was: As there is no way to monitor
this kind of quantities in FDS, how can I assess that my results are
good from a numerical point of view ?
I read the Fluent documentation again. It seems to me that the
difference between the two softwares lies in the process of solving
the equations.
For transient flows, Fluent uses a process in which the time step is
fixed. For each time step an iterative algorithm solve the equations.
To go to one time step to the other, there are two solutions: either
the residuals have reached the trigger values or the number of
iterations by time step fixed by the user is reached.
FDS uses a different process. The algorithm consists in a single-
iteration process by time step. The value of the time step is not
fixed and its value is calculated thanks to the CFL condition. The
respect of this condition ensures that the results are numerically
"correct". My second question was: according to the fact that this
condition is necessary but not sufficient, is it really enough ?
Maybe I'm making mistakes in my analysis. I would really appreciate if
you and/or somebody else could correct me.
Regards,
Julien
cwood a écrit :
Julien
In the second line the word "converged" as to be replaced by
"correct".
Sorry,
Julien
Julien a écrit :
Kevin
del dot u = 0. The momentum equation in FDS is written
rho du/dt + F + grad p = 0
Since rho is constant (in this example, not in general), you can take
the divergence of the equation
del^2 p = -div dot F
FDS solves this equation using a direct Poisson solver, so that when
you advance the velocity field, the updated value of u is also
divergence free, del dot u = 0. The direct pressure solver on the
simple mesh is what distinguishes FDS from most other CFD models.
Fluent uses a more general meshing system and they do not use a direct
(i.e. non-iterative) solver. So Fluent has to iterate to enforce the
divergence constraint. FDS gets it directly.
We use the direct pressure solver because it is fast and accurate, but
the limitation is that we cannot use curvi-linear or non-uniform
grids.
> > > Christopher- Hide quoted text -
>
> - Show quoted text -
rmcdermo
explicit numerics. The Poisson equation for pressure is not limited
to explicit schemes. As I stated above (or below or whatever),
convergence of residuals and convergence of the PDE are two completely
different things. See, for example, Morton and Mayers, "Numerical
Solution to Partial Differential Equations". It is a short book and
well worth the read.