BUG: SHM can't resolve wall boundary near faceZone

case1.tgz

When used with new mutli-location method:

• Attached case illustrates the wall frame (top and bottom) is not resolved.

When old style is used (defining single locationInMesh, and using faceZone+cellZone combination for HX)

• The mesh leaks inside these frames

The single wall thick (baffles) are never resolved as walls (HX_CAC_FRAME.stl)

This might be cirtical to block the flow for inclided HX, unless there is any other family blocking the flow from sides.

@andy @Sergio

What is it different from your simple testcase that we debugged the multi-region handling with? That contained a stand-alone faceZone.

The difference is:

In these cases, there is a cellZone nearby the faceZone.

The target is to have heat exchanger (cellZone), all surrounding enclosures (faceZone) and also adjacent frame (four sides) as wall.

In OF23x, the wall on frame is available, whereas in plus version, there is only faceZone. Although a separate geometry is provided (duplicate) to make as wall.

Does it work with single locationInMesh (i.e. is plus backwards compatible)?

No, it doesn't.

Probably the reason being allocation of faces to faceZone/baffle.

Small remark: your stl files have a 'color' entry in them. This makes them unreadable by paraview.

Ok! Thanks for the note. :)

1. From what I can see the behaviour for the attached case1 with

• multiple locationsInMesh + no faceZones seems to be correct:
• no cells inside the frame (there is no locationsInMesh inside the frame)
• faces inbetween cellZones get automatically allocated to a synthesised faceZone (and this takes precedence over any surface intersection)

2. I'll try the case with a single locationInMesh + faceZones

@Roger : the topic you are interesting in

Was there any update on this Mattijs?

No update. Can you post the case with the single locationInMesh syntax?

Attached the case with singleLocationInMesh syntax case2.tgz

Am getting a failure:

log.snappyHexMesh

With the case2 setup I get the same result in plus and 23x in terms of cellZones.

• the geometry has coincident faceZone geometry and normal patch geometry
• both versions produce the same faceZone and cellZone. The difference is in the patching.
• 23x allows this (so the are boundary faces in the faceZone) and this causes the 'frames' of the geometry to become empty. However the patching is bad - it has gaps in it.
• in dev: faceZone seems to 'win'. Now the regioning walks into the frames and they become part of the mesh (but luckily not in the cellZone)

After retaining single instance of geometry for frames and using locationsInMesh for multi-domain

• the expected 'wall' is obtained

• however, probably due to 'faceZone' definition of frames, the cells inside rectangular cavity of frame is not removed.

Attached the case for reference:case3.tgz

Simple example case is attached. twoRegions.tgz

It contains two boxes sharing an interface. One of the box is defined as cellZone whereas the other is wall.

But the mesh penetrates inside part2 box.

I am running with 23x as comparion: ~/OpenFOAM/mattijs-plus/run/Customers/ESI/Prashant/test_gitlab66/twoRegions_23x/

vs

~/OpenFOAM/mattijs-plus/run/Customers/ESI/Prashant/test_gitlab66/twoRegions_plus

Can you check the 23x faceZone? That looks strange.

snappyHexMeshDict

I put the locationInMesh outside both boxes and changed two of the layer settings so it runs in 23x.

meshRefinementBaffles.C

Hi Prashant,

can you try attached version of src/mesh/snappyHexMesh/meshRefinement/meshRefinementBaffles.C ? Maybe also on some more complex cases?

I've changed the logic so any unassigned mesh-region (so no locationInMesh or a closed surface with a cellZone/faceZone) will stay unassigned (and so get removed). This was the default behaviour in 23x.

But this doesn't seem to work when the point is within one of the boxes (original files)

mentioned in commit ccac7d67dd446e5cc0b67aaa4f0d07094398f99f