search

firemodels / fds

Fire Dynamics Simulator
https://pages.nist.gov/fds-smv/
Other
666 stars 624 forks source link

MATL order in HT3D #13361

Open Vojta-Salek opened 2 months ago

Vojta-Salek commented 2 months ago

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: image

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. 1_MATL_order_comparison

Desktop:

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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!

1_MATL_order_comparison_withoutDT

mcgratta commented 2 months ago

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

mcgratta commented 2 months ago

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

Vojta-Salek commented 2 months ago

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 commented 1 month ago

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

mcgratta commented 1 month ago

I've looked at the case again. One issue is that you have placed the inside-solid devices exactly at 5 and 15 mm below the upper surface. These two points are exactly at the dividing line of internal cells. The tiniest change in thickness causes the device to shift to one cell or the other, which is why the plots look so different. There still might be a very small effect from the order of the MATL lines, but it is much less pronounced now. Try these lines

&DEVC XYZ=0.025, 0.025, 0.04, ID='Temperature_0.005', QUANTITY='INSIDE WALL TEMPERATURE', IOR=3, DEPTH=0.0051 /
&DEVC XYZ=0.025, 0.025, 0.04, ID='Temperature_0.015', QUANTITY='INSIDE WALL TEMPERATURE', IOR=3, DEPTH=0.0151 /
&DEVC XYZ=0.025, 0.025, 0.04, ID='Density_0.005', QUANTITY='SOLID DENSITY', IOR=3, DEPTH=0.0051 /
&DEVC XYZ=0.025, 0.025, 0.04, ID='Density_0.015', QUANTITY='SOLID DENSITY', IOR=3, DEPTH=0.0151 /

image image

mcgratta commented 1 month ago

Here is the burning rate. There is still a very small difference that grows with time. Not sure if this is just some random number thing or a effect of the MATL line order. I'll keep digging. image

Vojta-Salek commented 1 month ago

Thank you very much for your reply. I see now that I didn't even think to check the position of the inside-solid devices when I wrote the initial issue report - apologies for that. It is good to realize that the same problems that occur when DEVCs are placed at the computational cell boundaries in the gas phase (which I believe users are well aware of) can also happen within the solid phase.

Is it okay if I add a couple of slightly related questions here, or should I create a separate issue? I think I have also encountered some suspicious behavior of MATL lines order when using HVAC vents.