[gu1]

Hello,

I'm post-processing my RMS results for the tests I'm doing and would like opinions. The results "are good" but when compared to Fluent, I see that they can be better, since in Fluent I am using the same mesh.

Below I share my fvSolution. I would like to understand how I can approach my RMS values in X and Y (not good results), since the flow is in the Z direction (whose RMS has given good results).

solvers
{
p
{
solver GAMG;
smoother GaussSeidel;
tolerance 0;
relTol 0.1;
mergeLevels 1;
nPreSweeps 0;
nPostSweeps 2;
nFinestSweeps 2;
nCellsInCoarsestLevel 512;
cacheAgglomeration on;
agglomerator faceAreaPair;
directSolveCoarsestLevel false;
scaleCorrection true;
minIter 3;
}

pFinal //...only PISO algorithm.
{
$p
tolerance 1e-6;
relTol 0.0;
minIter 3;
}

"(U|k)"
{
type coupled;
solver PBiCCCG;
preconditioner DILU;
tolerance (1e-5 1e-5 1e-5);
relTol (0.0 0.0 0.0);
nPreSweeps 0;
}

//To solve U and UFinal (U.* using regex).

}

PISO
{
momentunPredictor no;
nCorrectors 3;
nNonOrthogonalCorrectors 1;
pRefCell 0;
//pRefPoint (0 0 0);
pRefValue 0;
}

divSchemes
{
default none;
div(phi,U) Gauss linear;
div((nuEff*dev(T(grad(U))))) Gauss linear;
div((nuEff*dev2(T(grad(U))))) Gauss linear;
}

[LVDH]

Interesting post. Of course you could just lower the tolerances in your fvSolution (Why is it zero for p? maybe a mistake?). Also p relTol=0.1 seems a bit high. Try 0.001.


Only today I noticed the coupled solver for U in OF 1712. Have you tried a more conventional approach? If yes please share what you saw. My first test did not show a worthwhile improvement.

[gu1]

Originally Posted by LVDH

Interesting post. Of course you could just lower the tolerances in your fvSolution (Why is it zero for p? maybe a mistake?). Also p relTol=0.1 seems a bit high. Try 0.001.


Only today I noticed the coupled solver for U in OF 1712. Have you tried a more conventional approach? If yes please share what you saw. My first test did not show a worthwhile improvement.

As I use the PISO solver, what interests me is the residual of the pressure in the last iteration ('pFinal'), so I put it at zero ('p'). And relTol is 0.1 (in 'p') because it's faster.

I have not tested other models for U, what I have used works very well.

[RobertHB]

Originally Posted by gu1

As I use the PISO solver, what interests me is the residual of the pressure in the last iteration ('pFinal'), so I put it at zero ('p'). And relTol is 0.1 (in 'p') because it's faster.

But if you are interested in the last iteration value, why not define it explicitly via pFinal, e.g. set it to 1e-6 to calculate to that res., instead of via the first iteration res.?

[LVDH]

Originally Posted by gu1

As I use the PISO solver, what interests me is the residual of the pressure in the last iteration ('pFinal'), so I put it at zero ('p'). And relTol is 0.1 (in 'p') because it's faster.

I have not tested other models for U, what I have used works very well.

Makes sense what you say. Anyway, you can still lower the final tolerance for p to 1e-8 and for the other variables to 1e-6. and see what happens. What actually confuses me is that you also have k set as "coupled". Like I said, I have only now come across this in 1712 so I do not yet know what this actually does. What I would try to see what happens solving k conventionally and then U as well.

[gu1]

Originally Posted by RobertHB

But if you are interested in the last iteration value, why not define it explicitly via pFinal, e.g. set it to 1e-6 to calculate to that res., instead of via the first iteration res.?

RobertHB... Thanks for your response. Unfortunately I did not understand your point of view... could you explain it any other way?

LVDH, the 'coupled' model only applies to velocity. The 'k' should not even be there... the Wale model does not use it.
Do you know what the 'coupled' means?! If not, with it I define tolerance for Ux, Uy and Uz. The model I use is the PBiCCCG (CCC = XYZ).

Would you know how to get me started on how to improve my results when compared to Fluent (according to the images I presented above)?

[RobertHB]

Originally Posted by gu1

RobertHB... Thanks for your response. Unfortunately I did not understand your point of view... could you explain it any other way?

Sure. You know that there are two different tolerance settings in your fvSolution/solvers. One is tolerance, the other is relTol.
The tolerance lets you define a final residual to be reached per iteration. If you e.g. use tolerance 1e-6; the Final residual of your variable (p, U, k, etc.) will be < 1e-6.
The relTol keyword lets you define a relative tolerance based on the initial iteration residual. If you use relTol 0.1; the final residual of the interation will be final res. = relTol*inti. res. So if your iteration starts with Initial residual = 0.5437478881 the iteration ends at Final residual = 0.05437478881.


So i would think that if you want to control your Final residual you should rather the the tolerance. Setting relTol to 0 disables the keyword.

[LVDH]

Originally Posted by gu1

Would you know how to get me started on how to improve my results when compared to Fluent (according to the images I presented above)?

If you are happy with your fvSolution, you should also look at your fvSchemes as the settings there also affect accuracy.
Then, please also keep in mind that a mesh which is good for Fluent is not necessarily good for OpenFOAM. Fluent will likely be able a handle bad quality cells better than OF. You could run checkMesh and see what OF thinks about your mesh. Then, also mesh related, is the height of your surface layers. Maybe your wall model in Fluent is different than what you are using in OF.

[gu1]

Originally Posted by RobertHB

So i would think that if you want to control your Final residual you should rather the the tolerance. Setting relTol to 0 disables the keyword.

In other words...

p
{
solver GAMG;
smoother GaussSeidel;
tolerance 1e-6;
relTol 0.0;
}

pFinal
{
$p
tolerance 1e-6;
relTol 0.0;
}

?!

CheckMesh:

Overall number of cells of each type:
hexahedra: 122880
prisms: 0
wedges: 0
pyramids: 0
tet wedges: 0
tetrahedra: 0
polyhedra: 0

Checking topology...
Boundary definition OK.
Cell to face addressing OK.
Point usage OK.
Upper triangular ordering OK.
Face vertices OK.
Topological cell zip-up check OK.
Face-face connectivity OK.
Number of regions: 1 (OK).

Checking patch topology for multiply connected surfaces...
Patch Faces Points Surface topology Bounding box
wall 7680 7744 ok (non-closed singly connected) (-0.0999999998 -0.0999999998 0) (0.0999999998 0.0999999998 2)
inlet 1024 1057 ok (non-closed singly connected) (-0.0999999998 -0.0999999998 0) (0.0999999998 0.0999999998 0)
outlet 1024 1057 ok (non-closed singly connected) (-0.0999999998 -0.0999999998 2) (0.0999999998 0.0999999998 2)

Checking geometry...
Overall domain bounding box (-0.0999999998 -0.0999999998 0) (0.0999999998 0.0999999998 2)
Mesh has 3 geometric (non-empty/wedge) directions (1 1 1)
Mesh has 3 solution (non-empty) directions (1 1 1)
Boundary openness (-1.90394189e-15 -1.90716853e-15 -8.55469839e-18) OK.
Max cell openness = 2.97460393e-16 OK.
Max aspect ratio = 13.6105489 OK.
Minimum face area = 1.11120589e-05. Maximum face area = 0.000163558947. Face area magnitudes OK.
Min volume = 1.85200908e-07. Max volume = 1.02892303e-06. Total volume = 0.0627309696. Cell volumes OK.
Mesh non-orthogonality Max: 9.6835347 average: 2.63548259
Non-orthogonality check OK.
Face pyramids OK.
Max skewness = 0.4318385 OK.
Coupled point location match (average 6.66133815e-16) OK.
Face tets OK.
Min/max edge length = 0.00113645172 0.01666667 OK.
All angles in faces OK.
Face flatness (1 = flat, 0 = butterfly) : min = 1 average = 1
All face flatness OK.
Cell determinant (wellposedness) : minimum: 0.153833429 average: 2.57817791
Cell determinant check OK.
Concave cell check OK.
Face interpolation weight : minimum: 0.428623081 average: 0.488083617
Face interpolation weight check OK.
Face volume ratio : minimum: 0.634366657 average: 0.951150797
Face volume ratio check OK.

Mesh OK.

End

fvSchemes:

ddtSchemes
{
default backward;
}

gradSchemes
{
default Gauss linear;
}

divSchemes
{
default none;
div(phi,U) Gauss linear;
div((nuEff*dev(T(grad(U))))) Gauss linear;
div((nuEff*dev2(T(grad(U))))) Gauss linear;
}

laplacianSchemes
{
default Gauss linear uncorrected;
}

interpolationSchemes
{
default linear;
}

snGradSchemes
{
default uncorrected;
}

[RobertHB]

Originally Posted by gu1

In other words...

?!

Yes, like that.

[gu1]

Originally Posted by RobertHB

Yes, like that.

I will test with the settings mentioned above, since you have recommended them.

I'm not 'VERY' hopeful. Actually the difference of the results I got in OF compared to those of the Fluent are glaring (I attached an image below). I believe the only output at the moment is to look at fvSolution and increase the tolerance (10-8) to see if I can lower the results in RMSx and RMSy (since the flow is in the Z direction and the RMS is with "good" results).

Would you have any other suggestions?

*Another point I have to address is the difference in uTau values. In Fluent for this same flow, uTau is 0.1. In OF I have obtained results of 0.09. And unfortunately I do not understand why.
I'm using this formulation to monitor uTau through the additional swak4Foam: sqrt(nu*mag(snGrad(U))).
I believe the equation is correct ... right?