search

firemodels / fds

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

numerical instability error #3794

Closed mrvlty closed 8 years ago

mrvlty commented 8 years ago

Hi everyone, I modelled a tunnel and set the simulation time as 200s. while it was in process it stopped suddenly and gave a numerical instability error i asked lots of people and run the simulation test cases again and again changing the different parameters of the model but nothing worked and gave the same numerical instability error again. I think the problem is engaged with the time step parameters. So, In the last simulation study i readjusted CFL number and initial time step. But this time my model gave a different error again . All the datum was attached below, Please help me to find what i should do?

Note: I know the time step size is automatically determined by the CFL condition. So there is no need to type a initial time step . Since i didn't find a solution, I wanted to try that way.

https://www.dropbox.com/s/lcf5cllpib0oqty/time.step.numerical_study_of_effect_of_b.rar?dl=0,

https://www.dropbox.com/s/zmxcfeubpbvv4b4/error.time.step.numerical.study%20of%20effect.log?dl=0

Best Regards

mcgratta commented 8 years ago

I cannot access Dropbox. It is banned by my institution. Create a simple version of the input file that fails and post it here.

mrvlty commented 8 years ago

Hi McGrattan, Here is the screenshot of the record wiev of the simulation. Thank you sir.

with time step specifacion 1 with time step specifacion 2 with time step specifacion 3

drjfloyd commented 8 years ago

We cannot run a screenshot. We would have to take the time to retype all the inputs. Please attach as a text file as Kevin requested. On Apr 20, 2016 11:22, "mrvlty" notifications@github.com wrote:

Hi McGrattan, Here is the screenshot of the record wiev of the simulation. Thank you sir.

[image: with time step specifacion 1] https://cloud.githubusercontent.com/assets/16001133/14669634/596952a0-06f2-11e6-940f-47357f8dd879.png [image: with time step specifacion 2] https://cloud.githubusercontent.com/assets/16001133/14669639/6153330a-06f2-11e6-855f-0fd5d64cab15.png [image: with time step specifacion 3] https://cloud.githubusercontent.com/assets/16001133/14669644/666d8728-06f2-11e6-8f29-9195ca890cc9.png

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/firemodels/fds-smv/issues/3794#issuecomment-212344176

mcgratta commented 8 years ago

Why do you do this:

LOCK_TIME_STEP=.TRUE.

Also, why are you adjusting CFL conditions? Doing this will surely cause instabilities.

mrvlty commented 8 years ago

Sorry sir i thought you would just look throught the text file of the simulation. (It is attached below) When I run that file, it gave" forrtl: severe (157): Program Exception - access violation" error.

with.time.step.txt

mrvlty commented 8 years ago

Mr. McGrattan

The simulation had given an error at about ramp up time so one of my teacher advised me if ı decrease the time step sizes and not to allow them to change , i can cope with the problem Therefore, I entered "LOCK_TIME_STEP=.TRUE." command and adjusted CFL conditions . However I know, I shouldn't change time step specification.

Actually I hadn't changed the time step specification in my first tests for the same case , but all of them gave numerical instability error (one of them is attached above). So I thought time step values could cause that error.

When I don't change the time step specification then how can I fix that numerical instability error or If that error is about simulator under the FDS-simulation parameters menu such as CFL, Sc,Von Noumann..., may my values for that parameters be wrong?

NOTE: In the example below the simulation stopped at about 27.44 s and gave "Numerical instability" error. 18.04.model.txt

mrvlty commented 8 years ago

I entered "LOCK_TIME_STEP=.TRUE." command and adjusted CFL conditions because ıt had given error at about ramp up time so one of my teacher advised me if ı decrease the time step sizes and restrict them, i can cope with the problem.

mcgratta commented 8 years ago

Try running this case. I added small holes along the tunnel to relieve pressure spikes. I have seen this problem before. You could run the case with a single mesh, or add some pressure relief.

&HEAD CHID='tunnel' /

&TIME T_END=200. /

&MESH ID='entrance.mesh', IJK=8,176,8, XB=-0.125,0.125,0.0,5.5,0.0,0.25/
&MESH ID='fire.region.mesh', IJK=16,64,16, XB=-0.125,0.125,5.5,6.5,0.0,0.25/
&MESH ID='exit.mesh', IJK=8,176,8, XB=-0.125,0.125,6.5,12.0,0.0,0.25/

&REAC ID='propane',
      FUEL='PROPANE',
      CO_YIELD=0.005,
      SOOT_YIELD=0.024,
      RADIATIVE_FRACTION=0.3/

&MATL ID='STEEL',
      SPECIFIC_HEAT=0.46,
      CONDUCTIVITY=45.8,
      DENSITY=7850.0,
      EMISSIVITY=0.95/

&MATL ID='concrete',
      SPECIFIC_HEAT=1.0,
      CONDUCTIVITY=0.1,
      DENSITY=500.0/

&SURF ID='fire.source',
      COLOR='RED',
      HRRPUA=2126.0,
      TAU_Q=-38.0/

&SURF ID='wall.surface',
      DEFAULT = .TRUE.
      COLOR = 'GRAY 30'
      MATL_ID(1,1)='STEEL',
      MATL_ID(2,1)='concrete',
      THICKNESS(1:2)=0.001,0.023/

&SURF ID='entrance',
      RGB=26.0,204.0,26.0,
      VEL=-0.3,
      PROFILE='ATMOSPHERIC'/

&VENT ID='burner.vent', SURF_ID='fire.source', XB=-0.04431,0.04431,5.95569,6.04431,0.0,0.0, COLOR='RED'/
&VENT ID='inlet', SURF_ID='entrance', XB=-0.125,0.125,0.0,0.0,0.0,0.25, RGB=0.0,204.0,51.0/
&VENT ID='outlet', SURF_ID='OPEN', XB=-0.125,0.125,12.0,12.0,0.0,0.25, RGB=51.0,204.0,255.0/

&VENT XB=-0.125,-0.125,0.03,0.06,0.0,0.03, SURF_ID='OPEN' /
&VENT XB=-0.125,-0.125,2.03,2.06,0.0,0.03, SURF_ID='OPEN' /
&VENT XB=-0.125,-0.125,4.03,4.06,0.0,0.03, SURF_ID='OPEN' /
&VENT XB=-0.125,-0.125,6.03,6.06,0.0,0.03, SURF_ID='OPEN' /
&VENT XB=-0.125,-0.125,8.03,8.06,0.0,0.03, SURF_ID='OPEN' /
&VENT XB=-0.125,-0.125,10.03,10.06,0.0,0.03, SURF_ID='OPEN' /

&SLCF QUANTITY='TEMPERATURE', PBX=0.0/
&SLCF QUANTITY='VELOCITY', VECTOR=.TRUE., PBX=0.0/
&SLCF QUANTITY='TEMPERATURE', PBY=6.0/
&SLCF QUANTITY='DIVERGENCE', PBX=0.0/
&SLCF QUANTITY='PRESSURE', PBX=0.0/
&SLCF QUANTITY='HRRPUV', PBX=0.0/

&TAIL /
mrvlty commented 8 years ago

thank you Mr.McGrattan, I have never thought it that way. I run the simulation hoping work smoothly İt is working now but at the begining of the simulation it gave warnings like " WARNING: Two VENTs overlap in MESH 1, Cell 0 2 1 . VENT 12 rejected for that cell". The screenshot of it as below.

warning

2016-04-20 17:31 GMT+03:00 Kevin McGrattan notifications@github.com:

Try running this case. I added small holes along the tunnel to relieve pressure spikes. I have seen this problem before. You could run the case with a single mesh, or add some pressure relief.

&HEAD CHID='tunnel' /

&TIME T_END=200. /

&MESH ID='entrance.mesh', IJK=8,176,8, XB=-0.125,0.125,0.0,5.5,0.0,0.25/ &MESH ID='fire.region.mesh', IJK=16,64,16, XB=-0.125,0.125,5.5,6.5,0.0,0.25/ &MESH ID='exit.mesh', IJK=8,176,8, XB=-0.125,0.125,6.5,12.0,0.0,0.25/

&REAC ID='propane', FUEL='PROPANE', CO_YIELD=0.005, SOOT_YIELD=0.024, RADIATIVE_FRACTION=0.3/

&MATL ID='STEEL', SPECIFIC_HEAT=0.46, CONDUCTIVITY=45.8, DENSITY=7850.0, EMISSIVITY=0.95/

&MATL ID='concrete', SPECIFIC_HEAT=1.0, CONDUCTIVITY=0.1, DENSITY=500.0/

&SURF ID='fire.source', COLOR='RED', HRRPUA=2126.0, TAU_Q=-38.0/

&SURF ID='wall.surface', DEFAULT = .TRUE. COLOR = 'GRAY 30' MATL_ID(1,1)='STEEL', MATL_ID(2,1)='concrete', THICKNESS(1:2)=0.001,0.023/

&SURF ID='entrance', RGB=26.0,204.0,26.0, VEL=-0.3, PROFILE='ATMOSPHERIC'/

&VENT ID='burner.vent', SURF_ID='fire.source', XB=-0.04431,0.04431,5.95569,6.04431,0.0,0.0, COLOR='RED'/ &VENT ID='inlet', SURF_ID='entrance', XB=-0.125,0.125,0.0,0.0,0.0,0.25, RGB=0.0,204.0,51.0/ &VENT ID='outlet', SURF_ID='OPEN', XB=-0.125,0.125,12.0,12.0,0.0,0.25, RGB=51.0,204.0,255.0/

&VENT XB=-0.125,-0.125,0.03,0.06,0.0,0.03, SURF_ID='OPEN' / &VENT XB=-0.125,-0.125,2.03,2.06,0.0,0.03, SURF_ID='OPEN' / &VENT XB=-0.125,-0.125,4.03,4.06,0.0,0.03, SURF_ID='OPEN' / &VENT XB=-0.125,-0.125,6.03,6.06,0.0,0.03, SURF_ID='OPEN' / &VENT XB=-0.125,-0.125,8.03,8.06,0.0,0.03, SURF_ID='OPEN' / &VENT XB=-0.125,-0.125,10.03,10.06,0.0,0.03, SURF_ID='OPEN' /

&SLCF QUANTITY='TEMPERATURE', PBX=0.0/ &SLCF QUANTITY='VELOCITY', VECTOR=.TRUE., PBX=0.0/ &SLCF QUANTITY='TEMPERATURE', PBY=6.0/ &SLCF QUANTITY='DIVERGENCE', PBX=0.0/ &SLCF QUANTITY='PRESSURE', PBX=0.0/ &SLCF QUANTITY='HRRPUV', PBX=0.0/

&TAIL /

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/firemodels/fds-smv/issues/3794#issuecomment-212448650

bwklein commented 8 years ago

@mrvlty These warnings are not a problem. They are telling you that you have places in the model where one vent is on top of another and which vent surface condition it is applying to the surface at that area of overlap.

@mcgratta We are working on this same case with @mrvlty in our issue tracking system. Dan and I are finding some strange behavior and are reducing the problem down to a reproducable error state. In my first passes I am seeing huge velocity spikes and pressure pulsing before bursts of HRR.

mcgratta commented 8 years ago

This is a common problem in long tunnels when one uses multiple meshes, especially of different resolutions. Unless we do an exact pressure solve for the entire tunnel, there are going to be spurious pressure and velocity spikes. Adding holes alleviates the problem.

mrvlty commented 8 years ago

Mr. McGrattan , I calculated critical velocity of this study as 0,67 , the experimental source of it demostrated the same value as well. But when I run the simulation using data which you reccommended, the results demonstrate bigger value for Vcr. May holes cause that mismatching between the critical velocity values. I attached the the velocity profile of it, could you please help me about it.

Thank you so much.

2016-04-21 18:52 GMT+03:00 Kevin McGrattan notifications@github.com:

This is a common problem in long tunnels when one uses multiple meshes, especially of different resolutions. Unless we do an exact pressure solve for the entire tunnel, there are going to be spurious pressure and velocity spikes. Adding holes alleviates the problem.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/firemodels/fds-smv/issues/3794#issuecomment-212983851

mrvlty commented 8 years ago

Thank you @bwklein , I really appreciate your advice. You and your team always help the users. Best regards.

guipesa commented 8 years ago

Hi all, We were having the same trouble in a tunnel simulation with FDS 6.4.0 reaching numerical instability due to the pressure solver. We run it with max_pressure_iterations = 5000. As we couldn't avoid the numerical instability we run the same code in FDS 6.3.2 and it ran without any problem. The maximum pressure iterations by step was 300, long far from 5000 that reached in FDS 6.4.0 giving the numerical instability. Also we tried in FDS 6.4.0 with VN_MIN = 0.4 and VN_MAX = 0.5 and the some trouble was happened. Some changes are in version 6.4 that give numerical problems. Thanks you all for the work done. Best regards, Guillem,

mcgratta commented 8 years ago

Guipesa -- post your input file and I'll look at it.

mcgratta commented 8 years ago

mrvlty -- yes, the holes will affect your results. If multiple meshes cause instabilities, use a single mesh. Or if you use multiple meshes, either reduce the size and number of holes, or decrease the VELOCITY_TOLERANCE and increase the number of pressure iterations.

guipesa commented 8 years ago

I attach the file.

Tunnel.txt

mcgratta commented 8 years ago

Try setting

&MISC BAROCLINIC=.FALSE. /

There can only be one MISC line, so if your file already has a MISC line, just add BAROCLINIC=.FALSE.

mcgratta commented 8 years ago

Also, if you set BAROCLINIC=.FALSE., you should not need to add holes.

rmcdermo commented 8 years ago

Why!? I just gave a big speech arguing against this kind of "solution". Let's understand the true cause of the instability. We have a version of the code that works. We can do a bisect.

On Tuesday, April 26, 2016, Kevin McGrattan notifications@github.com wrote:

Also, if you set BAROCLINIC=.FALSE., you should not need to add holes.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/firemodels/fds-smv/issues/3794#issuecomment-214476757

Sent from my iPhone

mrvlty commented 8 years ago

@mcgratta When I set BAROCLINIC=.FALSE., doesn't it effect the Vcr or other results. However, If it effects that parameters , how can I decrease the VELOCITY_TOLERANCE and increase the number of pressure iterations to get logical results ?

mcgratta commented 8 years ago

Unfortunately, this is the solution in this case. This case fails for all FDS 6 releases. It worked with FDS5_OPTIONS=.TRUE., of which the key was BAROCLINIC. I think the root cause is the extraction of p from rho*(H-KRES). In a long, sealed tunnel, H bounces around significantly, and there's nothing to bind H and KRES close together. We might have to iterate on the BAROCLINIC term in the momentum equation.

mcgratta commented 8 years ago

Take a look at the case I posted in Issue 3807 . It is a 2D simulation of your tunnel, and it uses only a single mesh. It becomes unstable within a few dozen time steps. Locking down the VELOCITY_TOLERANCE will have no effect in this case.

guipesa commented 8 years ago

Hi Kevin, In our case we tried in FDS 6.3.2 and it worked without instability. It is in FDS 6.4.0 when we are having numerical instability. Now I run it with baroclinic = .false. I will compare results with 6.3.2 to see if there are big differences. Thanks, Guillem,

dvswenson commented 8 years ago

I have run some additional testing of this problem using a simplified model. Changing the model to one mesh did not solve the problem.

  1. Simplified model using FDS 6.4.0 failed due to numerical instability.
  2. Simplified model using FDS 6.1.2 ran successfully to completion.
  3. Simplified model using one mesh and FDS 6.4.0 failed due to numerical instability.

I have attached the input files and a graph of HRR for the successful FDS 6.1.2 solution.

Dan Swenson redo_fds_6_1_2.fds.txt redo_fds_6_4_0.fds.txt redo_fds_6_4_0_one_mesh.fds.txt

fds_6 1 2_hrr

mcgratta commented 8 years ago

These tunnel instabilities are tricky, because they are sometimes related to errors at mesh boundaries, but not always. Sometimes a case might be (for various reasons) close to having a numerical instability, and subtle differences from one version of FDS to another might push it over the edge or keep it just within the stability range. The sealed tunnel complicates matters because pressure fluctuations caused by the fire propagate instantaneously (via the pressure solver) to the end of the tunnel or the mesh containing the fire. FDS iterates to try to match the pressure solution mesh to mesh, but sometimes that's not enough.

mrvlty commented 8 years ago

@mcgratta I hope that problem about the pressure solver can be fixed in FDS 6.4.0 as soon as possible.

@dvswenson I will download FDS 6.1.2 and ran that model using this version. I hope, i can obtain meaningfull results.When the simulation finish, I will write results here.

Thank you for your time.

mcgratta commented 8 years ago

I believe the problem is with the baroclinic torque term in the momentum equation. This is not an easy fix. I'd be interested to know if it works with 6.1.2. It might be that the instability is avoided, but that the numerical instability still affects the solution.

dvswenson commented 8 years ago

I was able to obtain a stable solution to the tunnel problem using FDS 6.4 by reducing the time step to 1E-4 seconds. I selected this value based on the FDS 6.1.2 solution, where the time step selected by FDS had a minimum of about 4E-4.

I ran the attached model until 40.2 seconds. The fire is t^2 with a ramp up time of 38 seconds, so the fire had reached the peak when I stopped the solution.

The attached image shows the calculated HRR. It is much smoother than when the time step is selected automatically. The HRRPUV plot certainly shows complex combustion patterns.

The model is attached. Of course, the solution took a long time, since the time step I specified was fixed (four days for 40 seconds).

Dan Swenson

hrr with dt 0 0001

hrrpuv dt 0 0001

redo_fds_6_4_0_dt_0001.fds.txt

dvswenson commented 8 years ago

Would it be worth considering letting the user specify a "time step reduction factor"? or at least backing off a bit from the calculated stable time step estimate?

Dan Swenson

mcgratta commented 8 years ago

As I said above, I believe this problem is caused by a mismatch in the pressure field. In the momentum equation, the pressure term is (1/rho) grad p which would lead to a pressure equation of the form

del dot (1/rho) grad p=...

But we do not have a fast solver for this inseparable form of Poisson's equation. Instead, we decompose the pressure term

(1/rho) grad p = grad (p/rho) - p grad (1/rho)

and write the pressure equation

del^2 (p/rho) = -del dot p grad (1/rho) + ...

The p on the right hand side is from the previous time step, thus, there is a mismatch in the pressure field. For most FDS calcs, the time lag in p is not a problem, but in this tunnel case it is. When you lower the time step drastically, you are alleviating the problem to some extent by making the old p and new p closer in value.

I am testing now an iterative scheme such that we iterate the "baroclinic term", p grad (1/rho), in the current pressure iteration scheme that we use to force the pressure and velocities to match at mesh boundaries.

dvswenson commented 8 years ago

Sounds good, thanks.

mcgratta commented 8 years ago

I believe that I have fixed the instability problem in tunnels. I have committed new code to the FDS repository, but we do not want to issue a new official release until the code is run through the validation cases, which takes a few weeks. In the meantime, does anyone who is monitoring this thread have the ability to compile code from the repo?

mrvlty commented 8 years ago

I am glad to solve that instability problem Mr. McGratta. I want to try it as soon as possible. Merve

mcgratta commented 8 years ago

If you can compile the code, you can try it now.

mrvlty commented 8 years ago

Ok, thank you so much. I will try it immediately .

Merve

2016-05-12 16:15 GMT+03:00 Kevin McGrattan notifications@github.com:

If you can compile the code, you can try it now.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/firemodels/fds-smv/issues/3794#issuecomment-218753270

dvswenson commented 8 years ago

This problem has now been fixed. See issue 3807.