|
[Sponsors] |
October 26, 2009, 10:00 |
Possible bug in cyclicPolyPatch::order
|
#1 |
Member
Niklas Wikstrom
Join Date: Mar 2009
Posts: 86
Rep Power: 17 |
Hi,
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:rder, 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 Niklas |
|
October 26, 2009, 13:33 |
|
#2 |
Senior Member
Mattijs Janssens
Join Date: Mar 2009
Posts: 1,419
Rep Power: 26 |
Hi Niklas,
- 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. |
|
October 27, 2009, 08:43 |
|
#3 |
Member
Niklas Wikstrom
Join Date: Mar 2009
Posts: 86
Rep Power: 17 |
Code:
Specified rotation : n0:(0 1 0) n1:(0 5.29112e-08 -1) HOWEVER: 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 Code:
Points changed by average:9.91435e-16 max:2.84237e-14 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 :-) Best regards! |
|
October 27, 2009, 12:57 |
|
#4 |
Senior Member
Mattijs Janssens
Join Date: Mar 2009
Posts: 1,419
Rep Power: 26 |
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.
|
|
Thread Tools | Search this Thread |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Bug in Meshing Parameters menu Spacing1 (1e+10) | Karna | ANSYS Meshing & Geometry | 1 | October 12, 2009 15:38 |
On Bug of Fluent 12.0 | lzgwhy | FLUENT | 0 | August 26, 2009 07:41 |
bug in Rcomponents utility | cedric_duprat | OpenFOAM Bugs | 1 | May 7, 2009 03:56 |
Bug reports | Mattijs Janssens (Mattijs) | OpenFOAM | 0 | January 10, 2005 11:05 |
Forum y2k Bug | Jonas Larsson | Main CFD Forum | 1 | January 5, 2000 11:22 |