[Tobi]

Dear FOAM'er,

for some reason I build a new application that can flatten individual patches. The application is not too powerful and can only handle to flatten patches normal to the following planes:

• x-y
• x-z
• y-z

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time

Overriding DebugSwitches according to controlDict
    SolverPerformance 0;

Create polyMesh for time = 0

Read flattenPatchDict

Average patch normal of patch 'sym1' is (-2.10044e-13 -6.77083e-08 7.59531e-25)
Normalized average patch normal of patch 'sym1' is (-3.10219e-06 -1 1.12177e-17)
Modifing the points on the patch

Average patch normal of patch 'sym2' is (1.42693e-13 -6.58748e-08 2.53275e-13)
Normalized average patch normal of patch 'sym2' is (2.16613e-06 -1 3.84479e-06)
Modifing the points on the patch

Average patch normal of patch 'sym3' is (-2.0357e-25 -6.4221e-08 -7.58311e-17)
Normalized average patch normal of patch 'sym3' is (-3.16983e-18 -1 -1.18078e-09)
Modifing the points on the patch

Patch 'sym1' was modified

Patch 'sym2' was modified

Patch 'sym3' was modified

Writing points into directory "/calc/foamCases/Rhodos/hexMesh_zones/constant/polyMesh"

While running the application a second time, we will realize that the patches are perfectly aligned:

Normalized average patch normal of patch 'sym1' is (0 -1 0)

Normalized average patch normal of patch 'sym2' is (0 -1 0)

Normalized average patch normal of patch 'sym3' is (0 -1 0)

I was too lazy to add the necessary code in order to save the new point field in a new time folder. Thus, the point file will be directly overwritten. That means if you set something wrong in the dictionary, your mesh gets destroyed


For what is it good?

• flatten symmetry planes generated by snappyHexMesh
• flatten any flat surfaces generated by snappyHexMesh

https://bitbucket.org/shor-ty/flattenpatch

[pete20r2]

Thanks for this cool tool, I've used it to fix up the boundaries from cfMesh channel cases.
I had an error compiling on 1712 though.
Line 134 needed to be cast to type token. I don't know enough C++ to do this properly but this seemed to work:

134:        const token tmp = token ( boundaryPatches[patchi].name() );

[Tobi]

Hi Peter,
thanks for your hint. This circumstance is related to having different OpenFOAM distributions. E.g., I am using the Foundation version since I started using OpenFOAM. Thus, I got more familiar with the structure and class names.
Additionally, I like the release notes done by the Foundation based on the linkage between the bug-tracking system and other code related changes. ESI is doing a good job here too but does not provide as much information as I would like to have. However, the reason for that problem is related to my wrong programming

The object boundaryPatches is related to the class polyBoundaryMesh. The operator operator[] is returning an object of the class polyPatch to which we apply the function name(). Right now I cannot see the function definition of name() inside the class polyPatch

So, as the result of a fast search, I don´t know why it works at all. The function name() should be defined in a included class such as primitivePatch etc.
At least we have the proof that I don´t have C++ skills too.

[dduque]

Dear Tobi.


Your code just made my day! I was finally making progress in adding layers to a 2D geometry with a couple of straight angles. I finally had some success by using empty patches for back and front, but they were a bit distorted. That is likely to cause trouble when running the solver. (I am not sure since I am using that 2D for an axysimmetric simulation, with an intermediate extrudeMesh -- that's when I got non-planarity issues.)


Anyway, your code works like a charm. Only I also had to change line 134 as Peter, and line 73 to:

const word vecDir = word(flattenPatchDict.lookup("direction") );

This compiled in v1912.

[Tobi]

Hi, thank you for your feedback. Would be interesting to know, if you problem still occurs if you change the write format from »ASCII« to »BINARY« in the controlDict file.

[dduque]

Hi Toby.


I can see where you are aiming for. However, in my case this is not a matter of truncation errors (I did check with binary output anyway, just in case -- nothing changes).


In a nutshell, I was trying to mesh a 2D domain with many right angles. If my front and back covers were set as empty, the meshing is fast and produces an acceptable mesh.


In the figures, shots of one of the corners: 1, after castallation, 2. after the snap step, which introduces non-planarity, 3. after the add layers step, non-planarity increased.



corner1.png
corner2.png
corner3.png



Next, another view of 3. from the side. Finally, after your flattenPatch step: the side is now planar, and may be used for a 2D simulation, by an extrudeMesh from this side.



corner3_side.pngcorner3_side_flat.png


I know this seems convoluted, but it's the only way I have managed to satisfactorily add layers to this geometry.