Incorrect OBST processing causes a MESH-ZONE error

[mst-lyubimov]

While testing our front-end solution for problem that started to be discussed in issue #10874 we found a new problem - incorrect processing of some OBST elements.
In some cases it results in the same error
ERROR: ZONE 2 meets ZONE 1 at the boundary of MESH 2 and MESH 1
The error occurs in FDS 6.7.7 - 6.7.9
A simple example that generates the error:

&HEAD CHID='test' TITLE='Test project' /
&TIME T_END=10/
&MESH IJK=6,4,6 XB=5,6.5,2,3,-3,-1.5 /
&MESH IJK=3,3,3 XB=5,6.5,3,4.5,-3,-1.5 /
Wall 1
&OBST XB=5,5.5,3,3.5,-3,-1.5 RGB=89,89,89/
Wall 2
&OBST XB=5.5,6,2.5,3,-3,-1.5 RGB=89,89,89/
The next Wall 3 does not lie on the MESH border.
If it is present, a flat element appears on the border, which should not be there.
In addition, an error occurs. ERROR: ZONE 2 meets ZONE 1 at the boundary of MESH 2 and MESH 1
Wall 3
&OBST XB=6,6.25,2.25,2.75,-3,-1.5 RGB=89,89,89/
&TAIL /

In SmokeView, we see the following picture. There should be no flat element. This is mistake. Moreover, since the artifact hit the mesh border, we got an error:
ERROR: ZONE 2 meets ZONE 1 at the boundary of MESH 2 and MESH 1

If we remove Wall 3 from the source file, we get a correct situation and no error.

If we leave only Wall 3, then the incorrect OBST processing persists. Of course there is no MESH-ZONE error, because MESHes are not separated by walls everywhere.

[rmcdermo]

Thanks for the report. We will take a look.

[mcgratta]

I fixed a few bugs in my initial fix.

[rmcdermo]

Should be working now. If firebot passes tonight, then you can test with the latest bundle.

@bryanwklein We wanted to make sure you were aware of this case. It is a tricky case for FDS to handle in that the snapping rules can become very complicated. To whatever extent Pyrosim can help avoid or identify OBST that are dangerously close to coarse-fine mesh interfaces, that would be useful. We will continue to try to flag errors where we can. Thanks

[rmcdermo]

Also, I'm nominating this for a Boris. The test case was nice and simple, and the effect on zones is quite important.

[bwklein]

@bryanwklein We wanted to make sure you were aware of this case. It is a tricky case for FDS to handle in that the snapping rules can become very complicated. To whatever extent Pyrosim can help avoid or identify OBST that are dangerously close to coarse-fine mesh interfaces, that would be useful. We will continue to try to flag errors where we can. Thanks

We do a detection like this already for "HOLE" objects, but not for OBST. What would be a 'safe' rule for best handling OBST on MESH boundaries?

[rmcdermo]

Well, the problem is that "safe" depends on what the user is trying to achieve. For the this particular case, the key point is that the user does not want two separate zones to form. So, anything that causes the coarse mesh to think there is an OBST on the other side is a problem.

If the input geometry (say from CAD) is not water tight, but the resulting FDS geometry is (causing two separate zones), then the user probably needs to be warned, with some hint for how to overcome the issue. But I'm just thinking out loud here, if there are better ideas, we are happy to hear them.

[bwklein]

Ok, maybe this was fixed in your work above, but why did the course mesh think that the smaller OBST (Wall 3) was adjacent? There were empty cells separating the course mesh from the OBST in the smaller mesh.

[rmcdermo]

In this case, it was a bug that Kevin fixed.

But... if you nudge wall 3 closer and closer to the interface, eventually it snaps to the interface. At that point, the coarse mesh has no alternative but say it is blocked, even though Wall 3 does not extend to the x boundary. FDS correctly flags an error, telling the user that zones cannot change across the thin obstruction created on the coarse mesh. In this simple example, it's pretty obvious how to fix it. But if this were buried in a complicated case, I could imagine it being hard to detect.

[mcgratta]

In a nutshell, if an obstruction snaps to the interface of a coarse and fine mesh, PyroSim should draw the obstruction on both meshes. On the fine side, you would see more of less the same obstruction, only it would extend all the way to the mesh interface. The coarse mesh would have to create a thin obstruction that spans the entire cells or cells. If not holes are plugged by this, no problem, but as in the case above, the hole got plugged.

[bwklein]

In a nutshell, if an obstruction snaps to the interface of a coarse and fine mesh, PyroSim should draw the obstruction on both meshes. On the fine side, you would see more of less the same obstruction, only it would extend all the way to the mesh interface. The coarse mesh would have to create a thin obstruction that spans the entire cells or cells. If not holes are plugged by this, no problem, but as in the case above, the hole got plugged.

Thank you, I will enter a feature request for this into our tracker.

[mst-parkhachev]

In latest bundle FDS6.7.9-333_SMV6.7.21-184_tst_win this error persists.
Maybe it's not a new enough build...

[rmcdermo]

We had warnings from our continuous integration system the night before last, so the bundles did not build. Windows might lag a day behind the linux bundle, as sometimes there are snags with that deployment. We are working on using the GitHub Actions to deploy the bundles, but that is not finished yet.

So, yes, wait until you see a Windows test bundle from today or after at the link above and let us know. Thanks

[mst-parkhachev]

Now it works well, without excess wall and zone error!
Thank you!

[rmcdermo]

OK, thanks. Let us know if you see other issues.