search

firemodels / fds

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

MLRPUA incorrect #1124

Closed gforney closed 9 years ago

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

Application Version:FDS 5.5.0
SVN Revision Number:6004
Compile Date:5 April 2010
Operating System:Windows XP 2002 service pack 3

Describe details of the issue below:

I've tested 4 different versions of specifying a fixed burning rate 
and get different results. 

My simple test case is a solid 0.1x0.5x0.1 m set within a mesh size 
0.1x0.1x0.1. The solid material has density 536 kg/m3, heat of 
combustion of 18270 kJ/kg. For a surface thickness of 0.01 m, I 
calculated the mass to be 1.1792 kg, the surface density = 5.36 kg/m2. 

I have specified a surf to all 6 surfaces, which included a THICKNESS 
of 0.01 m, SURFACE_DENSITY of 5.36 kg/m2, MLRPUA of 0.0196 kg/(m2.s), 
BURN_AWAY =.False., and calculated the burn time to be 275 sec which I've set with
a ramp for the MLRPUA. Ignition was set to burn immediately. I've integrated the mass
loss over 300 sec (the material 
only burned for 275 sec) and got total mass = 3.04 kg which is 
clearly not correct. (Version 5.4 gave the correct result). 

Specifying The HRRPUA (365.4 kW/m2) does give the correct result. (but did not do so
in version 5.4).

The attachment doe snot want to work so I've added the input file text below.

MPUA.fds
Generated by PyroSim - Version 2010.1.0928
12 Jul 2010 1:07:04 PM

&HEAD CHID='MPUA'/
&TIME T_END=300.00/
&DUMP RENDER_FILE='MPUA.ge1', DT_RESTART=300.00/
&MISC SURF_DEFAULT='OPEN'/

&MESH ID='MESH', IJK=10,10,10, XB=0.00,1.00,0.00,1.00,0.00,1.00/

&REAC ID='REAC',
      C=3.00,
      H=8.00,
      O=0.00,
      N=0.00,
      CO_YIELD=0.0110/

&MATL ID='virtual clothes',
      FYI='From Zalok - Assessment of use FDS in Performmance-based, Fire Technolgy,
2009',
      SPECIFIC_HEAT=1.42,
      CONDUCTIVITY=0.1900,
      DENSITY=536.00,
      HEAT_OF_COMBUSTION=1.8270000E004/

&SURF ID='clothes',
      FYI='Zalok',
      RGB=146,202,166,
      MLRPUA=0.0195,
      RAMP_Q='clothes_RAMP_Q',
      HEAT_OF_VAPORIZATION=1.1340000E003,
      SURFACE_DENSITY=5.36,
      BACKING='INSULATED',
      MATL_ID(1,1)='virtual clothes',
      MATL_MASS_FRACTION(1,1)=1.00,
      THICKNESS(1)=0.0100/
&RAMP ID='clothes_RAMP_Q', T=0.00, F=1.00/
&RAMP ID='clothes_RAMP_Q', T=275.00, F=1.00/
&RAMP ID='clothes_RAMP_Q', T=276.00, F=0.00/

&OBST XB=0.50,0.60,0.2000,0.70,0.2000,0.3000, SURF_ID='clothes'/ Obstruction

&VENT SURF_ID='OPEN', XB=0.00,0.00,0.00,1.00,0.00,1.00, COLOR='INVISIBLE'/ Vent Min
X for MESH
&VENT SURF_ID='OPEN', XB=1.00,1.00,0.00,1.00,0.00,1.00, COLOR='INVISIBLE'/ Vent Max
X for MESH
&VENT SURF_ID='OPEN', XB=0.00,1.00,0.00,0.00,0.00,1.00, COLOR='INVISIBLE'/ Vent Min
Y for MESH
&VENT SURF_ID='OPEN', XB=0.00,1.00,1.00,1.00,0.00,1.00, COLOR='INVISIBLE'/ Vent Max
Y for MESH
&VENT SURF_ID='OPEN', XB=0.00,1.00,0.00,1.00,0.00,0.00, COLOR='INVISIBLE'/ Vent Min
Z for MESH
&VENT SURF_ID='OPEN', XB=0.00,1.00,0.00,1.00,1.00,1.00, COLOR='INVISIBLE'/ Vent Max
Z for MESH

&TAIL /

Original issue reported on code.google.com by walther.groenewald@wspgroup.co.za on 2010-07-12 12:42:55

gforney commented 9 years ago 
I ran the case with FDS 5.5.1 and the "BURN_RATE" in the _hrr.csv file is 4.29e-3 kg/m2/s
for 275 s. This is consistent with your specified MLRPUA and SURFACE_DENSITY. Are you
sure that you integrated properly?

Original issue reported on code.google.com by mcgratta on 2010-07-12 14:53:38

gforney commented 9 years ago 
The "BURN_RATE" that I got was 0.011 kg/m2/s for 275 sec. I did get the correct 4.29e-3
kg/m2/s for 275 sec when using HRRPUA = 356 kW/m2. I've run it in 5.5.0, so I'll try
in 5.5.1.

By the why, when I used "BURNAWAY = .TRUE" and did not set a time ramp (allowing FDS
to compute the burntime) I got completely different results (I did it for both MLRPUA
and HRRPUA). Why the difference? I've attached the relevant files.

Original issue reported on code.google.com by walther.groenewald@wspgroup.co.za on 2010-07-12 21:44:08

gforney commented 9 years ago 
Yes, try FDS 5.5.1. We might have fixed a bug.

As for BURN_AWAY -- too many contradictory inputs. I would not use it in this case.

Original issue reported on code.google.com by mcgratta on 2010-07-12 22:27:38

gforney commented 9 years ago 
With 5.5.1 MLRPUA now works correct but HRRPUA not. (They have swapped around from version
5.5.0)

Original issue reported on code.google.com by walther.groenewald@wspgroup.co.za on 2010-07-13 06:48:20

gforney commented 9 years ago 
The reason is that the reported mass loss rate is the true mass loss rate of your material.
The HRRPUA is based on a surrogate HEAT_OF_COMBUSTION. In order to get the right HRR,
FDS must modify the mass loss rate so that the modified mass loss rate times the user-specified
HoC yields the right HRR. Does this make sense?

Original issue reported on code.google.com by mcgratta on 2010-07-13 12:03:50

gforney commented 9 years ago 
If I understand you correctly, the recorded mass loss rate is determined by the global
gas phase reaction, and not by the material heat of combustion. This makes sense and
correlates with the spreadsheets. But, then there is no purpose in prescribing the
material heat of reaction with either HRRPUA or MLRPUA. The reported burn rate is then
strictly the gas phase burn rate and not the material burn rate.

Also, by prescribing the MLRPUA, one is actually prescribing the gas phase burn rate
of fuel, and mass loss data from calorimeters need to be adjusted with the ratio of
material heat of combustion/gas phase reaction heat of combustion.

One should then be careful to use only HRRPUA to determine burnout time.

By the way, what happens when one specifies a burnout time, and ventilation controlled
conditions or oxygen limiting conditions are encountered? From what I've seen in other
simulations, the HRR adapts according to what can be sustained by the gas phase reaction
(as one would expect). However, by specifying the burn time with a ramp, one will then
grossly underestimate the overall burn time and conditions in the enclosure since the
timer will run out while fuel is not consumed at the original rate from which the burn
time was computed. Or is FDS smart enough to adapt the burn time accordingly?

Original issue reported on code.google.com by walther.groenewald@wspgroup.co.za on 2010-07-13 14:19:39

gforney commented 9 years ago 
FDS tracks the mass loss of the fuel and stops releasing fuel when there is none left.
It doesn't calculate a burn out time. It just tracks the mass loss.

Original issue reported on code.google.com by mcgratta on 2010-07-13 14:29:14

gforney commented 9 years ago 
Thanks for the help but it is not completely clear to me. If one specifies HRRPUA FDS
does not known when the fuel will be consumed and the material will burn indefinitely
unless one specifies the HRRPUA with a time ramp (section 8.4.6) in order to stop the
HRRPUA when burnout time (as set in the ramp)is reached. The mass of fuel released
from the solid is not calculated, but the gas phase fuel required to give the total
HRR. It is this value that is given in the output. Correct?

What happens now if the compartment goes to flashover? All the fuel will now reach
ignition temeparature and will start to burn according to the prescribed HRRPUA, but
combustion cannot sustain this?? As soon as the ignition temperature is reached the
time ramp will start...

I know this discussion is strtching the bounmadries of the issue tracker, so plaese
let me know if I must rather post my question on the forum.

Original issue reported on code.google.com by walther.groenewald@wspgroup.co.za on 2010-07-13 17:21:00

gforney commented 9 years ago 
If the solid has a THICKNESS and the MATL has DENSITY, the burning will stop when there
is no more mass to burn. The tricky part in all this is the different HoC's for the
different solids and the gas phase reaction.

Original issue reported on code.google.com by mcgratta on 2010-07-13 17:25:35

gforney commented 9 years ago 
The solid does not stop burning if a MLRPUA or HRRPUA is prescribed (section 8.4.6 in
user manual). i've tested it as well and it doe snot stop.

Original issue reported on code.google.com by walther.groenewald@wspgroup.co.za on 2010-07-14 11:00:09

gforney commented 9 years ago 
Could you post the case that shows this.

Original issue reported on code.google.com by mcgratta on 2010-07-14 12:27:00

gforney commented 9 years ago 
Attached are files showing the theoretical calculations and runs with:

1)HRRPUA set with tim ramp (burning stopped at 275 sec), obtaining the correct energy
release.See - HRRPUA.fds and associated Excel output sheet

2) HRRPUA without time ramp. solid continues to burn. See HRRPUAcontinuous.fds

Original issue reported on code.google.com by walther.groenewald@wspgroup.co.za on 2010-07-14 14:20:05

gforney commented 9 years ago 
These cases work with BURN_AWAY=.TRUE., but because of the object is solid, but the
fuel is assumed to be only 0.01 m thick, the mass will probably not be conserved. There
are too many assumptions at work here. Take a look at BULK_DENSITY and see if that
works better for you. It was designed for complicated fuels where parameters like SURFACE_DENSITY
are not appropriate.

Simo -- should we stop burning based on SURFACE_DENSITY?

Original issue reported on code.google.com by mcgratta on 2010-07-14 17:13:41

gforney commented 9 years ago 
Has this problem been resolved? Is there a way to do what you want with the current
version of FDS?

Original issue reported on code.google.com by mcgratta on 2010-08-31 13:57:34

gforney commented 9 years ago 
Ok, this was one of the things that came up during the summer holiday. Haven't done
anything yet.

Original issue reported on code.google.com by shostikk on 2010-09-01 05:35:51

gforney commented 9 years ago 
I ran the case, added BURN_AWAY = .TRUE. to the SURF line, and then further added BULK_DENSITY
on the OBST line. Everything seems to work OK.

Is the there still a problem?

Original issue reported on code.google.com by shostikk on 2010-09-01 11:04:57

gforney commented 9 years ago 
I don't think so. BULK_DENSITY is the best way to treat total mass in cases like this.
Thanks.

Original issue reported on code.google.com by mcgratta on 2010-09-01 12:16:11

gforney commented 9 years ago 
I believe there is still a problems.

1)The energy content of the fuel, density, surface density and HRRPUA are as in the
input file in comment 12. For HRRPUA = 356.4 kW/m2, HOC = 18270kJ/mg the mass loss
rate should be 4.29e-3 kg/s. FDS however reports the gas phase mass loss rate of 1.67e-3
kg/s in the output file, e.g. based on the global reaction C3H8 HOC of approx. 46360
kJ/kg. Isn't the intent to write out the solid burn rate?

2)The total energy for the fuel is 21.5 MJ. Using SURFACE_DENSITY and BURNAWAY=.TRUE.
the energy that is consumed before the fuel burns away is only 12.4 MJ.This indicates
that burnaway does not work correctly. See attached excel workbook and fds file.

3)If I add BULK_DENSITY to the object in conjunction with SURFACE_DENSITY the fuel
does not burn away (although BURN_AWAY=.TRUE.) and continues to burn indefinitely.
See 3rd attachment below. Removing SURFACE_DENSITY and keeping only BULK_DENSITY does
not cause burnaway either.

To summarize: I belive there are 2 problems:
(1) the reported burn rate is the gas phase mass loss rtae based on the HOC of the
global reaction and not the solid mass loss rate based on the solid's HOC.
(2) burnaway does not work correctly as the energy balance is not correct.

Original issue reported on code.google.com by walther.groenewald@wspgroup.co.za on 2010-09-01 20:28:46

gforney commented 9 years ago 
Yes, this is still a problem. I will fix it.

Simo -- I am going to create SF%HEAT_OF_COMBUSTION internally so that in cases like
these where HRRPUA is specified, we can still use the ML%HEAT_OF_COMBUSION to compute
the "actual" burning rate.

Original issue reported on code.google.com by mcgratta on 2010-09-01 22:07:49

gforney commented 9 years ago 
OK, I see the problem.
I'm currently testing a fix for the problem (1): now the HRR and mass loss rates should
be consistent with MATL HOC. I'm running the verification tests. 

For the second problem, it depeds how you calculate the energy content.  You have calculated
E_tot = A_tot * SD * dHc_matl = (2*0.1*0.1+4*0.1*0.5) m2 *5.36 kg/m2 * 18.27  MJ/kg
= 21.5 MJ. The burning mass is then 1.18 kg. This corresponds to BULK_DENSITY of 1.18/(0.1*0.1*0.5)
= 235.84 kg/m3. Setting this to OBST line now gives the desired mass and energy losses.

Original issue reported on code.google.com by shostikk on 2010-09-02 09:25:08

gforney commented 9 years ago 
I posted a fix (svn 6689). You must wait for the next maintenance release to test.

Original issue reported on code.google.com by shostikk on 2010-09-02 09:59:40

gforney commented 9 years ago 
I also created a verification test box_burn_away4.fds.

Original issue reported on code.google.com by shostikk on 2010-09-02 10:35:18

gforney commented 9 years ago 
Simo -- thanks. I tested the case posted above and it works now. 

Walther -- please test the cases again when we release a new version of FDS. I recommend
that you use 'BULK_DENSITY' and not 'SURFACE_DENSITY' in these kinds of cases.

Original issue reported on code.google.com by mcgratta on 2010-09-02 14:46:43

gforney commented 9 years ago 
Thanks for all the work and explanation that bulk density is based on the geometrical
volume. I've tried BURN_AWAY with only BULK_DENSITY, but still don't get any burnaway.

Original issue reported on code.google.com by walther.groenewald@wspgroup.co.za on 2010-09-02 20:23:00

gforney commented 9 years ago 
Yes, because there was a bug. Simo fixed the bug, but you need to wait for the next
release.

Original issue reported on code.google.com by mcgratta on 2010-09-02 20:34:09

gforney commented 9 years ago 
Thanks Kevin and Simo. Appreciate all your efforts to improve and already awesome product.

Original issue reported on code.google.com by walther.groenewald@wspgroup.co.za on 2010-09-02 20:49:11

gforney commented 9 years ago 
Walter, the  bug was related to the case where you have set HEAT_OF_COMBUSTION on a
MATL line without pyrolysis reactions. If you remove the HEAT_OF_COMBUSTION from the
MATL - as a temporary solution, you should be able to continue your work with BURNAWAY.

Original issue reported on code.google.com by shostikk on 2010-09-03 06:15:50

gforney commented 9 years ago 
Thanks for the insight. I'll adjust the global reaction then to get the HOC that I want.

Just to make sure - You probably would have realized that the problem occurs for the
MLRPUA case as well. Specifying MLRPUA gives the correct mass loss rate in the output
file, but the HHR is then calculated via he global HOC and not the one on the material
line.

Original issue reported on code.google.com by walther.groenewald@wspgroup.co.za on 2010-09-03 07:19:52

gforney commented 9 years ago 
Yes, the bug fix should handle both. In fact, internally FDS treats HRRPUA as a MLRPUA.
The conversion is made during the read-input phase, and later all boundary conditions
are handled as mass fluxes.

Original issue reported on code.google.com by shostikk on 2010-09-03 07:38:35

gforney commented 9 years ago 
A related issue to the calculation of the mass loss rate of the fuel, is the smoke production
rate:- Am I correct to say that when specifying smoke yield ys, the smoke production
will be calculated from the mass loss rate of the global reaction (calculated from
HRR and REAC HOC). To get the correct smoke production (and optical density)when specifying
a MATL HOC , one will have to adjust the smoke yield with the ratio of (REAC HOC/MATL
HOC.

Original issue reported on code.google.com by walther.groenewald@wspgroup.co.za on 2010-09-08 08:22:25

gforney commented 9 years ago 
Yes, you are correct.

Original issue reported on code.google.com by mcgratta on 2010-09-08 14:07:29

gforney commented 9 years ago 
I've tested the latest release and note the follwing:
1)The mass loss rate reported in the output file has been corrected.
2)Using BULK_DENSITY and BURN_AWAY=.TRUE. the calculation is correct based on the premise
that the fuel mass is distributed evenly in each geometrical cell of the fuel object.
I've continued with the properties of the previous example, but changed the geometry
of the fuel to 0.2x0.2x0.5 m with grid cells of 0.1x0.1x0.1m. Using the BULK_DENSITY
the overall burn time per cell is derived by FDS by dividing the mass per cell by the
(MLRPUA x cell face area x number of exposed faces). The corner cells with 3 exposed
faces burn away first, then the adjacent cells where there are then 3 exposed faces
due to the disappearing fuel cells opening another face on adjacent cells etc. 
3)In some instances where the solid is thin (say a thin sheet of plywood) or a hollow
box, this calculation would not yield the desired result. In my example the fuel is
essentially a 10 mm thick hollow box. Actual burning would then take place only on
the initial exposed surfaces. Using BULK_DENSITY with BURN_AWAY=.TRUE. does not yield
the correct result for this case as all the faces would be consumed at the same time.
Using SURF_DENS and BURN_AWAY=.TRUE. do not yield the correct result either. I'm not
sure what is option calculates.
4)I'm not sure what the functionality of SURF_DENS is, but it would be great FDS could
compute the fuel mass from SURF_DENS x initial exposed surface. This would then yield
the correct burn time for a thin solid or hollow box.
5)It would also be great if FDS could calculate the fuel mass (and hence fuel consumption)
whenever SURF_DENS or BULK_DENSITY is defined without using BURN_AWAY=.TRUE. This would
presumably save on computational time but have the advantage that burning is automatically
stopped when the fuel is comsumed. BURN_AWAY=.TRUE. would then only be required where
the fuel is required to disappear from the flow field. I presume this opens these now
empty cells to the flow field?

Original issue reported on code.google.com by walther.groenewald@wspgroup.co.za on 2010-09-11 21:51:27

gforney commented 9 years ago 
Thanks Walter for verifying the fix.

Considering the request of new functionality, I would rather start a new Issue on that,
so that we can sign this one, which was a bug, being solved.

For feature request, could you design simple test case of what you described in words,
and tell what the result will be. You are suggesting something that may be what you
would think logical, but may appear unlogical, or too restrictive for others. Also,
it is very difficult to make things work as you describe, because we are basically
dealing with things below the spatial resolution.

Your point 5) is something you can do yourself using RAMPs.

I will close this one.

Original issue reported on code.google.com by shostikk on 2010-09-13 11:58:22