firemodels / fds

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

HRR in output CHID_hrr.csv #965

Closed gforney closed 9 years ago

gforney commented 9 years ago
Please complete the following lines...

Application Version: 5.4.1
SVN Revision Number: 4697
Compile Date: Thu, 10 Sep 2009
Operating System: Windows XP Version 2002, SP3

Describe details of the issue below:

Hi, 
in the attached simulation I placed a burner on a cube made of FOAM. My 
goal is having the burner as ignition to let the cube totally burn away. 
At the end, when I check the output file CHID_hrr.csv (attached), I can 
integrate the BURN_RATE and get the cube mass, but when integrating the 
HRR I do not come to the expected value.
Having Heat of combustion of the material HOC_F, the cube volume V_F, and 
cube bulk density d_F, I would expect the integral of HRR in output file 
to be equal to HOC_F x V_F x d_F , but it's not the case.

I tried to enlarge the mesh domain or changing the boundaries to INERT-
ADIABATIC-OPEN but couldn't get the expected value.

My main questions are
1. Is it correct that the HRR in output file does not match with the 
expected one (more than twice as much)? If yes, how can I interpret the 
HRR value in the output file?
2. Can I consider my input file as "correct" to simulate a burning foam 
element or did I make any mistake in the input file?
3. Looking at the WALL TEMPERATURES in SMV (see attached picture), the 
OBST surface below the burner remain at ambient temperature. I tried 
placing a hot surface instead of a burner, with the same result, even 
after deactivating the hot surface or burner. How can I solve this problem?

Thanks a lot
Michele

Original issue reported on code.google.com by michele.poyry on 2010-01-18 15:34:51


gforney commented 9 years ago
I'll take a look at it.

Original issue reported on code.google.com by mcgratta on 2010-01-18 16:10:23

gforney commented 9 years ago
This is a bug. The difference in the HoC between the foam (25400 kJ/kg) and the 
default fuel (propane, 47200 kJ/kg) is not being accounted for. As a work-around, 
add a line like this:

&REAC HEAT_OF_COMBUSTION=25400. /

The burner has a cold surface by default. You can copy the SURF line you use to 
define the foam into another SURF line, but then set the IGNITION_TEMPERATURE=10 to

force the "burner" to burn at the start.

Original issue reported on code.google.com by mcgratta on 2010-01-18 21:20:22

gforney commented 9 years ago
Kevin,

Your fix seems to work, but the logic is now just opposite to the one used in
PYROLYSIS routine. The reason is, that we give a "wrong" value for the SF%MASS_FLUX
in the first place (in read.f90) by dividing the HRRPUA/by RN%HEAT_OF_COMBUSTION.

So, this works either way, but they are now different. Also, each MATL has already
a
property ML%ADJUST_BURN_RATE which could be used.

I may continue with this later, to make the different parts more consistent. I also
suggest we add one or two versions of box_burn_away to account for all the variations.

Original issue reported on code.google.com by shostikk on 2010-01-21 08:49:47

gforney commented 9 years ago
The problem in this case is that N_REACTIONS=0, which is why ML%ADJUST_BURN_RATE is

not set. I thought about changing the bounds of (1:N_REACTIONS,1:N_SPECIES) to 
include reaction "0", but worried that this might cause harm somewhere. All of our

tests like box_burn_away have involved single reaction solids, not solids where the

HRRPUA is set. The logic is opposite because in this special case, the 
ACTUAL_MASSFLUX(IW) is based on the RN%HoC, whereas in the case of a reacting solid,

the ACTUAL_MASSFLUX(IW) is based on the ML%HoC. You're right that we should have a

number of these cases.

Original issue reported on code.google.com by mcgratta on 2010-01-21 13:31:03

gforney commented 9 years ago
(No text was entered with this change)

Original issue reported on code.google.com by mcgratta on 2010-01-28 22:38:26

gforney commented 9 years ago
Could the original submitter verify that FDS 5.5.0 is now working properly. Thanks.

Original issue reported on code.google.com by mcgratta on 2010-04-20 13:37:22

gforney commented 9 years ago
I am closing this case.

Original issue reported on code.google.com by mcgratta on 2010-07-22 22:04:19