[andy_]

Originally Posted by CFD_SG_01

I totally agree with you. I plot the dPtot fluctuations over iteration and I could notice the unstable behavior for both models. The results given above is averaged over the last 1000 iterations.

Flapping about unconverged steady state fields are meaningless and cannot be usefully compared. If you want to compare the transient behaviour then you need to include resolved time terms and to converge the solution on every time step. If you want steady solutions then you need to include RANS turbulence models.

[CFD_SG_01]

Hello,

Here is some additional information I have.
I did realize two additional exercices to explore this subject.
1- A new mesh to with 12 boundary layers to get a Yplus down to 0.4 in order to avoid wall function problems
2- A coarse mesh combined with an inlet velocity of 4m/s to get a minimum of 50 yPlus in order to assess high Y+ wall functions.

Here are the results:

1st Case (new finer mesh)-KOMEGA SST:
For information 1D computation (using colebrook correlation): 22 Pa
StarCCM+ - dPtot (Pa): 89.4
OpenFOAM - dPtot (Pa): 93.3
Relative difference: 4%

2nd Case (coarse Mesh)-KOMEGA SST:
For information 1D computation (using colebrook correlation): 244 Pa
StarCCM+ - dPtot (Pa): 1515 (Computed yPlus : 62
OpenFOAM - dPtot (Pa): 1237 Computed yPlus : 55
Relative difference: 18%
(I can share the information that the velomag iso contour show differences. Unfortunately I can't share pictures)

My first conclusion is that the wall function plays a key role for both results. The 1st case shows very similar results and it is reassuring . I still do not understand why my handmade calculation provides another results .
I've also noticed that OpenFOAM doesn't include the K-Epsilon Realizable Two Layers while StarCCM+ does so it won't be possible to compare both.
I've tried to run the case with OpenFOAM using KEpsilonRE or KEpsilon ( LowRe Correction : True) but it quickly crashes.
Any suggestion ?

Regarding the 2nd case (coarse mesh): Both Yplus isocontour and velomag are different. This makes me think again of wallfunctions between solvers. On one side there is a continuous Blended Wall Function managed by StarCCM+ on the other side other wallfunctions settings. Have you ever worked on such subject or have you ever noticed similar results ?

Thank you in advance

[andy_]

Originally Posted by CFD_SG_01

My first conclusion is that the wall function plays a key role for both results. The 1st case shows very similar results and it is reassuring . I still do not understand why my handmade calculation provides another results .
I've also noticed that OpenFOAM doesn't include the K-Epsilon Realizable Two Layers while StarCCM+ does so it won't be possible to compare both.
I've tried to run the case with OpenFOAM using KEpsilonRE or KEpsilon ( LowRe Correction : True) but it quickly crashes.
Any suggestion ?

Regarding the 2nd case (coarse mesh): Both Yplus isocontour and velomag are different. This makes me think again of wallfunctions between solvers. On one side there is a continuous Blended Wall Function managed by StarCCM+ on the other side other wallfunctions settings. Have you ever worked on such subject or have you ever noticed similar results ?

Wall functions and/or low Reynolds number treatments can be implemented in a significant number of different ways leading to differing wall shear stresses. The differing wall shear stresses create different boundary layers which can lead to different main flows depending on how influential the boundary layers are in controlling the main flow. So yes wall functions can be important particularly if the solution is under-resolved by, for example, imposing a flat inlet profile with a very large and physically unreasonable gradient next to the wall.

Many decades ago I implemented a number of different wall treatments for several different high Reynolds number RANS turbulence models and studied their performance for simple boundary layers and more complex flows such as curved diffusers. In terms of pressure recovery in the diffusers the wall functions had an influence but it was secondary to the difference in the turbulence models themselves. The velocity and turbulence inlet profiles were reasonably realistic though rather than flat which would have avoided emphasizing/provoking the differences in the wall functions.

[JBeilke]

If the results deviate so greatly, there is usually something really wrong in the setup.

I quickly ran both cases in CCM+ with High-Re k-epsilon and got 25.9 Pa in the first case and 298 Pa in the second.

So we don't need to blame the turbulence models for the wrong results.

The results above are just to show that we can easily get to the right order of magnitude. My setup is way too sloppy for a real benchmark.

[FliegenderZirkus]

Originally Posted by CFD_SG_01

Unfortunately I can't share pictures

I wonder why you can't share everything, isn't this just a straight pipe after all? I would be curious to see a section view of the domain showing how the inlet and outlet extrusions are defined and on which surfaces you are taking the pressure drop report (talking about Star-CCM+ here). Contours of the axial velocity and pressure would be nice too. If you can share the analytical calculations, that would be useful. The results should be in the same ballpark as the CFD, if it's really just a straight pipe. Judging by what @JBeilke posted, the hand calculations seem correct though...

[LuckyTran]

As mentioned by Andy already, flapping results is clearly non-converged and post-processing any quantities is meaningless. Running additional cases without addressing these issues leads to even more misleading results presented.

I have a feeling the mesh is god awful in quality and leading to convergence problems and that all these shenanigans are not caused by Star, not caused by OpenFOAM, not caused by wall functions, not caused by turbulence models, but purely user error.

I mean, if the difference between the two cases is only the mesh then why does the calculated dP from the colebroke equation change!? There's rampant errors here that is beyond the realm of simple typos. And as noted but grossly ignored, this error has nothing to do with any CFD code!

[CFD_SG_01]

Hello,

Thank you for your replies.
Well it looks like I didn't realize correct simulations.
On one side it is a good news JBeilke finds similar results to my handmade calculations using Blasius formula ()
The 1D computation uses Colebrooks formulas and provides almoste same results as my handmade calculation. (that's a relief^^ )
On the other side it's not reassuring to get different results from JBeilke and it questions some of my CFD skills ^^ (not a bad thing if it helps me to become better)

Please find some picture of the results. I finally find a way to upload some screenshots. I hope it will be helpful.
I do agree the coarse mesh is awful and it was the point of creating a deterioted mesh to assess solvers performance in case of such situation

[FMDenaro]

This discussion seems to go nowhere while talking of mesh, wall models, turbulence models without any convergence...

Again, first what about the numerics? That is, what happens in the two codes for a standard laminar solutions?
What kind of formulation is used, incompressible or compressible flow assumptions?

What are exactly the inflow conditions

[CFD_SG_01]

Originally Posted by FMDenaro

This discussion seems to go nowhere while talking of mesh, wall models, turbulence models without any convergence...

Again, first what about the numerics? That is, what happens in the two codes for a standard laminar solutions?
What kind of formulation is used, incompressible or compressible flow assumptions?

What are exactly the inflow conditions

I did the exercice for a laminar flow where I set an inlet velocity of 0.016m/s.
Laminar Flow exercice - For both solvers:
Incompressible Flow
Density = 997.561 kg/m3
Dyn. Visco. =8.8871E-4 (Pa.s)
Turbulence model : - no, Laminar option was selected
Inlet : Velocity inlet 0.016m/s (velocity value is imposed on all inlet cells)
Outlet : Outlet Pressure : 0 Pa ( the ref. Pressure is 101 325Pa)
The results where close ~3% difference between both solvers.

All boundary or type conditions were detailed in one of my previous post the last 20th of November.

[FMDenaro]

Originally Posted by CFD_SG_01

I did the exercice for a laminar flow where I set an inlet velocity of 0.016m/s.
Laminar Flow exercice - For both solvers:
Incompressible Flow
Density = 997.561 kg/m3
Dyn. Visco. =8.8871E-4 (Pa.s)
Turbulence model : - no, Laminar option was selected
Inlet : Velocity inlet 0.016m/s (velocity value is imposed on all inlet cells)
Outlet : Outlet Pressure : 0 Pa ( the ref. Pressure is 101 325Pa)
The results where close ~3% difference between both solvers.

All boundary or type conditions were detailed in one of my previous post the last 20th of November.

For such a simple case I would expect a quasi-perfect accord between the two codes, not sure about this 3% of difference.
Have you tried to get better accordance?

[CFD_SG_01]

Originally Posted by FMDenaro

For such a simple case I would expect a quasi-perfect accord between the two codes, not sure about this 3% of difference.
Have you tried to get better accordance?

I agree. I hoped to get less than 1% difference but since I've started to use OpenFOAM I daily face new surprising issues. So I "accepted" this result to move turbulent cases. Maybe it was a mistake but I needed to move forward to better understand how both solvers work.

[FliegenderZirkus]

Originally Posted by CFD_SG_01

Hello,
Please find some picture of the results. I finally find a way to upload some screenshots. I hope it will be helpful.

L = 10*D looks like a pretty short length of pipe for the flow to fully develop. I think you can see that in the velocity contour as well - it's still changing half way through the domain, which is where you already take your pressure drop measurement. That could explain the difference to hand calculations, which assume fully developed flow. It can be useful to take several line probes at various distances along the pipe and plot axial velocity profiles, like in the first picture in this article. It also makes comparison of different solvers or settings easier.

[CFD_SG_01]

Flash info !!
I found one of my BIG mistake. The distance between the planes to assess was not 0.1m but 0.5m. So the 1D and handmade calculation is 103Pa which is closer to the CFD values computed by StarCCM+ and OpenFOAM.
That's a relief !

Now I still need to focus and investigate why both solvers provide different results

[LuckyTran]

The picture of the Star-CCM case is clearly unacceptable. The flow accelerates, decelerates, and accelerates again. It's clearly wrong, there is no value added to comparing it with anything. The OpenFOAM one looks less problematic, but considering that this simulation was done by the same person, I would question it.


As predicted and I agree, the mesh is awful.