Open GoogleCodeExporter opened 9 years ago
Forgot to note I used 6.3.0.1445
Original comment by drjfloyd
on 23 Feb 2015 at 6:30
Clearly a bug here. There at least two things going on. 1. We initialize the
minimum and maximum layer volumes before we account for variable
cross-sectional area which causes the odd issue with a 10 m x 10 m x 10 m
specified input.
It also looks like the calculation of layer volume which just interpolates the
calculated volume as a function of height isn't working right for the 30 m x 30
m x 30 m specified input variant.
CFAST does interpolate between the cross-sectional area data points, so I get
the full volume to be (2-0)*(200+100)/2 + (4-2)*(300+200)/2 + (6-4)*(200+300)/2
+ (10-6)*200 = 2100 m^3
Original comment by cfastdev@gmail.com
on 26 Feb 2015 at 6:45
In addition to fixing the bugs, I think additional explanation regarding the
interpolaion in the User's Guide would help.
Original comment by drjfloyd
on 26 Feb 2015 at 6:48
I agree. We'll add discussion to the guides. How do you see it being used? At
the moment, we have an inconsistent input, I think. Consider the following
simple case: 10 m x 10 m x 10 m compartment; area at the floor is 100 m^2; area
at the ceiling is 0 m^2. If you assume the structure is a pyramid, the total
volume is 333.33... m^3. If you assume the structure is an A-frame (which it
turns out is what CFAST currently assumes), the total volume is 500 m^3. There
are an infinite number of other possibilities.
I'm inclined to change the input to volume as a function of height rather than
area since that's what we're actually using in the code. Since we determine the
upper layer volume from the ODEs, we calculate the layer height by
interpolating a volume as a function of height curve calculated from the area
as a function of height inputs. The problem is that the area inputs do not map
to a single unique set of volumes.
Thoughts?
Original comment by rpea...@gmail.com
on 26 Feb 2015 at 8:25
I guess the A-frame makes sense if the use case in mind was a vaulted ceiling.
I agree that doesn't really address all the possibilities.
The scenario that started this was I had a 4 story atrium (width was close to
height so I wasn't very concerned about shaft effects) where each floor had a
slightly different area open to the atrium. I wanted to get the correct volume
for smoke filling as the layer dropped to the floor.
In this case being able to specify volumes would be perfect. I guess you would
use the compartment dx,dy,dz for estimating surface area for heat transfer and
then let the user specify i pairs of z and vol where vol = the volume between
z_i and z_i-1 (z_0 is the floor)? In this case there would be a presumption of
constant area over each interval.
Original comment by drjfloyd
on 26 Feb 2015 at 8:59
Our thinking has evolved a bit as we try different test cases in the updated
code. Here's a draft of updated documentation for the variable area inputs.
I've tried to explain how things are handled in the code in the bullets at the
end (which is the style we use throughout the user's guide). Is there more that
you would like to see explained / Is this still confusing / ... thoughts?
Original comment by rpea...@gmail.com
on 13 Mar 2015 at 3:49
Attachments:
I think that is the right level of detail. It is clear to me how CFAST
processes the inputs, the relation to the original compartment definition,and
how the areas are used during a calculaiton.
Original comment by drjfloyd
on 13 Mar 2015 at 7:27
Original issue reported on code.google.com by
drjfloyd
on 23 Feb 2015 at 6:12Attachments: