Validation of Turbulent Pipe Flow

Using SimScale Fluid Flow / CFD
5

Hello @Carlos_Ramirez, @mas985, and other SimScale users,

We have been investigating the reason for this inconsistency in the results of the turbulent flow validation case, and I have good news and bad news.

The good news is that we know the reason why this inconsistency exists, I will try to explain this here. First, some background information:

  • For every face of its mesh, OpenFOAM defines an attribute called type. By default, we set this type to be wall.
  • As input, OpenFOAM also requires a set of files that define the initial and boundary conditions for simulation variables. For turbulent cases (e.g. for the K-Omega SST model), the workflow is influenced by whether or not the file for the variable nut is present among these files.
  • If nut is present, then OpenFOAM will proceed normally with the boundary-conditions (BCs) written by the user.
  • If nut is absent, then for all turbulence variables (k and omega, for example) OpenFOAM will replace all faces of type wall with the BC wallFunction.

With this information in hand, we look at the actual issue.

  1. Back when the turbulent flow validation case was created, the nut file was by default NOT written. This caused OpenFOAM to replace all BCs for all turbulence variables with wallFunction. This happened irrespective of whether the actual BC supplied was zeroGradient or wallFunction (or inlet / outlet, for that matter).
  2. For some reason, even with this incorrect setup, the observed results were physically in the correct range of values. And since the user could not see the actual OpenFOAM files, there was no way to tell that the actual “solver-level” case setup was in fact not what was expected.
  3. At some point in time, we corrected this behaviour by writing the nut files by default. This caused OpenFOAM to follow the correct behaviour.

The bad news, of course, is that with the correct simulation setup we get incorrect results. But this could be for multiple reasons: the mesh we use might not be good enough; the y+ near the walls needs better and smoother resolution; the numerics might need some treatment.

Our team will investigate this, and we will fix the turbulent flow validation case at the earliest. In the meanwhile, we have taken down the validation page for that case. As soon as the issue is resolved, we will update this thread.

Thank you @Carlos_Ramirez and @mas985 for bringing this issue to our attention. :slight_smile:

4 Likes