[AnthonyP]

Originally Posted by malv83

Changing sourcePatches from (front) to (back) solved the problem of the non-symmetric final geometry (symmetry plane was not collapsing to an edge), but I can not solve the warnings and errors of checkMesh.

--> FOAM Warning :
From function virtual void Foam::wedgePolyPatch::calcGeometry(Foam::PstreamBuffers&)
in file meshes/polyMesh/polyPatches/constraint/wedge/wedgePolyPatch.C at line 70
Wedge patch 'back' is not planar.
At local face at (0.032436500978669881301 0.0086712994579358493308 0.00037859711274703408777) the normal (3.4756075755086737744e-008 -0.043619419342796700301 0.99904822018569061637) differs from the average normal (-9.4556952460451980674e-011 -0.043619387107251821056 0.99904822159304018658) by 2.2556775865909222576e-015
Either correct the patch or split it into planar parts

I have changed the writePrecision to 20 and writeFormat to binary when building the mesh(which is created without error or warnings) and when running extrudeMesh, but I have no improvements.

Anybody else know other way (within OpenFOAM) to create the wedge?

I was able to solve planar issue by adjusting the merge tolerance (making it smaller, like 1e-15). For me mergeTol was the last line of extrudeMeshDict.

I'll be trying the swap and update this post if it worked out for me.

[AnthonyP]

Unfortunately, a simple swap from between back and front faces did not work.


I had noticed for my particular mesh, that one of the cells had edges which extended into the negative x domain (before extrusion) If I edited those points to not step past the wedge axis, the new mesh extrusion had no errors. Although it passes checkMesh with no errors, unfortunately, the code halts before reaching the first timestep (ex. right when it hits the runtime loop).


I am currently trying another way to make my base 2D planar mesh to see if I can get the extrudeMesh utility to function better.



Apologies on the slow response; since the runtime error I became occupied by another project.

[AnthonyP]

Delayed posting: The solver issue was found.

The solver did not like printing out the U along the new axis of symmetry. (Suggest: either skip this runtime plot or move it slightly off-axis)