search

atwhaley / cfast

Automatically exported from code.google.com/p/cfast
0 stars 2 forks source link

Trace species may not filter correctly under all conditions. #123

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
Consider the following test case:  Two compartments connected with mechanical 
ventilation in both directions.  Insert a known mass of trace species.  After 
some period of time, the total trace mass in both rooms should equilibrate to 
1/2 the total mass added.  If HVAC duct length is set to zero, this works.  If 
duct length is non-zero, trace species concentrations and masses are nonsense.

Further, if you add a filter to one of the fan systems, the zero duct volume 
case, trace species are NOT filtered out.  Total mass of trace species does not 
change after filter is turned on.

To set up, I changed line 215 of fire.f90 to 

xntms(upper,11) = 1.0

for the first 1000 s (passed simulation time, tsec, to dofire to allow this) of 
a long (80000 s) simulation to add 1000 kg of trace to the system. Actual value 
doesn't matter ... tiny amount or large amount for trace mass added.

Original issue reported on code.google.com by rpea...@gmail.com on 5 Nov 2014 at 6:49

Attachments:

GoogleCodeExporter commented 9 years ago 
Here's the output with zero duct volume (change dl(*) to 0.0_eb at line 1043 of 
input.f to toggle volume on and off.  This impacts the calculation in 
flowfan.f90 around line 575. Important variables include the amount filtered 
(variable name filtered), tracet, traces, ...

Original comment by cfastdev@gmail.com on 5 Nov 2014 at 6:53

GoogleCodeExporter commented 9 years ago 
Here's the version of fire.f90 (as of r1647) that I modified to create the fake 
trace species in a totally closed system without a fire

Original comment by cfastdev@gmail.com on 5 Nov 2014 at 7:03

Attachments:

GoogleCodeExporter commented 9 years ago 
This also seems to impact one of the verification tests: 
fire_filter_efficieny.in in Verification/Mass_Energy_Balance.  With the duct 
volume dl(ndt) set to 1, this case doesn't fail..

This case runs in a release compile but fails with a DASSL error in a debug 
compile.  Since it's filtering, it should all be part of the same issue.

Original comment by cfastdev@gmail.com on 5 Nov 2014 at 8:48

GoogleCodeExporter commented 9 years ago 
Here's another file that acts differently when changing the duct length.  
Validation file Validation/NIST_NRC/Test_16/NIST_NRC_T16.in fails to converge 
to a solution when 1) dl(ndt) =0.0_eb (line 1043 in input.f90) and when 
compiled with the 64-bit command line build.  It works fine if either dl(ndt) = 
1.0+eb or any other compile type.

Original comment by rpea...@gmail.com on 7 Nov 2014 at 1:24

GoogleCodeExporter commented 9 years ago 
OK. Changing the leakage (r1655) fixes the problem so you don't get a failure 
with 64 bit for NIST-NRC_T16.in.  To get it to fail, change width of leak to 
10.17 m

Original comment by rpea...@gmail.com on 7 Nov 2014 at 3:54