HVAC leak error with MATL line order

[Vojta-Salek]

Describe the bug
When using the &HVAC feature (TYPE_ID = 'LEAK') and HT3D=T, an error (ERROR(543): Cannot leak and specify flow or pyrolysis at the same time.) occurs, even though the associated VENTs (VENT_ID and VENT2_ID) are not at burning surfaces or surfaces with otherwise defined flow. This error only happens if any burning MATL line is specified before non-burning MATL lines in the FDS input file. In other words, the order of burning MATL lines in the code matters, even if these lines are not assigned to any surfaces (and certainly not to any HVAC-related surfaces).

To Reproduce
A simple model of a small, heated enclosed space bounded by non-burning obstacles with a burning box (PMMA) inside was created. The HVAC leak connects the enclosure with an open space (e.g., to prevent from overpressure and density increase). Three versions of the FDS input file are provided:

• A) Version with "incorrect" MATL line order producing the error message.
  Leakage_error.txt

• B) Version with "correct" MATL line order, where the burning MATL is not listed first by chance, avoiding the error.
  Leakage_noMATL_ID.txt

• C) Version with MATL_ID and MATL_MASS_FRACTION specification added to each SURF line from Version A). This eliminates the error message, although, this should not be the correct solution in the long term as noted here.
  Leakage_MATL_ID.txt

(Un)expected behavior

• For Version A: The error occurs as described above.

• For Version B: The thickness of the PMMA block is gradually decreasing indicating decomposition, and MMA production is reported in the CHID_hrr file. However, no burning (HRR) or pyrolysis products (MMA) are to be found anywhere in the domain, even with AUTO_IGNITION_TEMPERATURE = 0.

• For Version C): The behavior seems to be as expected. Once pressure difference is eliminated between both pressure zones, MMA fraction inside the compartment get slowly diluted by oxygen from outside, and once AIT temperature is reached inside, the remaining MMA ignites. The only un-physicall behavior observed is the step change in pressure and composition, however, I understand that this is due to rapid "mixed is burned", when AIT is reached.
  

Desktop:

• OS: Win. 10 Pro
• Version: FDS-6.9.1-829-g244dbce-nightly (includes fixes from previous bug #13316 concerning surface information within layers when using HT3D)

Additional context
In addition to the main issue, I noticed a few other unexpected behaviors, though I have not investigated them thoroughly. Perhaps a couple of them may be worth to share:

1. Burning rates loaded from the boundary file show burning at non-burning surfaces. I was not expecting this outside the sealed pressure zone 1. I understand that pyrolysis products can transfer to the opposite side of an adjacent cell, if a particular pyrolyzing surface is covered by other OBST. Does this behavior make sense even if the OBST covering pyrolyzing surface is a non-burnable material?

2. The automatically generated pressure for pressure zone 1 in the CHID_hrr file slightly differs from the pressure measured by a DEVC placed within the same zone. Although the difference is negligible, I tend to be cautious about automatic outputs.
   

[drjfloyd]

I'll take a look.

For pressure the value in the hrr file is the background pressure only whereas a PRESSURE device is the total pressure or background plus perturbation. These are not the same output.

[drjfloyd]

@mcgratta in the first case attached it throws an error in HVAC that the wall vent has a flow rate assigned. This is happening because the SURF_ID assigned to the VENT has HT3D. With no MATL_ID, in read.f90 MATERIAL(1) is assigned as a dummy. When MATERIAL(1) in the input has a reaction this then throws an error in HVAC as the SURF is assigned PYROLYSIS_PREDICTED. HVAC inputs are processed after PROC_SURF which is before we set boundary condition properties for HT3D OBST in init.

For HT3D instead of pointing to MATERIAL(1) should we append a dummy material to the material array to point to where that dummy material has no reactions?

The next two cases also seem to be HT3D issues.

[mcgratta]

I like the dummy material idea. That might solve a number of problems related to HT3D. I'll check it out.

[mcgratta]

There is already machinery for reserved materials, so I will just add one more.

[mcgratta]

I think I have a fix for the first problem. I'm testing that. The third case is trickier.

[Vojta-Salek]

Thank you for looking into and addressing this issue.

Could you please briefly explain what is currently happening in FDS when MATL_ID is added to SURF (containing HT3D=T) without specifying any THICKNESS? Thank you very much in advance.

I used to specify MATL_ID for both OBST and SURF simultaneously to avoid the Error 543. However, I have noticed that even without any HVAC lines, my simulation results differ when MATL_ID is only specified for OBST compared to when the same material is specified for both SURF and OBST (without providing any THICKNESS).

If needed, please let me know and I can try to create a simple case to demonstrate this, but I believe you are already tracking the issues.

[mcgratta]

I'm making steady progress on this issue. I'll explain it briefly. Before we introduced a 3D solid phase conduction option, the SURF and MATL lines completely described both the chemical composition and geometry of the surface and underlying solid. These lines are read by FDS first, before OBSTs and VENTs. Much of the initial set up for the boundary conditions is done just after we read the SURF line parameters. Now, however, we have the problem that we do not know the final make-up of each solid surface cell until all the OBSTs and VENTs are parsed and the entire geometry is assembled. In your examples, for example, we do not know at the time of reading the parameters that there is going to be a pyrolyzing material "buried" within a stack of non-pyrolyzing solids. Same for HVAC and other things that we typically set up at read time.

Anyway, long story short, I am steadily introducing logic into the read routine that creates "placeholder" parameters for these 3D solids. You can run your various test cases with the latest test build and see that we're getting close. Your last example involving HVAC is close but not exactly right. I have also had to throw an ERROR in some cases to prompt the user to include the MATL_ID on both the SURF and OBST lines in a limited number of circumstances where it has become too difficult to work the logic. Hopefully, that will only occur in a few cases.

[Vojta-Salek]

Thank you for the explanation; I feel like I have a better understanding now. That is why I didn't notice any differences with single-cell solid OBSTs, but when multiple obstacles are placed next to each other, strange things happen as MATL_ID at SURF line is read before the OBST definition, which contains additional information about the geometry and properties.

Regarding the second paragraph and the newly introduced ERROR, maybe it was not a good idea by me to use the same SURF for all obstructions made of the same material, regardless of whether they were connected to HVAC VENT or not. By doing so, I specified MATL_ID through SURF even for all other "ordinary" obstacles of that material, which didn't require this information, as they would have received it later based on the OBST line. As a result, I have in fact prescribed the "wrong" geometry and properties to all of those "ordinary" obstacles, that would otherwise have had no problem.

[Vojta-Salek]

I would like to share some recent observations using HT3D.

Although the bugs mentioned above, related to the order of MATL lines and MATL_ID specified on OBST or SURF lines, were mostly resolved, I am still observing significant differences for more complex geometries. These differences are likely caused by a combination of two other bugs (#13597 and #13361).

Bug #13597 causes large numerical errors if shrinking occurs, while bug #13361 is mostly fixed but still allows a very small discrepancy in the burning rate, which propagates through the simulation. I assume that this very small discrepancy is randomly amplified by the large unpredictable shrinking errors. As a result, I can see large discrepancies for more complex domains when the order of MATL lines or MATL_ID placement differs. If shrinking is prevented by introducing char with an appropriate density (char yield * virgin material density), the simulation stabilizes. The only remaining issue is the minor discrepancy from bug #13361, without further amplification.

The only aspect, that remains unclear to me is whether it makes sense to observe burning rate on non-burnable surfaces when a burnable OBST is covered on both sides in any direction. Previously, I did not observe this behavior, but at that time, an OBST fully enclosed by other OBSTs on all six sides did not release any combustibles upon decomposition. That was when surface information was not propagating through all layers in HT3D, though.