Problem with reading obstruction data after cutting with holes

[C-Rogge]

So I observed a problem while reading data of obstructions, which had been cut by a HOLE-line:

The obstructions seem to get cut in multiple pieces (which reflects the behavior of SMV as far as I know), but only one of those pieces actually makes it into the data read by the fds-reader.

A simple example (fds-file attached) yields the following output for bounding_box.as_list() of a wall-obstruction: [0.0, 1.0, 0.0, 0.1, 0.0, 1.0] While yielding only a part of the original obstruction when being cut: [0.3, 0.7, 0.9, 1.0, 0.0, 0.3] (originally 0.0, 1.0, 0.9, 1.0, 0.0, 1.0 with a hole in 0.3, 0.7, 0.9, 1.0, 0.3, 0.7)

The array of the boundary data also has a different shape (199 x 5 x 4 in opposition to 199 x 11 x 11).

Hole-Testcase.fds.txt

Edit: While further testing i also failed to get obstruction IDs within the reader. All imported obstructions always seem to be named 1, 2, 3 etc., not by their IDs within the sourcefile.

[JanVogelsang]

Hi, unfortunately, the IDs of the obstructions are not part of the output in FDS and can only be read by analyzing the corresponding .fds-file (@lu-kas please correct me if I am wrong). As we can't assume that the .fds-file in the directory (or in any other location) matches the generated .smv-file (or other output) files, we are not using that inside the reader (as apparently the .fds file can be modified after running the simulation).

Regarding your original problem, this is something that should definitely work and is probably a bug, which I will investigate as soon as possible.

[lu-kas]

No, the IDs of the OBSTs seems to get lost. I will ask in the SMV forum if this could be added.

[lu-kas]

https://github.com/firemodels/smv/issues/1487

[lu-kas]

Glenn implemented an output of OBST IDs into the SMV file, see above-mentioned issue.

[JanVogelsang]

Alright, should be easy to add.

[JanVogelsang]

Unfortunately, the nightly build does not work with the OBST example case in the repository anymore. @lu-kas Could you fix the fds-file?

[JanVogelsang]

I looked into the hole-problem again and I am now able to distinguish obstructions created dynamically by FDS due to a hole and obstructions without any holes in it. In SmokeView you can see the (up to) 4 obstructions created by FDS when there is a hole inside an obstruction when you look at the obstruction outlines.
The question is, how would you expect the fdsreader to handle these obstructions? Should 4 obstructions be created, just as FDS does? But then you would not be able to combine multiple sub-obstructions of multiple meshes anymore.

[C-Rogge]

After some pondering about this, i dont see any other possibility to be honest. Especially because there would be multiple surfaces with the same IOR and the same coordinates, for example the sides of a wall and those of a window cut into it (for instance both IOR +1 / -1 and overlapping y and z coordinates, just differing in x-direction). This would break the data structure given by the fdsreader as far as i am aware, for example when reading boundary data.

So, yeah. 4 new obstructions for each hole i guess.

[JanVogelsang]

Alright, I implemented it in this way now, namely all obstructions with holes that are split up in up to 4 new obstructions are considered completely new obstructions with no relation to the (previously) same obstruction in other meshes. The new obstructions get a unique id (name): '_from-hole-x', the x being replaced by a number between 1 and 4 respectively.

Please check this out in 1.9.6 (or newer) and tell me if this solution is fine for you and meets your needs.

[C-Rogge]

I'd guess this only works with the nightly build, too?

[JanVogelsang]

Hm, I think it should work with the current FDS version as well. Did you try it and got an error? Can't quite remember, but I think I tested this with both nighly and the last release.

[C-Rogge]

Just yesterday i saw those _from-hole-x-obstructions in another simulation of mine, so it seems to work, although i did not test its actual behavior yet. I'll look into it soon.

[C-Rogge]

So, i know its been a while, but i finally came to get some results from this new implementation. By accident.

I was just trying to pinpoint a new problem i observed while trying to read boundary data: The boundary data was not allocated within the expected obstructions, e. g. the boundary data belonging to obstruction 1 was saved to obstrution 2 or similar.

This only showed for the bounding_box did not fit the shape of the global data arrays nor the coordinates i got from get_coordinates().

While trying to pinpoint this problem in a good example file for a new issue here, i found that this is actually related to the whole hole problem (pun intended). When cutting through an obstruction, the general boundary data seems to get messed up, even when cutting through an obstruction which did not contain boundary data in the first place.

Long story short: Here is an example file: BoundaryTestCase.fds.txt

As you can see there are only two obstructions included, one with boundary data one without. A hole is cut through the one without boundary data.

When printing the obstructions with

for obst in sim.obstructions:
    print(obst)

the output is

Obstruction(id=2, Bounding-Box=Extent([1.90, 2.00] x [0.00, 2.00] x [0.00, 2.00]), SubObstructions=1)
Obstruction(id=1_from-hole-1, Bounding-Box=Extent([0.00, 0.10] x [0.50, 1.50] x [1.50, 2.00]), SubObstructions=1, Quantities=['temp', 'AST'])
Obstruction(id=1_from-hole-2, Bounding-Box=Extent([0.00, 0.10] x [0.00, 0.50] x [0.00, 2.00]), SubObstructions=1)
Obstruction(id=1_from-hole-3, Bounding-Box=Extent([0.00, 0.10] x [1.50, 2.00] x [0.00, 2.00]), SubObstructions=1)
Obstruction(id=1_from-hole-4, Bounding-Box=Extent([0.00, 0.10] x [0.50, 1.50] x [0.00, 0.50]), SubObstructions=1)

You can see how obstruction 2, which should hold the boundary data, does not contain any, but one of the _from-hole-obstructions does. This is the data of obstruction 2, which can be confirmed by the following:

print(sim.obstructions.get_by_id('1_from-hole-1').get_coordinates()[-1])

which outputs

{'x': array([0.]), 'y': array([0. , 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 1. , 1.1, 1.2,
       1.3, 1.4, 1.5, 1.6, 1.7, 1.8, 1.9, 2. ], dtype=float32), 'z': array([0. , 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 1. , 1.1, 1.2,
       1.3, 1.4, 1.5, 1.6, 1.7, 1.8, 1.9, 2. ], dtype=float32)}

which are the coordinates of obstruction 2.

[C-Rogge]

Any new insights on this?

[JanVogelsang]

Sorry, I currently don't have the capacity to look into this issue. Will be able to take some time for this again in a couple of months.
@lu-kas Any chance you or someone else might have the time to look into this before I will?

[JanVogelsang]

@C-Rogge Sorry for taking so long to fix this, but I finally found some time and think I fixed it. Please try version 1.9.11 and see if everything works for you now.

[JanVogelsang]

@C-Rogge I will close this issue for now, but please reopen it if you encounter any issues!