View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002241 | OpenFOAM | Bug | public | 2016-09-12 13:44 | 2017-06-30 11:07 |
| Reporter | rperry | Assigned To | chris | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Platform | Linux | OS | CentOS Linux release 7.1.1503 | OS Version | (please specify) |
| Summary | 0002241: correct faceZone orientation lost when creating faceZone via topoSet | ||||
| Description | Hello, On a simple automotive test car case with a porous media, I create a cellZone for the porous media, which has a resulting faceZone that includes both the inlet and outlet. I can see that, in 4.0, this faceZone has properly oriented normals :-) However, as I later want to measure mass flow rate, I use topoSet and searchableSurfaceToFaceZone to create inlet and outlet faceZones. Their orientation however, is not preserved. I am happy to share my case, but it's about 60Mb, so I have uploaded my topoSetDict, shmDict, and images of the issue from paraFOAM. There is no cell renumbering; the images come directly before and after topoSet is run. The clear line across which the normals change to incorrect values looked like a processor boundary issue, but after loading each of the processor meshes individually, I can confirm that this line does not correspond with a processor boundary, so I don't think it's related to parallelization. I am happy to help or share data. Alternatively, if it is possible to generate the inlet/outlet faceZones from the beginning (rather than one single faceZone that later has to be split), I would love to hear how - would be a good workaround. | ||||
| Tags | cell normals, faceZone, orientation, searchableSurfaceToFaceZone, topoSet | ||||
|
|
|
|
|
searchableSurfaceToFaceZone looks at the angle between - vector from owner cell centre to neighbour cell centre (i.e. pointing out of cell) - local surface normal and sets the flip map if these normals are in opposite direction. I checked the code and it looks ok. 1) are your surface normals consistent 2) at the location of your orientation flip maybe you're picking up a different row of cells where the owner and neighbour are different? 3) or maybe you are not picking up an intersection at all? On boundary faces it only checks for intersections between cell centre and face centre. If your surface is outside, even by a small tolerance, you might not pick up any intersection - but then the face would not be in the faceZone in the first place. 4) can you put on some 'Normal Glyphs' (deselect the 'Consistent' flag). Does it show the same. We'll need a small case to work on if you still think there is a problem. |
|
|
No feedback from reporter |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2016-09-12 13:44 | rperry | New Issue | |
| 2016-09-12 13:44 | rperry | File Added: faceZone_orientation_issue.zip | |
| 2016-09-12 13:44 | rperry | Tag Attached: cell normals | |
| 2016-09-12 13:44 | rperry | Tag Attached: faceZone | |
| 2016-09-12 13:44 | rperry | Tag Attached: orientation | |
| 2016-09-12 13:44 | rperry | Tag Attached: searchableSurfaceToFaceZone | |
| 2016-09-12 13:44 | rperry | Tag Attached: topoSet | |
| 2016-09-16 10:32 | MattijsJ | Note Added: 0006870 | |
| 2017-06-30 11:07 | chris | Assigned To | => chris |
| 2017-06-30 11:07 | chris | Status | new => closed |
| 2017-06-30 11:07 | chris | Resolution | open => fixed |
| 2017-06-30 11:07 | chris | Note Added: 0008301 |
