Two snappyHexMesh bugs

Using SimScale CAD & Meshing
1

Today in not a good day for meshing… I came across two different snappyHexMesh bugs. But let us start from the beginning.

I tried to create a finer mesh for a new geometry. One of the things I did was to create two different layer zones, one with 2 layers and the other with 5 layers. When I tried to create the mesh I got a funny error:

→ FOAM FATAL ERROR:
Multiple outside loops:0()

I have never seen it before so I started to look for a solution. I found out that the problem were the layers so I tried two different configurations together with the previous one that worked for the previous geometry but still got the error. Finaly I have found out that this is a snappyHexMesh bug and was fixed in the new repositories. Here is the solution:

As I cannot fix it myself I just wanted to see how the new mesh levels are looking. I removed all of the layers from mesh configuration and started the computations again. But unfortunatelly I again got another error:

ERROR: dgraphFold2: out of memory (2)

It was strange for a 21M mesh and 32 cores. I tried again with a smaller mesh (12M) but again got the error. I looked for a solution and one of the suggestions was to run the meshing with lower (sic!) number of processes. Finally I have found out that this is some kind on snappy-scotch problem and it was fixed in some later 2.4.x commit

I have no idea how often those bugs occur (had them for the first time). If any of you had them please raise your hand and click the like button :slight_smile:

@dheiny is it possible to fix those bugs? Do you have any plans of changing OF version that you use (I think that it is 2.3.1 now)?

1 Like
2

Hi @akosior,

great - thanks a ton again for reporting those! That’s very helpful! Both are known and we’re in the process of providing more OF versions to avoid those. However our process of integrating a new solver/mesher code is quite elaborate as we’re running a large validation library on them and testing them extensively for backwards compatibility. I’ll check back with our CFD team to provide an estimate on when this will hit the production system.

In the meantime a potential work-around for both (unfortunately I know them meanwhile quite well :wink: ): Tuning the edge/feature refinement to a higher refinement level helped me to work around the loops:0() problem. For the dgraph, as you said, changing the number of MPI processes helps to avoid the problem. Both should not be necessary anymore soon!

Sorry for the lost productivity on your end!

David

3

@dheiny while we are on the subject of different OF versions, could you add an option for single precision calculations?

Best,
Andrzej

4

Hi @akosior,

interesting feature request! That’s indeed in the pipeline but not very high prioritized. Could you elaborate on the use case where you’d not want to use double precision? Would be great to understand the purpose a bit better.

But already added a +1 for you on the request ;)!

David

5

Hi @dheiny,

it occurs that forces resulting from simulations of the F1 car using single and double precision does not differ much. We could save much time and core hours doing some of our calculations in single precision.

Best,
Andrzej

6

That’s very interesting. Indeed then it makes a ton of sense - in most application/projects I worked in that differed quite a bit, so we ended up choosing almost always double prec! Okay, will be taken into consideration moving forward!