inconsistent behavior with gap between GEOM

[drjfloyd]

The attached case has four meshes each 1 m on a side. At the center of each mesh is a wall made of two GEOM such that there is a gap across the entire width near the mid height. The x+ boundary has an inflow of 1 m/s with 1E-4 kg/kg SOOT.

Case 1: The wall has a 1 cell gap (5 cm) aligned with grid Case 2: The wall has a 1 cell gap split over two grid cells Case 3: The gap is 0.2 cm and split over two grid cells Case 4: The gap is 0.01 cm and in one grid cell

After 20 s the mass of soot on the far side of the wall for Case 1 to 4 is: 3.5E-7 2.0E-6 2.6E-6 2.0E-7

Case 1 and Case 2 should be the same as they have the same gap width. Case 3 should not be an order of magnitude higher than Case 1 and Case 2

geom_gap.fds.txt

[marcosvanella]

Thanks Jason, I'll look into this.

[drjfloyd]

Related question to this issue: Is there a point where GEOM considers a gap between faces to be so small that it should be considered a solid? Thinking of the point where a tool like Pyrosim gets used to create the input and a user has drawn a series of angled parallelpipeds representing a wall. Right now since we block an entire cell, if the user doesn't make sure to snap one wall segment to another it isn't an issue as long as any gap is small compared to the grid cell size. Whatever GEOM does in terms of having minimum gap or not I think we should make sure that GEOM documentation discusses it.

[marcosvanella]

At this point there is no gap blocking. What is done on the velocity reconstruction of cut faces adjacent to the geometries in the gap depends if fluid points can be found (these are regular velocity points on the gas side, part of the immersed boundary method currently being used for cross velocities, something we are working on modifying). In the case of a small gap (one cell or less) these velocities will be assumed zero when no interpolation points can be found. About the mass loss on the gap, that might be tied to flow penetration. I'll check.

[marcosvanella]

This is an interesting problem. I run the case tightening velocity and also forcing to target cross velocities within the pressure iteration loop. the results are similar to what you reported. The main differences here are that the IBM forcing of cross velocities is different on the different meshes (Case 1 and 2) and that cut-cell arrangements (scalar transport) are also different. I don't see how computing Cartesian edge stresses (method we are working on, more similar to OBSTS) instead of forcing velocities will help us here. Defining a minimum gap would be something to consider.

[drjfloyd]

Ran this case again. It dies quickly with a numerical instability for the third mesh where there is a thin gap. For the 4th mesh with a teeny gap it looks like it is just filled in which I think is fine. For the 1st and 2nd with the same gap size offset, the results are now ~20 % different rather than an order of magnitude different.