[boffin5]

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:

\
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

And the checkMesh for the fluid domain also looks okay:

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

Salome has been giving me bad meshes, and I have learned to clean them up by using Meshlab and Meshmixer. But even after using these tools, my simulation is still failing. At this point I am flummoxed and don't know where to go. And I am really suspicious of salome. Help!!

[boffin5]

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.

[Yann]

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

[boffin5]

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

[boffin5]

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!