|
[Sponsors] |
![]() |
![]() |
#1 |
Senior Member
Alan w
Join Date: Feb 2021
Posts: 278
Rep Power: 6 ![]() |
I am still working on my chtMultiregion case, and have run into yet another roadblock. It comprises a radiator in a fairing, and the fairing itself is modelled with several bodies. This is to facilitate troubleshooting, as I was having problems with one single big body.
Now, most of the bodies work okay, but one is defying me. After running through 50 timesteps, I open the postProcessing streamlines, and rather than flowing around the body, the streamlines just go straight to the body and stop. (See the attached image.) But when I do a surfaceCheck on the body, it looks okay: Code:
\ Build : 8-30b264cc33cd Exec : surfaceCheck front-upper.stl Date : Jan 28 2024 Time : 13:04:02 Host : "localhost.localdomain" PID : 8993 I/O : uncollated Case : /home/boffin5/cfdaero/meredith-blockmesh-flap nProcs : 1 sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE). fileModificationChecking : Monitoring run-time modified files using timeStampMaster (fileModificationSkew 10) allowSystemOperations : Allowing user-supplied system call operations // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // Reading surface from "front-upper.stl" ... Statistics: Triangles : 13016 Vertices : 6510 Bounding Box : (15.4144 -0.318944 9.25658) (16.0254 0.318944 9.42756) Region Size ------ ---- front-upper-mm 13016 Surface has no illegal triangles. Triangle quality (equilateral=1, collapsed=0): 0 .. 0.05 : 0.00261217 0.05 .. 0.1 : 0.000614628 0.1 .. 0.15 : 0.000768285 0.15 .. 0.2 : 0.000307314 0.2 .. 0.25 : 0.000921942 0.25 .. 0.3 : 0.000614628 0.3 .. 0.35 : 0.000307314 0.35 .. 0.4 : 0.000691457 0.4 .. 0.45 : 0.000768285 0.45 .. 0.5 : 0.000921942 0.5 .. 0.55 : 0.00184388 0.55 .. 0.6 : 0.00291948 0.6 .. 0.65 : 0.00752919 0.65 .. 0.7 : 0.0175169 0.7 .. 0.75 : 0.0275046 0.75 .. 0.8 : 0.0573141 0.8 .. 0.85 : 0.0823602 0.85 .. 0.9 : 0.109557 0.9 .. 0.95 : 0.189459 0.95 .. 1 : 0.495467 min 3.96433e-08 for triangle 12135 max 0.999998 for triangle 9406 Edges: min 0.000896871 for edge 2529 points (15.4147 -0.170761 9.28724)(15.415 -0.170519 9.28805) max 0.1165 for edge 8936 points (15.655 2.68481e-25 9.42425)(15.7715 -2.49081e-25 9.42434) Checking for points less than 1e-6 of bounding box ((0.611 0.637888 0.170979) metre) apart. Found 0 nearby points. Surface is closed. All edges connected to two faces. Number of unconnected parts : 1 Number of zones (connected area with consistent normal) : 1 End Code:
Create time Create polyMesh fluid for time = constant Time = constant Mesh stats points: 10407655 faces: 30521475 internal faces: 30168820 cells: 10058917 faces per cell: 6.03348 boundary patches: 15 point zones: 0 face zones: 0 cell zones: 1 Overall number of cells of each type: hexahedra: 9939354 prisms: 1482 wedges: 3 pyramids: 0 tet wedges: 85 tetrahedra: 0 polyhedra: 117993 Breakdown of polyhedra by number of faces: faces number of cells 4 403 5 295 6 3717 7 1044 8 506 9 111574 10 8 12 426 15 20 Checking topology... Boundary definition OK. Cell to face addressing OK. Point usage OK. [localhost.localdomain:08153] 7 more processes have sent help message help-mpi-btl-base.txt / btl:no-nics [localhost.localdomain:08153] Set MCA parameter "orte_base_help_aggregate" to 0 to see all help / error messages Upper triangular ordering OK. Face vertices OK. Number of regions: 1 (OK). Checking basic patch addressing... Patch Faces Points inlet 1089 1191 frontier 8217 8788 outlet 1089 1190 ground 2739 3045 front-upper 6262 6865 front-mid-lower 5888 6378 lips-lower 318 438 lips-upper 249 380 splitter 721 837 throat 504 656 aftmid 2260 2402 tail 658 756 flap 577 623 Checking geometry... Overall domain bounding box (0 -10 0) (50 10 20) Mesh has 3 geometric (non-empty/wedge) directions (1 1 1) Mesh has 3 solution (non-empty) directions (1 1 1) Boundary openness (1.33e-14 -7.70752e-16 -1.3329e-16) OK. Max cell openness = 4.93108e-16 OK. Max aspect ratio = 31.2552 OK. Minimum face area = 2.10001e-07. Maximum face area = 0.372755. Face area magnitudes OK. Min volume = 6.34466e-10. Max volume = 0.224499. Total volume = 19999.9. Cell volumes OK. Mesh non-orthogonality Max: 64.7792 average: 3.60738 Non-orthogonality check OK. Face pyramids OK. Max skewness = 2.97707 OK. Coupled point location match (average 0) OK. Mesh OK. End |
|
![]() |
![]() |
![]() |
![]() |
#2 |
Senior Member
Alan w
Join Date: Feb 2021
Posts: 278
Rep Power: 6 ![]() |
Concerning my flow problem, my theory of the day is that it is related to the use of .stl files. Recently I saw a video by the Wolf Dynamics people, who I respect greatly, saying that .stl files can be problematic and should be avoided if possible. So I looked at the available output formats in salome, which are .stl and .unv.
If I create a .unv file and copy it into OpenFoam, then I must use the unvIdeasToFoam utility to convert it, but this creates a 3D domain mesh in polyMesh. If I have many bodies to work with, I'm not sure how to deal with a bunch of different polyMeshes. What I really want, is a 2D surface mesh file that snappyHexMesh can operate on in order to create a 3D domain mesh. My snappyHexMeshDict file has all the different bodies listed in it, in order to create the final domain polyMesh. So the problem is, how do I convert a .unv file from salome into a .obj file that I can directly use in snappyHexMesh? SHM can deal with .stl, .obj and .vtk files. I have been searching for a method, so far without luck. This is all irritating due to the motorBike tutorial making use of .obj surface files in its processing of geometry with SHM, without giving us any clue of the origin of the .obj files. My CAD system won't output .obj files, nor will salome. It also dumps a group of .obj files into inGroups, without any explanation of how that is done, but that's another story. I'm hoping that a generous and smart community member can shed light on all this. |
|
![]() |
![]() |
![]() |
![]() |
#3 |
Senior Member
Yann
Join Date: Apr 2012
Location: France
Posts: 1,169
Rep Power: 27 ![]() |
Hello Alan,
It might sound like a stupid question, but are you sure your streamlines are not deviated in the 3rd direction? Are you plotting 3D streamlines or streamlines on a slice? Regards, Yann |
|
![]() |
![]() |
![]() |
![]() |
#4 |
Senior Member
Alan w
Join Date: Feb 2021
Posts: 278
Rep Power: 6 ![]() |
Hi Yann,
Thanks for responding! I have looked at the streamlines using the native OpenFoam streamlines function with a dict file in the system directory, and also using streamtracer in paraview. They look the same in the two different methods. The views show them superimposed on a slice, but the streamlines actually move a little in the transverse direction, but not much. Attached are more views of the situation, showing both of the streamline generation methods. It's weird, the flow sees the duct lip, and flows around sort of okay (although the stagnation points are in a strange location), but after that they just dive down and ignore the expansion of the duct. I am in the process of getting a one month free trial of a commercial meshing tool, and it will be interesting to see how this case works out. Alan w |
|
![]() |
![]() |
![]() |
![]() |
#5 |
Senior Member
Alan w
Join Date: Feb 2021
Posts: 278
Rep Power: 6 ![]() |
Hi again Yann,
One template simulation that you helped me with is precious, as it runs correctly! This one is my radiator-parallel simulation. So I took one of the bodies from my problem simulation, and stuck it into this template. When I ran it, not only are the streamlines around the new piece are totally wrong, but the ones around my original template body are messed up too! Check out the attached image. To make sure it's not a problem with boundary condition values, I copied all of the values from my problem simulation into original version of the template, and it ran fine, as can be seen in the other image. Somehow, body meshes in the problem simulation carry the problem with them. I think the problem is with salome. Salome, J'accuse! |
|
![]() |
![]() |
![]() |
|
|
![]() |
||||
Thread | Thread Starter | Forum | Replies | Last Post |
[General] Problem with streamline animation | luca.bor | ParaView | 0 | December 6, 2018 08:00 |
Mesh& steptime independant: conduction-convection problem | Fati1 | Main CFD Forum | 1 | October 28, 2018 13:52 |
Gambit - meshing over airfoil wrapping (?) problem | JFDC | FLUENT | 1 | July 11, 2011 05:59 |
natural convection problem for a CHT problem | Se-Hee | CFX | 2 | June 10, 2007 06:29 |
Adiabatic and Rotating wall (Convection problem) | ParodDav | CFX | 5 | April 29, 2007 19:13 |