Hello,
I’m developing a validation of Turbulent Flow on a Pipe with roughness on the wall based on the configuration of this case (Turbulent Pipe Flow) that shows a good match between the computational results and the experimental data. Before attemping to make simulations with roughness, I ran a simulation exactly in the same conditions of the case named “k-epsilon_wallFun” (I mean, same initial conditions, boundary conditions, numerical parameters and simulation controls). However, I obtained results very different: the convergence of the control parameters don’t have the quality of the original simulation, and the pressure drop in my case is 7.17 kPa (the result of the original case is approx. 1.65 kPa). I don’t know if this discrepancy is due for different versions of SimScale or exist other reason for this problem.
If you know what can be my problem, i would very grateful!
I have some information with regard to the issue that you encounter. There are 2 approaches to model turbulent flow near the wall.
Wall functions
Full-resolution
The wall function for this particular project has inconsistency, which is caused due to some changes in the default code and we are working to rectify this for the old project. In the meantime, please try to work with full-resolution scheme which should give you the right results. Also, thank you so much for pointing this out to us
I am having the same problem with wall functions as discussed in this thread:
However, when I try to recreate the results for the “Full Resolution” case using k-OmegaSST, the simulation is converging extremely slow. Much slower than the original. Plus when I look at the average inlet pressure, it keeps increasing with increasing iterations (>200 kPA). So I don’t believe this is working either. Here is the project:
I tried to follow the original as best as possible.
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.
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).
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.
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.
As promised by @sjoshi in his last message, a thorough investigation was completed of how boundary conditions are written for turbulent simulations. This resulted in a small rework introduced in the latest release, which fixed the issue reported here. Now all simulations using turbulence models that include no-slip walls provide more accurate results. This can be seen in case of updated Turbulent Pipe Flow validation case, which now for both Wall Function and Full Resolution approaches gives results in close correspondence with predictions given by Darcy-Weisbach equation.
See more on Turbulent Pipe Flow validation project documentation page, and related SimScale project, that are now available at following links:
