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.

[mcgratta]

I will address the last point. There is a parameter called LAYER_DIVIDE on the SURF line that allows the user to specify from which side of a 1-D slab the fuel gas emanates. I haven't looked at this with respect to HT3D, but I suspect it might give you some flexibility. I hesitate to say that a non-combustible layer will always block fuel gas from escaping because there will inevitably be a case where this is needed. Can you see if LAYER_DIVIDE allows you to redirect the fuel gas.

[Vojta-Salek]

Thank you! I will have a look at LAYER_DIVIDE, do some testing, and report back.

[mcgratta]

Any new developments? I have lost track of this issue.

[Vojta-Salek]

No developments at LAYER_DIVIDE in particular. However, it is on my to-do list and I am still working on HT3D topic for porous matters in general.

Lately, I was trying to address the "artificial char" introduced to prevent decomposing solids from shrinking/swelling (mentioned here). I thought that by giving the char high thermal conductivity and low specific heat capacity, it can become "thermally invisible" and thus not insulate the remaining virgin material. It is not that simple, because char is present also in layers where only part of virgin material is decomposed. Those layers also quickly become very conductive which actually slows down decomposition.

I am also on track of some weird behavior when comparing HT1D to HT3D outputs for a mostly 1D heating scenario. As soon as I make sure I reached a dead end, I will create a simple scenario as usual and post it here.

By the way, do you have an idea what finally solved the issue #13361? Knowing the cause, I may probably skip some test that I usually do after updating FDS. Thank you very much in advance for your support!

[mcgratta]

Issue #13361 was due to initialization of the variable thickness data type. In the past, a SURF line with a given THICKNESS had all of its data structures created immediately after being read in. Now we have to wait until the overall geometry is set up, at which point we can determine that varying thickness of the surface. This was really a matter a book-keeping---not one thing in particular, but a list of things.

[Vojta-Salek]

Finally, I had time to briefly examine the LAYER_DIVIDE feature using FDS-6.9.1-1393-g8882aca-nightly. Based on my simple simulations, it appears the feature functions as intended. However, I tested only a limited range of geometries consisting of single-layer obstacles.

The difference with HT3D is that you can now place multiple objects adjacent to each other, rather than relying on a single large object with multiple layers. Therefore, you can in theory prescribe LAYER_DIVIDE for inner surfaces. However, everything seems to be governed by LAYER_DIVIDE of outer surfaces. I believe it makes sense the way it is designed even for HT3D. I am aware my cases where single-cell obstacles are randomly generated to form a porous matter are out of FDS scope.

One potential enhancement that comes to mind is enabling Smokeview to visualize the decisions made by LAYER_DIVIDE for complex geometries. Would be nice to be able to display which surfaces the OBST produced vapors are connected to. This feature could also be beneficial for multi-layer materials in the default HT1D mode.

During testing, I encountered some unexpected behaviors, likely related to Smokeview:

• In Glitch_1.fds I attempted to generate fuel vapors from a surface covered by another obstacle. At some point, an increase in the burning rate was visible when loading boundary data, but it only manifested as a change in color. The color bar scales remained at 0–0 kg/m²/s. While this is likely irrelevant, I am sharing it since I noticed it by chance.
  Glitch_1.fds.txt
  Smokeview snapshot

• In Glitch_2.fds, I tested covering burning OBST surfaces with non-burning ones. For some geometries, vapors appeared on surfaces that were not aligned with the axes passing perpendicularly through the decomposing material. If you believe this is worth reporting, I can create a Smokeview issue.
  Glitch_2.fds.txt
  Smokeview snapshot

I also conducted simulations related to the Issue #13361. For some more complex geometries, the differences still persist depending on the order of MATL lines. In some cases, the discrepancies were even larger compared to previous nightly builds. Once I have time to create a more simple test case, I will reopen the issue.

[mcgratta]

I cannot replicate Glitch 1 with the version of Smokeview that I am using on Windows

Glitch 2 also looks OK with the latest version of Smokeview

Try adding CELL_CENTERED=T to your BNDF lines. That should color each cell uniformly.

[Vojta-Salek]

I can still see Glitch 1 even with the new SMV-6.9.4-24-g2488ee1-nightly and Win 10 Home (yesterday, I was using the latest standard release SMV 6.9.4). I discovered that the glitch disappears if the FDS run is already completed. If I open Smokeview during calculations, I still see the glitch around 212 seconds.

For Glitch 2, the nightly Smokeview build struggles to load the boundary files. Based on the angle I sometimes see no boundary, sometimes weird patterns. I have also noticed that I see different patterns from the same angle if I switch to full screen. Anyway, once I capture the right angle and the boundary file is loaded correctly, CELL_CENTERED=T prevents creating a gradient away from the desired surfaces - my apologies, I should have done that instantly yesterday.

Here are some weird boundary patterns (had to capture them using a print screen, if Smokeview image is captured, the pattern is not displayed, just white surface as showed in the first example):

[mcgratta]

I downloaded the Smokeview that just posted I see

I should not see the gray surface at the bottom.

[gforney]

should be fixed.
update your smv repo and rebuild smokeview, or
download and install smokeview from https://github.com/gforney/test_bundles/releases/tag/SMOKEVIEW_TEST
or download and install the nightly bundle the next time firebot passes.

I had hard wired an 'epsilon' I used for comparing blockage face positions. this was not appropriate for small grids like in your case. the fix was to define this epsilon relative to the grid size. let me know if you still see a problem

[mcgratta]

Works! Thanks.

@Vojta-Salek could you confirm that it works for you.

[Vojta-Salek]

I confirm that the weird patterns are gone. However, I can still see the bottom surface in Glitch_1.fds changing its color around 212 sec if burning rate boundary is loaded, although burning rate should be zero according to colorbar limits. This only happens if I open Smokeview in the middle of still ongoing FDS calculations - which I think is a common practice to display some results in the middle of ongoing simulation.
Glitch_1.fds.txt

[gforney]

click in the colorbar and scroll from the min to the max value. when I ran the simluation I get that the values though close to zero range from 0.0 to a small number around 3x10^-16 . the non-blue colors you are seeing are at the upper range. I could force smokeview to show only the lower range but I think it is useful to know that the the numbers being visualized are not constant

[Vojta-Salek]

@gforney Understood. It is a bit confusing that max range gets rounded to 0 only after the simulation is complete, but I think it is completely irrelevant. I was worried something else may be wrong. Thank you for your explanation and support!

[Vojta-Salek]

Talking about the previous topic of LAYER_DIVIDE. If I may add a suggestion regarding the LAYER_DIVIDE feature, do you think it would help users if this was described in more detail in the User's Guide? I have two points:

1. LAYER_DIVIDE is mentioned only at the end of an example in Section 8.3.5 (Walls with Different Front and Back), making it a bit hidden. It might be helpful to refer to this section when introducing NU_SPEC(i,j) in the pyrolysis model (Section 9.2.1). For example, adding a note like: "If gaseous species are produced, they will be released from the solid surface according to the LAYER_DIVIDE of the SURF containing the decomposing material; see Section 8.3.5." Maybe even clarify that internal transport is not considered, so species transport is effectively infinitely fast.

2. The description in Section 8.3.5 is intuitive when LAYER_DIVIDE is an integer and no layers fully decompose. However, what happens when LAYER_DIVIDE is fractional? For example, if LAYER_DIVIDE is 0.5 and a SURF has an initial layer thickness of 10 cm, does this mean gases are only produced from the first 5 cm? If the thickness decreases due to decomposition, does the "0.5" proportion update dynamically, or is it fixed to the initial thickness? The same can be asked about dynamically updating when any layer fully decomposes.

[gforney]

looks like smokeview is resetting the bounds in the .bf.bnd file to 0.0 . I"ll see what is going on.

[gforney]

colorbar labels values should now be consistent with data values when values are small. for your Glitch_1 case the 'BURNING RATE' boundary file values are essentially but not quite zero. these values range from 0.0 to 1.7*10^-16 which are now reflected in the colorbar labels. these non-zero values were why you were seeing the bottom patch change color at ~200 s.

as before update your smv repo and rebuild smokeview, or
download and install smokeview from https://github.com/gforney/test_bundles/releases/tag/SMOKEVIEW_TEST
or download and install the nightly bundle the next time firebot passes.

[mcgratta]

I'll explain LAYER_DIVIDE better. Now that we have this 3D option, it is more important now than in the past.

[mcgratta]

I added more explanation about LAYER_DIVIDE. See commit #13909.

\subsection{Solid Phase Gas Transport}
\label{info:LAYER_DIVIDE}

The solid phase conduction/reaction algorithm does not have an explicit transport mechanism for pyrolyzed gases. Rather, the pyrolyzates are assumed to appear instantaneously at the surface. Which surface is controlled by the \ct{SURF} line parameter \ct{LAYER_DIVIDE}, a real number that specifies the number of layers whose gaseous pyrolyzates are to be applied to the surface with the given \ct{SURF} label. For example, if \ct{LAYER_DIVIDE=1.5}, the gases generated by the first layer and half of the second layer shall be applied at the given surface. This same partitioning holds whether or not the solid is shrinking or swelling. Be careful to ensure that the specified values of \ct{LAYER_DIVIDE} are consistent for the \ct{SURF} lines that control opposing surfaces. If two different \ct{SURF} lines govern the front and back of a solid obstruction, the specified values of \ct{LAYER_DIVIDE} should sum to the total number of layers. Otherwise, the mass of evolved gases may not be correct.

If \ct{LAYER_DIVIDE} is not set, it is assumed that for a solid with \ct{BACKING='EXPOSED'}, the gases generated within a depth of half the total thickness are to be applied at the front surface and the other half at the back. If the \ct{BACKING} is not \ct{'EXPOSED'}, all of the gases will be applied at the front surface.

Suppose, for example, that the solid is composed of a layer of insulation on top of a layer of plastic on top of a layer of steel. The steel is impermeable. By setting \ct{LAYER_DIVIDE=2.0} to the \ct{SURF} line whose first layer is the insulation directs the vapors generated by the insulation and plastic to be driven out of the exterior surface of the insulation. Similarly, for the \ct{SURF} line that is applied to the steel, specifying \ct{LAYER_DIVIDE=0.0} would indicate that no fuel vapors are to escape the steel surface. Note that in this instance, the sum of the values of \ct{LAYER_DIVIDE} is not equal to the number of layers, but this is not a problem because the layer of steel does not generate any gases.

[Vojta-Salek]

@gforney Confirmed. The new Smokeview version provides consistent results for both ongoing and completed simulations. I find it more intuitive now. Thank you!

@mcgratta Thank you for your explanation. The description of LAYER_DIVIDE now seems comprehensive, and it has clarified all my black spots.

I believe all my questions and doubts raised during this discussion have been addressed or resolved. The only idea I still have regarding LAYER_DIVIDE is that, as 3D options are likely to see more use in the future, it would be helpful to have a tool in Smokeview to visualize 'layer connections to surfaces'.

If there's anything else I cab contribute to, please let me know. I’d be happy to test more HT3D features, though I may not be able to do so immediately.

[mcgratta]

Thanks for all your efforts. It has helped us tremendously.

As to Smokeview rendering of solid phase quantities, this has been a problem since the very beginning because the solid phase in FDS has been somewhat decoupled from the gas phase. The noding is different, and the total thickness is not necessarily the same. The 3-D solver adds to the abstraction because the solution of the heat conduction equation has been split into three sets of 1-D solves. It is not possible to create a contour plot of the full 3-D temperature profile within the solid because there are actually 3, one for each direction. I suppose something could be done, but I worry that whatever we do might present a misleading picture.

One possible thing that can be done is to animate the 1-D profiles that are generated using the &PROF namelist group in FDS. It would be useful to click on a surface cell in Smokeview and see an animation of the evolving interior temperature or other quantities.

[Vojta-Salek]

1-D profiles sound great—it’s always a bit difficult to plot each one from a separate file.

I was, for instance, considering the possibility of loading LAYER_DIVIDE as a boundary. When dealing with multiple attached objects (sometimes even multi-layered), it can become challenging to imagine the LAYER_DIVIDE value at the outer surfaces. One potential extension could be a boundary that multiplies LAYER_DIVIDE by the actual thickness to display the effective thickness 'connected' to the surface over time.

Another idea could involve displaying arrows that connect the inner parts of a solid to the surface, similar to how HVAC connections are displayed. Here, unfortunately, I have no idea how to include the fact that we can have multiple layers inside a solid.

I hope I’m not bothering you with these ideas. I’m just brainstorming out loud here, fully aware that the benefits of these ideas might not justify the effort needed to implement them.

[mcgratta]

Creating a &BNDF QUANTITY would be easy. I'll look into that.