search

atwhaley / cfast

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

CFAST freezes with certain input values #56

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
I have found that certain (seemingly reasonable) input values will freeze the 
calculation and require a force quit. However, I have not found a pattern to 
the input that causes this freezing behavior. One such example is explained 
here and attached.

What steps will reproduce the problem?
1. 600 s run
2. Compartment dimensions of 6.1 x 4.88 x 2.44 m
3. Fire size (constant HRR) of 1640 kW
4. Door vent of 2 x 0.9 m size

This run freezes at 380 s.

Version 6.2.0 on Windows XP.

The input and .o files are attached.

Can you advise on how to further debug this?

Original issue reported on code.google.com by koverholt on 18 Aug 2010 at 6:36

Attachments:

GoogleCodeExporter commented 9 years ago 
I've been running into this problem many times a week for various setups, so 
I've been looking into this a bit more, and I compiled the debug version of 
CFAST and tried to debug it in GDB to see where it was getting stuck.

I wasn't able to see exactly where it was getting stuck in a loop, but I 
noticed that if I change the following lines (starting at line 1358) in 
initialization.f:

C*** initialzie time step checking

      ZZDTCRIT = 1.0D-09
      IZDTNUM = 0
      IZDTMAX = 100
      IZDTFLAG = .TRUE.

to ZZDTCRIT = 1.0D-08, then the time step checking (in line 781 in cfast.f) 
works and CFAST terminates properly. Otherwise, using the latest version of 
CFAST, it just hangs in the GUI and command line in an infinite loop. I checked 
all of the values in case.n.csv, and none of them are blowing up, so I am not 
sure where to look next. Any suggestions?

Original comment by koverholt on 24 Feb 2011 at 2:18

GoogleCodeExporter commented 9 years ago 
This is an ongoing issue with a small number of test cases in CFAST where the 
model grinds to a very small time step and sometimes never recovers.

Here's a slightly revised test case where I've made changes to the fire object. 
 It runs to completion.  The chemistry calculation, while a simple molecular 
balance, needs to have inputs consistent with the chemical equation used.  
Leaving the species inputs as zeroes and only inputting the heat release rate 
does cause problems at times as it has here.  I've also attached a simple Excel 
spreadsheet that we often use to make sure the inputs are consistent.

This should make your test case work.  We'll continue to examine the test case 
as you originally sent it to see if we can resolve the slow-down so CFAST is 
not as particular to certain solutions.

Original comment by cfastdev@gmail.com on 17 Mar 2011 at 1:44

Attachments:

GoogleCodeExporter commented 9 years ago 
We have the same problem with cfast freezing after 8.8 seconds. We tried both 
solutions offered above. Changing the minimum time step (DTCHE) and the 
molecular balance (CFAST Chemistry.xlsx). But is doesn't work, it still stops 
at 8.8 seconds. I attached the files we're working with. Hopefully this helps 
to find a solution. Maybe you can advise us how to debug this?

Original comment by lieuwede...@gmail.com on 17 May 2011 at 8:21

Attachments:

GoogleCodeExporter commented 9 years ago

Original comment by mcgra...@gmail.com on 19 Jul 2013 at 1:28

GoogleCodeExporter commented 9 years ago 
I reran this case with the latest version of CFAST (r923) and the attached 
(updated) input file. The case stops at 170 s and I get the following output:

$ cat burn_structure.log
Date stamp from CFAST initialization 2013/08/19    
The project files are based on the root: burn_structure                         

Version  6.3.0, Created 2013/06/12, Revision   923
CFAST run with validation option =  0
Opening a version  6 file in normal mode
Ceiling jet calculation has been set:  T F T F T
Compartment   1 Compartm    6.1   4.9   2.4   0.0   0.0   0.0TFTT   GYPSUM    
OFF       GYPSUM    GYPSUM  
Plume model for this fire: McCaffrey 
Object New Fire position set to   3.050  2.440  0.001; Maximum HRR per m^3 =  
1.222E+07 exceeds physical limits
Open the output file burn_structure.out
Open the smokeview files - burn_structure.smv  burn_structure.plt
Open the spreadsheet files - burn_structure_n.csv  burn_structure_f.csv  
burn_structure_s.csv  burn_structure_w.csv
100 consecutive time steps with size below 0.1000E-08 at t= 0.1738E+03

Original comment by koverholt on 19 Aug 2013 at 8:56

Attachments:

GoogleCodeExporter commented 9 years ago

Original comment by koverholt on 19 Aug 2013 at 9:16

GoogleCodeExporter commented 9 years ago 
rick any idea why HRRPUV/V3 is this high given that HRR is ~ 1.6MW and vol is ~ 
7 m3
Maximum HRR per m^3 =  1.222E+07 exceeds physical limits

Original comment by gfor...@gmail.com on 19 Aug 2013 at 9:59

GoogleCodeExporter commented 9 years ago 
The HRRPUV is based on the volume of the flame, not the room.  See line 1868 of 
input.f90. Here, it assumes a cylinder of the user specified area with a flame 
height calculated by Heskestad's correlation.  It was intended to get only the 
worst offenders.

Original comment by rpea...@gmail.com on 20 Aug 2013 at 1:27

GoogleCodeExporter commented 9 years ago 
If I change the IZDTFLAG flag to false, the model just grinds along with a time 
step about e-10.  This is clearly one that CFAST should be able to handle with 
ease since it's a one room case with an open door and a constant fire.

Original comment by rpea...@gmail.com on 20 Aug 2013 at 1:56

GoogleCodeExporter commented 9 years ago 
This test cases also works if you turn off radiation.  Glenn is working on this 
same problem for other test cases.

Original comment by rpea...@gmail.com on 20 Aug 2013 at 6:03

GoogleCodeExporter commented 9 years ago 
Failing cases work as of revision r968.  Problem was numerical instability in 
layer absorptivity routine.  Current fix is to revert to constant absorptivity 
used in (far) earlier versions of CFAST.  Validation results actually show 
better overall accuracy with the update. 

Still need to investigate what's going wrong with absorptivity routine.

Original comment by cfastdev@gmail.com on 29 Aug 2013 at 11:13

GoogleCodeExporter commented 9 years ago 
This case is now running to completion with the fix. Marking as verified.

Original comment by koverholt on 29 Aug 2013 at 1:57