[okrochak]

Dear all,

I am running simpleFoam simulations of a flow meter and a pipe assembly, and I want to take advantage of the symmetry of the problem. So I only mesh the right half of the pipe/meter, and then I apply "symmetry" BC for "p U" fields. However, the resulting simulation doesn't behave as expected. If I view my symmetry plane, there are normal fluxes U_y, going through it. The magnitude of flow in my simulation is from 0.01 at the inlet to around 0.04 maximum in the domain. The velocity through the plane reaches magnitudes of 4.5-9 e-4, which is only 2 order lower than the overall magnitude and thus physically significant.

Please note that this behaviour is encountered with Openfoam v2212. However, I've done extensive tests and this behaviour is reproducible with OpenFOAM v2006, as well as with symmetryPlane and even slip BCs !!!

I've also run a simulation with the full domain, for comparison. Although it's not fully converged (it = 400) with simpleFoam, all other solver settings are consistent. The solution matches exactly besides the symmetry slice.

If you need any further information, I will readily provide it to you. I attach the samples from U and boundary files:

https://imgur.com/a/spkiGBy
Thank you in advance for any help

/*--------------------------------*- C++ -*----------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: v2212 |
| \\ / A nd | Website: www.openfoam.com |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
class volVectorField;
object U;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

dimensions [0 1 -1 0 0 0 0];

internalField uniform (0 0 0);

boundaryField
{
inlet
{
type fixedValue;
value uniform (0.0116 0 0);
}

outlet
{
type zeroGradient;

}

mirrorPlane
{
type symmetry;
}

walls
{
type noSlip;
}

fins
{
type noSlip;
}

}


// ************************************************** *********************** //


/*--------------------------------*- C++ -*----------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: 2212 |
| \\ / A nd | Website: www.openfoam.com |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
arch "LSB;label=32;scalar=64";
class polyBoundaryMesh;
location "1/polyMesh";
object boundary;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

5
(
outlet
{
type patch;
nFaces 1860;
startFace 3445294;
}
inlet
{
type patch;
nFaces 1860;
startFace 3447154;
}
walls
{
type wall;
inGroups 1(wall);
nFaces 67730;
startFace 3449014;
}
mirrorPlane
{
type symmetry;
inGroups 1(symmetry);
nFaces 0;
startFace 3516744;
}
fins
{
type wall;
inGroups 1(wall);
nFaces 62682;
startFace 3516744;
}
)

// ************************************************** *********************** //

[Tobermory]

Agreed that this seems odd. Initial thoughts are: how good is your mesh (check output from checkMesh) and your solution convergence (check run log)?

[okrochak]

Originally Posted by Tobermory

Agreed that this seems odd. Initial thoughts are: how good is your mesh (check output from checkMesh) and your solution convergence (check run log)?

Dear Tobermory,

My mesh is mostly ok, I do have some skew and orthogonal faces because I mesh part of the meter with snappyHexMesh

OK.
Min volume = 1.59692e-12. Max volume = 1.1959e-08. Total volume = 0.000494526. Cell volumes OK.
Mesh non-orthogonality Max: 74.8541 average: 13.6687
*Number of severely non-orthogonal (> 70 degrees) faces: 3.
Non-orthogonality check OK.
<<Writing 3 non-orthogonal faces to set nonOrthoFaces
Face pyramids OK.
***Max skewness = 4.1713, 1 highly skew faces detected which may impair the quality of the results
<<Writing 1 skew faces to set skewFaces
Coupled point location match (average 0) OK.

Failed 1 mesh checks.


As for the residuals, I've added it to the imgur album. They are relatively low and don't see to decrease much further, although sometimes there is an "oscillation". I plan to investigate this setup also with a transient solver pimpleFoam.

https://imgur.com/p3h9Zf8

It's a laminar flow without any turbulence model, so only U p are shown

Nonetheless, I don't think this is the cause of this symmetry bug. I think it has to do more with how OpenFOAM interpretes this BC, but I couldn't find much information on that.

[Tobermory]

So checkmesh failed with some corrupt cells ... and it is really the continuity error that we are interested in here. My advice is to sort out the mesh first - get a proper, good quality mesh and you might find that the solver behaves more rationally. I don't think that you can blame it on the boundary condition at this stage.

[sylvester]

Hi Alex,


You visualize Uy with a range between -9.9e-3 and +9.1e-3, i.e. not symmetrical around 0. This results in a reddish colour for when Uy = 0 m/s. This can give the false impression that the symmetry b.c. is not working properly.



In the attached imaged I've tried to recreate your colour. The value of the Result variable is uniformly 0, but its colour is not white (or neutral grey), but a bit red.

[okrochak]

Originally Posted by Tobermory

So checkmesh failed with some corrupt cells ... and it is really the continuity error that we are interested in here. My advice is to sort out the mesh first - get a proper, good quality mesh and you might find that the solver behaves more rationally. I don't think that you can blame it on the boundary condition at this stage.

Dear Tobermory,

Thank you for your reply. The original mesh was created by using "blockMesh" utility to create most of the mesh in a structured manner. Then I've applied "snappyHexMesh" utility to mesh the more complicated part of the geometry.

To test your hypothesis, I've made another mesh with only the structured part. This mesh returns no problems/warning with checkMesh utility. Nonetheless, when I run the simulation, there are still symmetry plane - normal fluxes. I've added an image to the original album.

https://imgur.com/uZUZvT6

So I don't think it's the issue with the mesh in particular. I think this has to do with how symmetry BC (and likely slip wall BC as well) are implemented in OpenFOAM. In my opinion, a symmetry BC should force patch-normal velocity to zero, just as a wall BC forces velocity magnitude to zero (regardless of the mesh quality).

[okrochak]

Originally Posted by sylvester

Hi Alex,


You visualize Uy with a range between -9.9e-3 and +9.1e-3, i.e. not symmetrical around 0. This results in a reddish colour for when Uy = 0 m/s. This can give the false impression that the symmetry b.c. is not working properly.



In the attached imaged I've tried to recreate your colour. The value of the Result variable is uniformly 0, but its colour is not white (or neutral grey), but a bit red.

Hello sylvester,

I understand what you are trying to say, but this is not the issue. Look at the third image in the album, there you clearly see there are non-zero y-velocities:

https://imgur.com/tHTfzwR

[sylvester]

I see what you mean.


Might it be a ParaView cell-to-point interpolation issue? In your images, do you visualize the data with cell values, or point values?

[okrochak]

Originally Posted by sylvester

I see what you mean.


Might it be a ParaView cell-to-point interpolation issue? In your images, do you visualize the data with cell values, or point values?

I think in the images I use point values, but I get the same results if I use cell values. Maybe you are right, it's just the way the OpenFOAM interpolates, since there could (and should) be some wall normal flux in the cell centers, since it's not entirely at the symmetry plane. But I'm not convinced this is the right explanation and I feel like OpenFOAM or paraview should be able to correct for that, since a BC is given explicitly on the face

[qingqingliu]

Hi Alex,

I met a similar issue. I used slip boundary in an axisymmetric geometry. However, the normal velocity is not zero. It seems that the slip boundary cannot fully remove the normal velocity in OpenFOAM? My post is here:

slip and wedge boundary conditions in the axisymmetric geometry

[okrochak]

In the end, I ran some tests with a full domain and with half-domain and symmetry bc and the data was the same everywhere besides the points on symmetry plane. So it might simply be an issue of Paraview/Openfoam not knowing to enforce the zero-flux bc on the symmetry plane, but as it doesn't seem to affect the rest of the domain it is not a major issue.

[blr]

I have met the same issue. I use the symmetry conditon, but the velocity normal to the symmetric face is not zeor. Your results justify my situation. Thanks a lot, okrochak!

[blr]

Originally Posted by blr

I have met the same issue. I use the symmetry conditon, but the velocity normal to the symmetric face is not zeor. Your results justify my situation. Thanks a lot, okrochak!

Hi, okrochak, and everyone, here is a thread for this issue,https://www.cfd-online.com/Forums/openfoam-post-processing/187798-why-no-slip-b-c-does-not-obtain-zero-velocity-contour.html"]Why no-slip b.c. does not obtain zero-velocity contour?[/URL]. It's the problem of ParaView. We should use paraFoam instead of paraFoam -builtin.