search

firemodels / fds

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

Importance of radiation path length and absorption coefficients in shear layer cases #1495

Closed gforney closed 9 years ago

gforney commented 9 years ago 
In the attached case, the background levels of water vapor and CO2 seem to absorb more
heat than one would expect. Try running the attached file with and without Y_CO2_INFTY=0
and HUMIDITY=0 on the REAC line. You will see that when there is background CO2 and
water vapor, the flow field looks different. We think that a relatively short pathlength
(1 m) is leading to an over-estimate of absorption by water vapor and CO2.

Original issue reported on code.google.com by mcgratta on 2011-11-11 20:10:05

gforney commented 9 years ago 
There is a another twist to this.  In the RADCAL manual, the RTE is given as:

-del dot q_r = 4 pi kappa_mean I - 4 pi kappa_Planck Ib

we use kappa_mean for both absorption and emission.  I did a quick hack into FDS to
use kappa_Planck for the source term.

Attached are images from a cut down version of the Arup tunnel file above you sent
(1/2 the length so the ceiling jet reaches the edge quicker).  The _h2o case is the
current radi.f90 with Y_CO2_INFTY and HUMIDITY set to 0.  The _old case is the current
radi.f90 with the default CO2 and H2O.  The no suffix case is the modified radi.f90
with the default CO2 and H2O.  All of these use the default path length of 1 m.

With the old radi and default CO2 and H2O there is non-ambient floor temperatures almost
all the way out to the edges (this is the over-estimate of absorption Kevin is referring
to).  The 0 H2O and CO2 has no non-ambient floor temperatures.  The modified version
has non-ambient floor temperature but only within a couple of fire diameters of the
fire.  

Should we be using the same kappa for both absorption and emission or since RADCAL
computes separate ones, should we be using them?

Original issue reported on code.google.com by drjfloyd on 2011-11-11 20:25:50

gforney commented 9 years ago 
Good point Jason!

However, currently, AMEAN is calculated as an effective coefficient of _emission_,
as T_{wall} is set to 0 K in the beginning of INIT_RADCAL subroutine. AMEAN is solved
from Eq. (8) of RADCAL manual, that is 

i = (sigma/pi) * [(1-exp(-AMEAN*L))*T**4 + exp(-AMEAN*L)T_{wall}**4]

It might be more correct to set T_wall to a typical fire temperature (900 C). As a
result, AMEAN would represent effective coefficient of absorbing/emitting medium. We
do this for Mie calculations with droplet already. 

What happens to your result in this case?

Original issue reported on code.google.com by shostikk on 2011-11-15 13:56:48

gforney commented 9 years ago 
_900 is using amean for both emission and absorption with Twall=900 C.  _900_ap0 is
using apo for emission and amean for absorption with Twall=900 C.  There isn't much
difference from the plots above where Twall=0 K

Original issue reported on code.google.com by drjfloyd on 2011-11-15 14:53:05

gforney commented 9 years ago 
Thanks. We could try to make your 900_ap0 the default mode of operation. This means:
a) Setting TWALL = RADTMP. (better name for input needed?)
b) Using AMEAN for absorption and AP0 for emission. Do we need more memory arrays for
this?

This is quite big a change, so validation runs would be needed.

Original issue reported on code.google.com by shostikk on 2011-11-15 15:00:48

gforney commented 9 years ago 
Right now the lookup table for kappa is dimensioned (SPECIES,Z,T,BAND).  This would
need to be increased to (SPECIES,Z,T,BAND,2).  The only additional cost in creating
the lookup table is this array as RADCAL is already computing both AP0 and AMEAN.

When performing the lookup, a good deal of the cost is getting the species mass fractions
and figuring out which T and Z to interpolate between.  There will be a small additional
cost to do two interpolations rather than one.

We will need two global arrays for KAPPA (or make KAPPA (I,J,K,2).  One for AP0 and
one for AMEAN.  If we want to output both quantities then they will need to be global
mesh arrays. If we only care about outputting one of them, then one would be a global
mesh array and the other could be a WORK.  I think we would want to be able to output
both in which case we would also need to have two QUANTITYs: ABSORPTION COEFFICIENT
and EMISSION COEFFICIENT (some other name?).

Original issue reported on code.google.com by drjfloyd on 2011-11-15 15:21:10

gforney commented 9 years ago 
well that concept doesn't seem to work well.  With no fire, the temperature drops since
there winds up being an imbalance between emission and absorption over the domain.

Original issue reported on code.google.com by drjfloyd on 2011-11-15 20:03:07

gforney commented 9 years ago 
I created some test cases to replicate some of the points from the plot in Chapter 3-10
of the SFPE handbook (transmittance of a 1400 K source as a function of humidity and
path length).  Basically did a 1D simulation of a hot wall to a cold wall through a
humid layer with a thickness of the path length.  If I set the TMPWALL in RADCAL to
1400 K and set the PATH_LENGTH I get errors in transmittance from a few percent at
10 m (1 % to 100 % humidity), a few percent at 1 % humidity from 10 m to 1000 m, and
15 % at 1000 m with 100 % humidity.  So with the correct path length and the correct
wall temperature, what we get from RADCAL put into the FDS radiation solver gives us
the correct answer.  

If I set the 10 m cases to have a 1000 m path length, then my errors at 10 m with 100
% humidity increase greatly (predict 94 % transmittance vs. 83 % in the plot).  

If I set the wall temperature to 900 K with the correct path, the errors are larger.

What does this all mean? I think it means we can't pick a set of default values that
will work for all problems.  If we pick path lengths based on grid size, we can get
near field fluxes, but not far field and vice versa.  If we pick flame temperatures
for computing absorption coefficients, then if the dominant source is a hot layer,
we might not get the correct fluxes.

Original issue reported on code.google.com by drjfloyd on 2011-11-16 20:53:05

gforney commented 9 years ago 
Yes. This is indeed the problem of doing grey gas radiation. 

In most cases, the radiative heat flux is only important at short distances from the
source, as it determines the flame spread of surface heating. Even big errors in the
far field fluxes usually have no safety relevance. They become important only when
the radiation solution gets coupled to the other conditions, such as the false floor
flows initiating this issue.

So, if we need to choose between the two, I would say we try to make (keep) the radiation
solver working on short distances and do some "trick" for the far fields.

Original issue reported on code.google.com by shostikk on 2011-11-17 08:03:16

gforney commented 9 years ago 
This issue is still unsolved. What should we do with this?

Original issue reported on code.google.com by shostikk on 2013-05-15 21:08:37

gforney commented 9 years ago 
Vivien -- could you take a look at this issue.

Original issue reported on code.google.com by mcgratta on 2013-05-16 17:09:02

gforney commented 9 years ago 
I am going to look at the problem stated by Jason and to use the stand alone Radcal
to understand the evolution of the absorption coefficient with the path-length. While
I still do not grasp all the details of the problem, I have the impression that the
problem lies in the curve of growth (i.e. function relating the transmissivity with
the pathlength) that is used to perform the computation.

Specifically, the spectral narrow band of water can be model using the Goody model,
which expresses the transmissivity as:

transmissivity = exp(-kappa*optical_pathlength/sqrt(1+kappa*optical_pathlength/(4*gamma)))

where kappa is the narrow band mean absorption coefficient, optical_path length is
basically concentration*physical length, and gamma is the narrow band average half-width
of the fine structure.

When the wide band model is used in FDS, the absorption coefficients used are the Planck
averaged ones, which are calculated from the product kappa*concentration. Hence, we
have:

transmissivity ~ exp(-kappa*optical_pathlength).

For small values of optical_pathlength, the Goody model gives:

transmissivity ~ exp(-kappa*optical_pathlength),

which is what FDS will give. However, for large value of optical_pathlength, Goody
gives:

transmissivity ~ exp(-sqrt(4*kappa*optical_pathlength*gamma)),

which will give values lower than FDS for the same optical_pathlength.
his could explain the higher prediction obtained with FDS.

These are my thoughts for now. I will get back to you in a couple of days after having
played with RadCal and FDS on this configuration.

Original issue reported on code.google.com by vlecous1 on 2013-05-17 16:14:05

gforney commented 9 years ago 
Does the above discussion deal with the possible difference between line-by-line and
narrow band calculation? I think our problem is the grey gas calculation (which the
multi-band version still is). In FDS, we use either path mean or Planck mean, smaller
of the two. See these lines in radi.f90:

                  CALL RADCAL(AMEAN,AP0,RADCAL_SPECIES(NS))
                  IF (NSB==1 .AND. PATH_LENGTH > 0.0_EB) THEN
                     RADCAL_SPECIES2KAPPA(NS,J,K,1) = MIN(AMEAN,AP0)
                  ELSE
                     RADCAL_SPECIES2KAPPA(NS,J,K,IBND) = AP0/BBF
                  ENDIF   

For large path lengths, the path mean absorption coefficient will decrease. In my opinion,
the problem is in how we integrate over spectrum, and in practice, how we define the
path length. Can we find a more intelligent definition of the path length, based on
some radiation "length scale"?

Original issue reported on code.google.com by shostikk on 2013-05-28 20:40:20

gforney commented 9 years ago 
This problem remains a challenge for grey radiation calculation. No solution is envisioned
before we upgrade the radiation calculation routine to something more elaborate that
takes into account the spectral dependencies in actual transport calculation.

I close this issue.

Original issue reported on code.google.com by shostikk on 2014-08-20 06:45:43