MATL order in HT3D

[Vojta-Salek]

Describe the bug
The order in which MATL lines are listed in FDS code influences the outcome of the simulation in HT3D mode although each OBST is explicitly given a MATL_ID. The method of OBST properties definition (using both MATL_ID and SURF_ID) is equivalent to the example given in the FDS guide, chapter 8.4.1:

I am submitting this issue because at first glance everything looks fine, but the results can vary without the user being aware.

To Reproduce
I have created a simple case of two heated obstacles (boxes) on top of each other. Bottom box is assigned artificial burning material properties, top box is assigned artificial nonburning properties. For both boxes, SURF_ID is used to invoke HT3D and MATL_ID is used to define material (e.g., burning or nonburning MATL) properties. I have attached below two identical FDS codes differing only in the order of MATL lines in FDS code. A simple python code for quickly plotting the outputs is also given (in .txt, .py is not supported).
0_MATL_order_burning_first.txt
0_MATL_order_nonburning_first.txt
Read_data.txt

Expected behavior
Since MATL_ID is explicitly specified for each OBST, I would expect the order of listing particular MATL lines in FDS code to be irrelevant. However, it actually is not the case.

Screenshots
The temperature of the top box in case burning MATL is listed as first ("Temp. top 1st burning") is clearly different compared to the case burning MATL is listed as second ("Temp. top 2st burning"). The same goes for the bottom box and for densities.

Desktop:

• OS: Win. 10 Pro
• Version: FDS-6.9.1-657-g64f473f-nightly

Additional context
Can be solved by adding MATL_ID and MATL_MASS_FRACTION to each SURF line but only if the user is aware that it is not enough to specify MATL_ID at OBST line. In more complex FDS codes, such behaviour can easily be overlooked.

[mcgratta]

This is a good bug. The problem is that for 3D solids, the surface information is not getting to all the layers. I'll fix.

[mcgratta]

I fixed the problem, and a new test code should be ready in a few days.

I have nominated you for the coveted Boris Stock Award. Excellent bug report.

[Vojta-Salek]

I fixed the problem, and a new test code should be ready in a few days.

I have nominated you for the coveted Boris Stock Award. Excellent bug report.

Thank you for your tireless dedication to code development and for the nomination.

If I may ask one more question about this topic - after fixing the bug, will there be any difference between specifying MATL_ID: A) only for OBST, B) only for SURF, or C) for both OBST and SURF simultaneously? Assuming HT3D is used and no thickness or multi-layered approach is applied to SURF. I basically want to create (for now) an OBST whose size for the inner heat transport is consistent with those in the gas phase solver.

The goal is to be able to stack multiple one-cell-thick objects on top of and next to each other in various ways while specifying possibly different material properties (burning or non-burning) for each object. If this was possible, including correctly solved heat transport between individual objects, it would open a new possibilities for the research on, for example, piled solids composed of possibly multiple materials and containing macroscopic voids/pores. (I am aware that this is far beyond from what FDS was originally intended for. Yet it is and will naturally continue to be a tool bent for the needs of researches dealing with solid thermal decomposition and fire spread.)

[mcgratta]

The way things are evolving for HT3D, you should set MATL_ID on the OBST line. The SURF line should have HT3D=T and MATL_ID only if there are very thin layers at the surface.

[Vojta-Salek]

May I kindly ask if the bug has been succesfully solved?

The results from new nightly builds (e.g., FDS-6.9.1-829-g244dbce-nightly) show improvement compared to the previous version (FDS-6.9.1-657-g64f473f-nightly). However, the temperatures in the test scenario provided above still show discrepancies depending on the line order, even in new builds. Although it looks more like some nummerical issues (?).

Thank you for the clarification. I may have found some other unintended FDS behavior loosely related to this topic, but I would like to confirm whether this issue is solved before I start working on another simplified scenario for the bug report.

Thank you!

[mcgratta]

Are you using the exact same input files as above? If not, post them here.

[mcgratta]

I looked back at the cases. I did not notice that there was still a slight difference. I'll fix.

[Vojta-Salek]

Yes, I confirm that exact same input files as above are used. I have only changed some colors in the plot to distinguish (partially) overlapping curves (Read_data_2.txt).

Thank you very much for looking into this. If there's anything I can help you with at the moment, please let me know.

[mcgratta]

I'm still working this. It is a very tricky bug to catch.