CFD Online Discussion Forums

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)
-   OpenFOAM Meshing & Mesh Conversion (https://www.cfd-online.com/Forums/openfoam-meshing/)
-   -   [blockMesh] Wrong surface normals with SHM's baffle feature on varying blockMeshDict description (https://www.cfd-online.com/Forums/openfoam-meshing/128756-wrong-surface-normals-shms-baffle-feature-varying-blockmeshdict-description.html)

ripudaman January 20, 2014 17:15

Wrong surface normals with SHM's baffle feature on varying blockMeshDict description
 
2 Attachment(s)
Dear Foamers,

I have posted my problem on the bug reporting system here - http://www.openfoam.org/mantisbt/view.php?id=1131.

One of the managers replied and said that he was not able to reproduce the problem. I am unable to diagnose what I am doing wrong. Can you please help me?

I am creating a circular baffle (radius = 5, center = 0,0,0) using SHM. The baffle is in the YZ plane. The two faces of the normal after snapping should have normals in the opposite directions. I found that this varies with a small change in the blockMeshDict file.

Keeping everything else same if I increase the size of my blockMesh dict in the +X direction (increasing the gridblocks in +X direction proportionately) I find that the surface normals on the circular baffle (ff and ff_slave) become randomly oriented.

I have attached two cases. Sneddon_50_25_25 works perfectly while Sneddon_100_25_25 does not.
The first case has a box with dimensions (-100,-50,-50) to (100,50,50) with 50,25,25 gridblocks in X,Y and Z directions respectively.
The second case has the box with dimensions (-100,-50,-50) to (300,50,50) with 100,25,25 gridblocks in X,Y and Z directions respectively.
In both cases the disc/baffle is located at 0,0,0 and oriented in the YZ plane.

Can you please confirm if you can reproduce a random arrangement in the cell normals on the ff patch in the X direction? The normals on one side of the patch should ideally be uniformly either (1,0,0) or (-1,0,0). I get a mixed bag for the second case.

Thanks for your help.

Ripu

wyldckat January 26, 2014 09:35

For future readers: this problem seems to have been already solved, or at least the bug has been reported as already fixed and confirmed on the indicated bug report.

ripudaman January 26, 2014 13:43

The problem was solved by using an updated version of OpenFOAM 2.2.x form the repository.


All times are GMT -4. The time now is 08:20.