inconsistent faceZone normals from snappy, orientFaceZone fails to correct (log says it flips half the normals, but the faceZones mesh file is unchanged)
So, I am seeing an issue I have seen in past versions: faceZones are not consistently oriented from snappy, AND this is not being corrected by orientFaceZone. This then prevents me from monitoring mass flow rates properly. When meshing a simple radiator (see geom image attached), I get a cellZone for the inside of the radiator, and a single faceZone separating the radiator cellZone from the external cellZone. I later take this faceZone, and split it into inlet and outlet faces using topoSet and a dict file in system.
Both the original faceZone, and the created inlet/outlet faceZones have random normals, which I want to have consistent for mass flow calculations. So, I try using orientFaceZone, but it does not change anything! I first meshed the case normally, then copied that mesh, and ran orientFaceZone on the copy. I am writing the mesh in ascii uncompressed, so I can use xxdiff to directly compare the files. Although the faceZones file for the copied mesh is newer, suggesting it was re-written by the utility, it is the exact same as the original file – no change. I have made a screenshot of xxdiff, to show you this. I've circled where I would normally expect to see a change.
The log file for orientFaceZone (also attached) clearly shows that it is flipping almost exactly 50% of the normals, and when I look at the faceZone normals in paraview (image also attached), about 50% should be flipped. Makes sense, as the 50% suggests a random distribution of the normals from snappy.
So, it appears to me that orientFaceZone is working, and doing the correct flipping. BUT, it seems to not write out the results! I cannot see any options that would force or prevent it from doing so, which makes me think it is a bug.
At the moment in 1706, I run the cases with two fluxSummary monitors: one using faceZone, and one using faceZoneAndDirection (great feature!!!) with the direction of the faceZone given by me explicitly. The two mass flow rates should match up exactly IF orientFaceZone were working, but there is a clear mis match (simpleFoam log attached.) I am hoping to get away from that, so if this is in fact a bug, I can share the test cases I created. They are 42MB each, compressed, and include a paraview state file for viewing the faceZone normals.