Simulation of the NIST Parallel Panel Setup

[Tristan Hehnen]

Hello everybody!

I would like to start some discussions on the parallel panel setup and its  simulation. Our starting point has been to try to reproduce the setup with the empty panels as well as possible. Afterwards, we wanted to add in the combustible sample. Since the time to submit the data set for MaCFP-3 is running out, I've started to mix both approaches together. (Still I've got doubts to finish it in time.)

For our simulations we are using FDS 6.7.9 (FDS6.7.9-0-gec52dee-HEAD). Our basic FDS input for the parallel panel setup can be found in this git repo: https://github.com/TristanHehnen/ParallelPanelBurnerSetup

In this repository there are a couple of FDS input files and Jupyter notebooks. The input files contain a couple of variations, for example fluid cell sizes, mesh layout or simulation mode. The Jupyter notebooks are set up to take all the heat flux information from the simulations and compare them to the simulation responses. So, in principle, if you are interested, you could clone the repo, run the simulations in the respective directories and then run the notebook to create all the plots automatically.

In the beginning the general idea was, that I wanted to have few meshes. My reasoning was that I wanted to avoid potential issues in information transport across mesh boundaries, like the delay for the radiation solver. Therefore, you see quite large sub-domains in the setups linked above. Since Kevin and Randy are not convinced that this is a big issue and due to time constrains I've now shifted to smaller sub-domains. So one might very well be fine with more and smaller sub-domains. For now I also do not see a difference, other than computing time needed.

Another principle we are using here is a "reference cell", denoted by "C" and a number. This is a fluid cell, based on the edge length of a cone calorimeter sample in this case, i.e. (0.1x0.1x0.1)m^3. The number after the "C" indicates the divisions of the reference cell per axis. The dimensions of the parallel panel setup fit nicely, such that one can subdivide from the reference without FDS moving the OBST faces around by snapping them to the grid.

With this strategy we can also maintain a connection to the inverse modelling process that generates the thermophysical parameters for the sample material  (C3) and the gas phase combustion model.

In our recent article we, we had conducted a couple FDS simulations with much coarser fluid cell resolutions than suggested by the MaCFP-3 call for participation. In these simulations, we could see that the centre line heat flux seemed to be reproducible relatively well (PP_CentreLineGaugeFlux.png). However, this is not so much the case when comparing the flux over the panel surface (PP_FluxMap_01.png). One can see here, that the heat flux forms a triangular pattern in the simulation. The experiment data shows a more horizontal pattern. The black dots indicate the device locations in experiment and simulation.

With higher fluid resolution (1cm or less/C10 and up), the data gets closer to the horizontal pattern. We can observe that with smaller fluid cells (C10 and up) there are vortices forming above the burner, where the air flows around the panel edges (Vortices01.png). These vortices are trapping parts of the flame (Vortices02.png) and seem to be the primary reason why the heat flux map shows a more horizontal pattern. For example see simulation setup "Burner_09", with 0.5 cm fluid cell resolution (C20) (BurnerPanelFluxMapSimDEVC_MaCFP_Burner_09.png), here the device data is assessed to create the flux map. Comparing the boundary (BNDF) information directly, the impact of the vortex formation becomes visible (BurnerPanelFluxMapSimBNDF_MaCFP_Burner_09.png). Thus, the resolution provided by the gauge location seems to be too low to resolve this phenomenon.

In general, the heat flux to the empty panels is too high at the bottom and too low at the top of the panels. This is indicated in these difference plots (BurnerPanelFluxMapDiff_MaCFP_Burner_09.png), here the simulation response is subtracted from the experiment data, i.e. red: the experiment is larger, blue: the simulation is larger.

My first assumption has been, that the radiative heat exchange between the burner flame, as well as the empty panel and burner surfaces might be the primary reason for the difference. We're in the process of conducting some inverse modelling runs with relatively coarse fluid resolution. Goal is to adjust a few model parameters to get closer to the heat flux distribution across the panel surface. However, the optimiser consistently wants to increase the HRR of the burner (from 60 kW to 80kW) than changing the other parameters.

Given that the largest differences are at the upper parts of the panels, my assumption has changed, assuming that the convective heat transfer is the primary reason. Randy suggested, to either use smaller velocity tolerances (V_TOL) or a different pressure solver (ULMAT, GLMAT, UGLMAT) to get more accurate velocities at the OBST boundaries. I've tried now all these suggestions for a setup with sample (here comes the mixing of the strategies). Furthermore, the updates of the radiation solver were set to every frame (Upd:1) and/or the angles increased by a factor of 10 (Ang:1000). Yet, they all seem to produce essentially the same results. Kevin's strategy to set two narrow VENTs at the bottoms of the panels (Burner Split) also does not produce better results for our parameter set, see (PP_C3_HRR_SimCheck.png).
Notable difference is the case that uses a higher radiative fraction (RF) for the PMMA flame (from 0.2 to 0.3), indicating that the radiation might be more important. Thus, I guess we can abandon the idea with the convection and focus at the radiation.
I should point out that this simulation setup uses a 3.3 cm fluid cell resolution (C3), for faster iteration of the setups.

I did change the radiative fraction of the PMMA-related gas phase combustion reaction, after talking to Kevin and Randy and looking into Kevin's approach (https://github.com/firemodels/fds/blob/26430320806aacd39f74678de50942bebfbe954c/Validation/NIST_NRC_Parallel_Panels/FDS_Input_Files/PMMA_60_kW_2_cm.fds).

This is a thing that I would like to avoid however. Specifically, because we build the parameter set with the default methane definition in FDS, i.e. RF=0.20.  We used this surrogate fuel explicitly throughout the whole parameter estimation process, such that we can capture the flame heat feedback to the sample as an emergent property of the model. Thus, fiddling with these parameters in-between the estimation process and the parallel panel simulation does not seem right.

Given the long runtimes of the simulations, I do not believe there is much I can do before the submission deadline. Well, it is what it is...

Anyway, I would like to know what experiences you have with the simulation of the parallel panel setup. Does anybody have further questions or suggestions of what could be tried?

Best,

Tristan

[Jason Floyd]

You can see the files Kevin made in the FDS Git Repo in: https://github.com/firemodels/fds/tree/master/Validation/NIST_NRC_Parallel_Panels/FDS_Input_Files. He initially observed similar behavior of not getting the same flatness in the heat flux to the walls. In the current inputs, you will see is that he no longer uses the simple OPEN boundary. In FDS with an OPEN boundary, the air outside the boundary is essentially assumed as being quiescent. In the test lab this isn't the case; there are background air currents in the buildings. They are not large, but even a slight amount of air movement will break symmetry and push the fire plume around. Instead of an OPEN boundary, Kevin applied a small sinusoidal pressure boundary to represent these background air currents.

[Tristan Hehnen]

Hi Jason,

thank you very much for your reply! In the meantime I've also talked with Kevin and Randy, they also pointed me to the FDS validation case in the Git repo.

It is my understanding that the oscillating boundary condition is more a guess than representative of the actual conditions during the experiment. Yet, it seems to be pointing into a direction that is worth further investigation.
As of now, in the MaCFP Git repo there is no information reported about background air currents in the laboratory for the parallel panel experiments. This makes it a bit difficult for me to assess/capture the flame movement in the simulation.

Here is a more detailed overview over the simulation response of the heat flux from the propane burner to the empty panels. The HRR of the burner can be reproduced very well.




For all fluid cell resolutions the data recorded at the lowest centre line heat flux device is also in agreement with the experiment. For higher resolutions and device locations the heat flux is under-predicted. From the plots of the centre line heat flux it seems to me that the system has not yet reached a steady-state in the experiment.




In the flux maps it can be observed that there is higher flux at the centre line in the simulations with 2 cm and 1 cm fluid cell resolution. This changes when the cell size is reduced and the flame is trapped in the vortices at the panel edges (see previous post).




Flame movement should then even out the flux and reduce the flux at the upper parts of the panel even more.

It is worth pointing out that I'm using the simulation mode LES with default settings. Randy mentioned recently that he is simulating some of the gas burner setups from MaCFP. He needed to change the extinction model, because with default LES there were higher oxygen concentrations detected in the flame than expected. But I believe he is also using the multiple step reaction for the gas phase combustion.

Kevin is using the default VLES simulation mode.

With respect to the background air currents, it seems to be useful to also record gas velocities and flow directions around the experiment setup(s). 

If background air currents in the building affect the flame this much, I wonder how items located around the setup and distances to walls impact the flow field as well. Maybe it is necessary to use larger domains then, to take this also into account.

Best,

Tristan

--
You received this message because you are subscribed to a topic in the Google Groups "MaCFP Discussions" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/macfp-discussions/Hw6nyKv2YWo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to macfp-discussi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/macfp-discussions/55595e40-10ab-40a7-9a72-00e0d8a500c6n%40googlegroups.com.