FDS+Evac: Fire/Radiation effect
Theo D
First, thanks for the great software and time to help out everyone
here.
It is truely a great piece of work.
I was wondering if the current version of FDS+Evac uses the gas
temperature in the route decissions ?
From the technical reference I have not found this and from initial
tests it showed that this was not the case.
Or is this added in the calculation of force on the agent?
I thought about it as from the example from the website
(evac_example1a.fds) I found it strange that much agents are queueing
next to the fire source while waiting to get out.
Is there a way to avoid this behavior and/or is it an additional task
for future development ?
With regards,
Theodoro
TimoK
The current version of FDS+Evac does not use temperature
nor radiation. Just soot and CO, CO2, O2 (CO, CO2, O2
for the FED related stuff).
The "away from hot" or/and "away from radiation" is on
my to do list. First thing is to add this to the door
selection. Well, might be that this does not add too
much for the soot (visibility) related door selection,
but is quite easy to implement.
Second thing is to add "force" away from temp and rad.
But this is not so easy, needs lot's of playing around.
This means how strong force?
For now, you should give the "known doors" clever enough
for the room of fire origin, so that the agents are not
going towards the fire. Note, that you have keywords
TIME_OPEN, TIME_CLOSE on the EXIT/DOOR namelists. These
you can use to take the doors too close to the fire
away from the calculation: DO first a fire+evacuation
calculation (with agents or not, does not matter) to
get CHID_evac.fed (smoke, gas, etc data) for evacuation.
Then change TIME_OPEN/TIME_CLOSE as you like, see the
fire in Smokeview to get some "nice times". Then
do just evacuation calculation (and read in CHID_evac.fed).
Evacuation + read in CHID_evac.fed is equivalent to
fire+evacuation calculation. The fire ==> evacuation
information is always transfered via the CHID_evac.fed
file, even if there are both fire and evacuation meshes
at the same time.
WBR,
Timo
Kevin
the code). This is a scalar quantity that would be a good measure of
what a person would actually experience if a hot object were nearby.
Simo can tell you more.
dr_jfloyd
Gregor
> Could also make use of the logic for the RADIATIVE_FLUX_GAS DEVC
Do you mean RADIATIVE_HEAT_FLUX_GAS?
Gregor
shostikk
it contains no information on the "direction" of the radiation. From
the route selection perspective, a strongly unisotropic radiation
should have a "guiding" effect on the person. It would define the
meaning of "away".
S
TimoK
I have been saving (but not using anywhere):
! Rad flux, (no -sigma*Tamb^4 term)
rad_flux = MAX(MESHES(nom)%UII(I,J,K)/4.0_EB,SIGMA*TMPA4)
For the door selection the UII should be enough. If a door is
visible, I calculate the visibility (integrate over the
line-of-sight path). At the same time, I could check UII at
along the line-of-sight to see, e.g., what is the max value.
And if the max value is too large, then the agent might consider
some other door. For the non-visible doors, I should try somehow
to compute the gradient to see, if UII is increasing towards the
non-visible door direction or decreasing. The problem is how
to define the direction towards a non-visible door. Well, I
can use the door flow fields to follow towards the door, but
this might take some CPU time and it needs a little bit more
than two lines of code. Yes, I know, I need to do the same
stuff for soot/visibility for the non-visible doors. Now
I just do a really simple approximation, I use the soot
at the position of the agent.
TimoK
Theo D
Thanks for the quick reply and the effort to adjust it.
For now I will use the door known selection in time after the fire
simulation.
By the time it is implemented I will test/use the new approach.
Just a thought, when the movement of the agent is known, then the
"facing direction" is known as well right ?
With an agent always walking face forward isn't there a way to
implement that the radiation change (delta rad_flux) should not be
larger than a certain kW/m^2 ?
If it the threshold is encountered the direction should change or
something ?
Not sure how to calculate/experiment that threshold though, although
increasing rad_flux would never be "nice".
Just spilling some thoughts as I don't know how to calculate such a
force/threshold, let alone program it.
Good luck with it ;)
Theo D
TimoK
There are many ways of doing "away from fire". Some
combination of these would probably be the best.
* Door selection: Select doors, which are in good
direction, i.e., not too close to hot or too much
smoke places. Check that (line-of-sight doors):
smoke, rad.int. along the line and something
similar for doors around some bends (see, if
the gradient is "uphill" of "downhill" along
the initial direction to the door (from the
agent's position to the first bend).
* Door selection: Check if there is fire too close
to some door: temp,rad.int.,etc: One can take this
out from the door selection (for the visible doors
only. Non-visible doors you don't know the conditions
at the door). Well, this may be included above, but might
be nice to take some doors away explicitely, depends,
how I'll program the door selection.
* Record rad.int., temp, at grid cells. Make some kind of
force so that the agents go around hot places. Two
different ways of doing this: 1) some kind of pair
potential type force, 2) change the direction of the
v0 vector. The second one might be better one. It is
used for the counterflow stuff and seems to work there
nicely.
TimoK