search

firemodels / fds

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

Instability for 2D case is Y extent goes from 0 to .001 #1022

Closed gforney closed 9 years ago

gforney commented 9 years ago 
Attached case fails if y extent is set as above.

Original issue reported on code.google.com by randy.mcdermott on 2010-03-31 12:12:48

gforney commented 9 years ago 
Original file.

Original issue reported on code.google.com by randy.mcdermott on 2010-03-31 12:14:37

gforney commented 9 years ago 
The "instability" went away with the new input file, but the case does not look like
it does anything.  I will run in debug mode.

Original issue reported on code.google.com by randy.mcdermott on 2010-03-31 12:34:45

gforney commented 9 years ago 
Previous input files were incorrect.

Original issue reported on code.google.com by randy.mcdermott on 2010-03-31 13:05:11

gforney commented 9 years ago 
Previous input files were incorrect.

Original issue reported on code.google.com by randy.mcdermott on 2010-03-31 13:05:17

gforney commented 9 years ago 
This file still gives the instabilty at iteration 105, regarless of XB(3) and XB(4)
are
0,0.001 or -0.5,0.5.

Original issue reported on code.google.com by shostikk on 2010-04-01 09:41:24

gforney commented 9 years ago 
This is my fault. In the past few weeks, I have been looking closely at these 
various bounds on the HRRPUV. In FDS 5.4.3, the bound was

Q_UPPER=max(200/dx,3000)

The problem with this is that for high Q* fires (oil well blowouts, for example), 
the 200/dx was restricting the combustion to such an extent that flame heights in 
the simulations were up to twice that of the Heskestad correlation. Removing all 
bounds made the high Q* cases agree with the correlation very well. However, for low

Q* cases (like a very weak sand burner), FDS was under-predicting the flame heights

because Q_UPPER was allowing all the combustion to occur within the first grid cell.

In such cases, removing 200/dx and setting Q_UPPER=2500 kW/m3 works well over the 
whole spectrum. However (yes, lots of howevers) your DNS case cannot be bounded by

2500. Set HRRPUA_SHEET=200 on the REAC line and the case should work. The bound is

currently

Q_UPPER = HRRPUA_SHEET/dx + 2500

but HRRPUA_SHEET=0 be default. At the very least, we should restore it to 200 for 
DNS, but we have to think about LES with small grid cells.

Original issue reported on code.google.com by mcgratta on 2010-04-01 15:37:46

gforney commented 9 years ago 
This file is still giving numerical instability soon after start. Any ideas?

Original issue reported on code.google.com by shostikk on 2010-04-12 11:46:58

gforney commented 9 years ago 
In FDS 5.5, we use now put an upper bound in the HRRPUV as follows:

Q_UPPER = HRRPUA_SHEET/dx + HRRPUV_AVERAGE

For DNS, HRRPUV_AVERAGE=0, HRRPUA_SHEET=200. The idea is that in DNS you are 
resolving the flame, and thus we need this upper bound to prevent HRRPUV from going

to some huge value just at the point of ignition. For LES, HRRPUA_SHEET=0 and 
HRRPUV_AVERAGE=2500, the idea being that you are not resolving the flame but need to

limit how much energy gets released in one cell.

So remove HRRPUV_AVERAGE from the REAC line. We do not want to have the user set 
these bounds. Eventually, we'd like to get rid of them, but there are still cases 
where we need them (like yours).

Original issue reported on code.google.com by mcgratta on 2010-04-12 13:32:16

gforney commented 9 years ago 
Simo,

This seems to be running fine for me with default FDS6.  I will mark as Fixed.

R

Original issue reported on code.google.com by randy.mcdermott on 2010-04-13 19:21:12

gforney commented 9 years ago 
I haven't tried with ymin and ymax as original (0,0.001).
For (-0.5,0.5) it works fine - verified. Let's check the 0,001 case too.

Original issue reported on code.google.com by shostikk on 2010-04-13 19:25:23

gforney commented 9 years ago 
Simo,

I ran the (0,0.001) case to 2.5 seconds and all is fine.

R

Original issue reported on code.google.com by randy.mcdermott on 2010-04-13 19:55:01

gforney commented 9 years ago 
Yeah, seems to be OK. The results with (-0.5,0.5) were excellent. I will check that
(0,001) gives the same, and then we can close this.

Original issue reported on code.google.com by shostikk on 2010-04-14 06:13:19

gforney commented 9 years ago 
I assume that this case is verified. If not, open it up.

Original issue reported on code.google.com by mcgratta on 2010-07-22 22:02:37