Possible bug in cyclicPolyPatch::order
Running recent version of 1.6.x:
I am trying to create a (rotational) cyclic patch from two patches using createPatch. rotationAxis and rotationCentre is is given. Although several tests with different tolerances are performed, attempts fail with a Serious error in cyclicPolyPatch::order, followed by a Fatal Error due to face area mismatch (log file attached).
A coarser mesh on the same geometry runs without errors and the problem is not easy to reproduce.
Funny thing is that the faces reported to be of different area in the FATAL ERROR, does not match the correspondingly reported vertices. The attached image show the vertex location as orange spheres and the faces location barely seen as green triangles. The faces are loaded into paraview from the faceSet "wrongFaces" generated by createPatch.
The wavefront .obj files XX_half0_faces.obj and XX_half1_faces.obj generated by createPatch does contain the correct faces. With debug flag set for cyclics the lines showing found face to face connections looks much like an inverted hedgehog (attached).
I am aware of ANSAS lack of fine tolerances, but I have made sure the patches are perfectly flat and aligned to respective coordinate planes. Moreover the surface mesh on the two patches are in perfect match, using "eye norm".
My test case is 3M compressed and I am more than happy to send a mail containing the failing case.
Best regards and warmest congratulations
- can you switch on the debug flag for cyclic. Check the printout for 'Specified rotation' n0 and n1.
- check the obj files written for 'automatic ordering result'. Do they correspond to the two halves rotated on top of one another?
if you can create a smaller case I'm happy to have a quick look at it.
The problem is solved, for this test case, by setting the matchTolerance 1. It feels a bit awkward to allow such a high tolerance which is why I did not try it before. The points un-alignment is far less than the shortest face edge (~10) in this case, I am quite sure, and the point sync reports
Sloppy tolerances is a problem with Ansa, who on the other hand puts a nice effort into exporting directly to OpenFOAM.
Thank you Mattijs for answering! It helped me help myself :-)
The problem is I guess due to an accumulation of errors. Normal is slightly off, transformed points (one half transformed on to other half) even more off and probably just beyond the tolerance (relative per face) for a few small faces.
|All times are GMT -4. The time now is 10:26.|