Resource drain/multi-step combustion

[gforney]

Please complete the following lines...

FDS Version: 6.0 beta
SVN Revision Number: 15882
Compile Date: 5/21/13
Smokeview Version/Revision:
Operating System: Win 7 64 bit

Describe details of the issue below:

Attached is a run I am working on.  I have a couple of observations and issues:

1.  Utilizing particles for radiative heat flux (in FDS 5 was Radiative heat flux gas)
is quite costly in terms of memory.  This run is grabbing about 3 gigs RAM, but with
the radiative flux particles, the memory grab jumps to 11 gigs.  Doesn't do much in
terms of CPU time/step, but big memory grab.

2.  This is a model I upgraded from FDS 5.  I made essentially no changes to it except
making changes to inputs to comply with FDS 6 terminology.  So no more CO_PRODUCTION=.TRUE.,
no RADIATIVE HEAT FLUX GAS etc.  This model was taking about 15s cpu/step in FDS 5.
 Even without the particles, and even if I remove the secondary reactions, it is taking
about 45-50s cpu/step.  Might be because I am still tracking the species independently
and not lumped?  Don't I need to, now, though, because of the construct of doing underventilated
combustion.

3.  The HRR is fine.  I thought it was low, but checked, that was just simple user
error.  But all of the heat release is from the first reaction.  

4.  With the secondary reactions, whether infinitely fast or with finite-rates incorporated,
do not seem to be converting CO to CO2.  Might be because primary reaction is infinitely
fast?  Since I don't currently have good finite rate variables for wood, my goal is
to burn the wood at a prescribed HRR and have it burn well-ventilated until oxygen
drops, and then have it form more CO.  Similar functionality to CO_PRODUCTION=.TRUE.
in FDS 5.  Thoughts?

I know thats a lot.  I figured it was better to do it via the Issue Tracker than the
Discussion board.  Let me know what you think and what changes you suggest.

And I know answering all these questions/requests can become cumbersome when moving
towards a major release.  I want you all to know I certainly appreciate it.

Original issue reported on code.google.com by Stephen.Olenick on 2013-05-24 14:33:50

[gforney]

I'll take a look at the memory usage. Might be a leak, or allocation of large unused
arrays.

Craig -- take a look at the reaction stuff. We might need a simpler case to work with.

Original issue reported on code.google.com by mcgratta on 2013-05-24 16:29:53

[gforney]

I am currently working on item 4. 

Original issue reported on code.google.com by CraigWeinschenk on 2013-05-24 16:43:12

[gforney]

Looks like the memory hog is the PART lines. Should be easy to figure out what's happening.

Original issue reported on code.google.com by mcgratta on 2013-05-24 16:50:32

[gforney]

I see a problem with your input file.  You define AIR as the background species.  This
means there is no OXYGEN or NITROGEN in the calculation (you don't give them a MASS_FRACTION_0).
 The reaction for CO->CO2 uses OXYGEN, but there is no OXYGEN (there is only AIR),
so there can't be a reaction.  You should either use all primitive species or have
that reaction also use AIR (the only way to get oxygen for CO oxidation is from AIR
so you will always have the nitrogen and other air species present).  This means you
don't have to track NITROGEN and OXYGEN as species (can add LUMPED_COMPONENT_ONLY).
 In your case since you are doing soot deposition and CO oxidation, there isn't much
benefit in defining AIR as you are really only saving one tracked species.

Original issue reported on code.google.com by drjfloyd on 2013-05-25 18:03:20

[gforney]

Fair point.  I'm out of the office for the weekend but will implement that first thing
when I am in on Tuesday.  Good sleuthing.  Thanks!

Original issue reported on code.google.com by Stephen.Olenick on 2013-05-26 00:35:17

[gforney]

So the good news is that I snuck into the office over the weekend when my wife wasn't
watching and started a new simulation.  The bad news is that the power went out yesterday
and killed it.  So it will be a bit longer before I report back.  

But Jason, I am trying your suggestion.  I will say that in the 15s or so of simulation,
though, it seems the heat release rate is still a bit lower than I am requesting via
reaction 1 and the mass flux.  Could be that the CO still isn't being converted to
CO2.  We'll see though.  The new fire-related lines:

&SPEC ID='WOOD'
    FORMULA='CH1.7O0.74N0.002' / Tewarson SFPE 4th edition Douglas Fir
&SPEC ID='OXYGEN',MASS_FRACTION_0=0.233 /   
&SPEC ID='NITROGEN',MASS_FRACTION_0=0.767 /
&SPEC ID='WATER VAPOR' /
&SPEC ID='CARBON MONOXIDE' /
&SPEC ID='CARBON DIOXIDE' / 
&SPEC ID='SOOT'
    MASS_EXTINCTION_COEFFICIENT=8700.
    AEROSOL=.TRUE. /            

&REAC ID='wood'
    FUEL='WOOD'
    HEAT_OF_COMBUSTION=16400.
    IDEAL=.TRUE.
    SPEC_ID_NU='WOOD','OXYGEN','CARBON MONOXIDE','WATER VAPOR','NITROGEN','SOOT'
    NU=-1,-0.53902,0.96804,0.85,0.001,0.03196/                  

&REAC ID='co_to_co2'
    FUEL='CARBON MONOXIDE'
    A=4e14
    E=167360
    SPEC_ID_NU='CARBON MONOXIDE','OXYGEN','CARBON DIOXIDE'
    NU=-1,-0.5,1
    SPEC_ID_N_S='OXYGEN','CARBON MONOXIDE','WATER VAPOR'
    N_S=0.25,1,0.5 /

&REAC ID='co_to_co2_reverse'
    FUEL='CARBON DIOXIDE'
    A=5e8
    E=167360
    SPEC_ID_NU='CARBON DIOXIDE','OXYGEN','CARBON MONOXIDE'
    NU=-1,0.5,1
    SPEC_ID_N_S='CARBON DIOXIDE'
    N_S=1 / 

&VENT XB=2.15,2.65,8.95,9.45,0.46642,0.46642,IOR=3,SURF_ID='Fire',COLOR='TOMATO' /
area 0.25 m2
&SURF ID='Fire',SPEC_ID(1)='WOOD',MASS_FLUX(1)=0.48780,TAU_MF=-333.0 / 

Let me know if you see anything that doesn't make sense.  Otherwise, I'll report back
soon.

Original issue reported on code.google.com by Stephen.Olenick on 2013-05-28 13:24:18

[gforney]

I figured out why the jobs are using so much memory. Each PART line that is associated
with a radiation target causes alot of arrays to be allocated to hold particle density,
temperature, etc, in each grid cell. For these kinds of particles, we do not need this
information. So I will fix. I will probably also automate the designation of the old
"GAS" radiation device to spare the user from adding the PART, SURF, and INIT lines.
These can probably be created automatically, which will help prevent the memory drain.

Original issue reported on code.google.com by mcgratta on 2013-05-28 14:05:29

[gforney]

Yeah, makes sense Kevin.  Particles have a lot of capabilities in FDS, and while using
them to do the radiation gas makes sense, many of the capabilities are wasted memory
hogs, so if you are able to do what you are suggesting, I think it might make sense.
 Once you commit a new source code, let me know.  I'd be happy to test it for you.
 Thanks.

Original issue reported on code.google.com by Stephen.Olenick on 2013-05-28 14:10:45

[gforney]

On the &MISC line, trying setting TEMPERATURE_DEPENDENT_REACTION = .TRUE. This will
calculate a local cell temperature based on the energy release in that time-step and
use that "flame temperature" to drive the kinetics. This should help in cases with
coarse resolution. You can visualize this as a slice or as a device. The quantity is
'FLAME TEMPERATURE'. I will be adding discussion to the guides this afternoon.

Original issue reported on code.google.com by CraigWeinschenk on 2013-05-28 14:23:56

[gforney]

Will do.  SVN 15882 still ok?

Original issue reported on code.google.com by Stephen.Olenick on 2013-05-28 14:32:26

[gforney]

Should be.

Original issue reported on code.google.com by CraigWeinschenk on 2013-05-28 14:33:57

[gforney]

One source of memory requirement is that we reserve space for the ILW array for each
virtual particle. I think we only use the sum over directions and bands. Instead of
104 directions, we should only reserve space for ANGLE_INCREMENT sums, and just update
the intensity sums (fluxes), like we do for OPEN boundaries.

Original issue reported on code.google.com by shostikk on 2013-05-28 20:14:32

[gforney]

Craig-its still early in the run (~22s in), but with the TEMPERATURE_DEPENDENT_REACTION=.TRUE.
on the MISC line, I am still not immediately noticing any different behavior.  The
hrr still seems slightly low (I have a meeting this morning, but will check later today
to ensure that it isn't user error again), and there is far more CO than CO2, making
me thing that, again, we are only going through the first reaction.  The REAC and SPEC
lines I am using are per comment #6 above.  I'll keep monitoring it and will fill you
in once I know more.

Original issue reported on code.google.com by Stephen.Olenick on 2013-05-29 11:25:16

[gforney]

I am in meetings all day today. Let me know how it turns out. Just curious, where are
you measuring all of the species (relative to source fire) in your simulation?

Original issue reported on code.google.com by CraigWeinschenk on 2013-05-29 12:21:38

[gforney]

I basically have slice files all over the simulation, so I was checking out CO and CO2
slices that go through a large cut of the domain, including the fire source vent.

Original issue reported on code.google.com by Stephen.Olenick on 2013-05-29 13:47:09

[gforney]

Update.  I took a look this morning.  More like ~38s now.  First, that shows how slow
it is running.  Probably due to the particles as well as tracking all the primitive
species, but obviously far slower than FDS5 with CO_PRODUCTION.  The good news is that
we have some CO2.  The only way we can have some CO2 is if we entering REAC #2.  So
that is good.  The bad news is that we have about 4000 ppm of CO and only about 10
ppm of CO2 for a 30 kW well-ventilated fire.  So the results are still unrealistic.
 The heat release rate also seems slightly low still (i.e. output is slightly higher
than expected input per REAC 1 DeltaHc, mass flux, and vent area).  I am hypothesizing
that the unrealistic results are either due to not entering REAC 2 enough (due to flame
temperature or some other issue), or REAC 3 is dominating, sending the CO2 back to
CO.  Recall, the goal is to get some type of functionality similar to FDS5 CO_PRODUCTION,
at least for me.  I'm trying to recall.  Did CO_PRODUCTION have the reversible reaction
for CO2 back to CO?  Anyway, at your convenience, any thoughts?

Original issue reported on code.google.com by Stephen.Olenick on 2013-05-30 11:30:04

[gforney]

Another update.  More like ~70s now.  It is running insanely slow now.  Maybe getting
3s a day on a pretty powerful computer, so I am not sure how much more simulation time
we are feasibly going to get.  As for results, still looks relatively the same.  Lots
of CO, not much CO2.  There does appear to be a shift occurring the production of CO.
 Perhaps the HRR is getting high enough to effect a flame temperature to complete the
conversion.  I'll let it keep going, but like I said, not sure how much more we are
going to get out of this...I reverted my model to FDS5.5 for now to get more realistic
results.  Let me know what else I can do to help.  Thanks.

Original issue reported on code.google.com by Stephen.Olenick on 2013-06-03 11:18:23

[gforney]

Stephen,

Thanks for running this case out. 

The difference between 5.5 and 6 is that in 6 the chemistry (kinetics) are de-coupled
from the numerics. In 5.5, CO_Production was a model design specifically for CO in
FDS. It was a combination of infinite-fast reactions and a finite rate reaction to
go from CO to CO2. There was no reversible step. The specifics can be found in a Fire
Safety Journal paper by Floyd and McGrattan as well as the FDS 5 Tech Guide. In 6,
the user is responsible for putting in their own reactions for anything beyond the
basic reaction. We are trying to ensure that the reactions specified on the input file
are solved efficiently and accurately. Finding the best mechanism is a challenge itself.

I have continued to work on the numerics over the last few days to fix the issue. The
combination of fast and finite rate reactions presents a unique challenge, especially
on coarse grids. In your case the grid resolution should not be an issue. Specifically,
focusing on computing a cell temperature during each step of the time integration.

If you put a CHID.stop file in the directory you are running your case (whenever you
decide to end the case), FDS should then dump the percentages of the routines. This
will let us know what is cause FDS to run so slowly. 

Also, one cause of the lower HRR could be extinction. The default critical flame temperature
for FDS is 1600 K (typical for most simple hydrocarbon fuels) and this may not be the
best for wood. Though not sure how different your HRR is compared to expected values
to see if this is the main issue. 

If you strip down and simplify your input file to just a burner (with the reactions)
and the basic devices I will run it along with the other cases I am working on to make
sure this is working before having you continue to try things.

Original issue reported on code.google.com by CraigWeinschenk on 2013-06-03 12:58:05

[gforney]

Sure.  I'll stop it today and will post percentages.  I'll also work on the simplified
input file and will post that when ready.  It might be a few days.  Had an atom bomb
of work dropped on my desk over the weekend!  Thanks for continuing to work with me
on this.

Original issue reported on code.google.com by Stephen.Olenick on 2013-06-03 13:03:14

[gforney]

No rush. I have plenty of cases that I am working with here. I would just add your wood
case to the ones I continue to run to make sure nothing is awry with using wood versus
a different initial fuel.

Original issue reported on code.google.com by CraigWeinschenk on 2013-06-03 13:05:55

[gforney]

From the stopped output file:
The last time-step info:

----------------------------------------------
       CPU/step:   112.468 s, Total CPU:    129.31 hr
       Time step:  0.00556 s, Total time:    63.51 s
       Max CFL number:  0.91E+00 at ( 34,122, 43)
       Max divergence:  0.18E+02 at ( 82,188, 13)
       Min divergence: -0.34E+01 at ( 63,190, 13)
       Max div. error:  0.81E-06 at (163,208,  4)
       No. of Lagrangian Particles:           269
       Total Heat Release Rate:             70.117 kW
       Radiation Loss to Boundaries:       -25.604 kW

       Time Step    5558   June  3, 2013  11:20:23
       Pressure Iterations:     10
       Maximum Velocity Error:  0.71E-01 on Mesh   1 at (  73 189  12)
       ----------------------------------------------
       CPU/step:   120.809 s, Total CPU:    131.26 hr
       Time step:  0.01049 s, Total time:    63.98 s
       Max CFL number:  0.89E+00 at ( 75,188, 13)
       Max divergence:  0.13E+02 at ( 54,150, 52)
       Min divergence: -0.16E+02 at ( 50,153, 52)
       Max div. error:  0.86E-06 at (163,208,  4)
       No. of Lagrangian Particles:           269
       Total Heat Release Rate:             49.638 kW
       Radiation Loss to Boundaries:       -23.852 kW

And the percentages:

 CPU Time Usage, Mesh   1

                 CPU (s)        %  
       ----------------------------
       MAIN    480557.16     100.00
       DIVG    131278.97      27.32
       MASS     33813.76       7.04
       VELO     39359.00       8.19
       PRES     64368.79      13.39
       WALL      9316.45       1.94
       DUMP     10060.07       2.09
       PART    101987.04      21.22
       RADI     20064.48       4.18
       FIRE     62271.27      12.96
       COMM         0.19       0.00
       HVAC       452.31       0.09
       SubTot  472972.32      98.42

 Time Stepping Wall Clock Time (s):   505503.689
 Total Elapsed Wall Clock Time (s):   506237.644

STOP: FDS stopped by user

I'll to the cut back simplified input file soon.  Thanks.

Original issue reported on code.google.com by Stephen.Olenick on 2013-06-03 16:09:18

[gforney]

And here is the simplified input file.  Simple square room with same fire source as
the input file we have previously been working with.  I did keep the cell size the
same though (0.05 m squares).  Everything else is cut back and simplified.

I am running it on SVN 15882 again.  I can run on a different SVN, though, if you think
it would make a difference. 

Original issue reported on code.google.com by Stephen.Olenick on 2013-06-03 16:48:33

---

• _Attachment: simplified_test.fds_

[gforney]

I will take a look with this case. I have made improvements over the weekend but not
sure how much impact they will have relative to 15882. As long as there is a green
box here: https://code.google.com/p/fds-smv/wiki/Firebot_Build_Status I would recommend
updating to the latest code.

Something to consider is:

&REAC ID='wood'
    FUEL='WOOD'
    HEAT_OF_COMBUSTION=16400.
    IDEAL=.TRUE.
    SPEC_ID_NU='WOOD','OXYGEN','CARBON MONOXIDE','WATER VAPOR','NITROGEN','SOOT'
    NU=-1,-0.53902,0.96804,0.85,0.001,0.03196/

&REAC ID = 'R2'
      FUEL = 'CARBON MONOXIDE'
      SPEC_ID_NU='CARBON MONOXIDE','OXYGEN','CARBON DIOXIDE'
      NU= -1,-0.5,1
      CRITICAL_FLAME_TEMPERATURE=1078./

&REAC ID = 'R3'
      FUEL = 'CARBON DIOXIDE'
      A = 5e8
      E = 167360
      SPEC_ID_NU= 'CARBON DIOXIDE','OXYGEN','CARBON MONOXIDE'
      SPEC_ID_N_S='CARBON DIOXIDE'
      NU= -1,0.5,1
      N_S = 1.0/

I think the issue is with the first reaction being fast. In this set, FDS will process
both forward reactions as fast. They have unique stoichiometry and extinction criteria,
so it is different than going to CO2 in one step. The reversible reaction is still
finite rate.

I am going to add some more diagnostic tools  - specifically allowing output of reaction
rates of specific reactions. This will provide insight into multi-step reactions. Then
we can see if R2 or R3 are getting called as desired.

Original issue reported on code.google.com by CraigWeinschenk on 2013-06-03 17:02:01

[gforney]

Ok.  Yeah, I thought the fact that some reactions were fast and some were finite-rate
might be an issue.  Lets see what your diagnostics show.  The problem is that while
for some hydrocarbon fuels, getting A, E, and the other constants from the literature
can be tough...

Original issue reported on code.google.com by Stephen.Olenick on 2013-06-03 17:12:03

[gforney]

I should have this implemented this afternoon or tomorrow. I will keep you updated.

Original issue reported on code.google.com by CraigWeinschenk on 2013-06-03 17:14:48

[gforney]

Ok.  I have been running the simplified case as well, exactly as attached earlier. 
My thoughts:

1.  Even without the particles (which were a memory drain), it is running very slow
on a powerful computer.  4 days to get 90s of simulation for a 1 room, million cell
model without a high heat release.  I haven't run it in FDS5, but I am guessing it
would complete in a day or so.

2.  We are getting some CO2.  Initially, we get little to none, but around 50s, we
start getting some.  Of course, by then, there is a ton of CO.  Also, the heat release
rate is a little low for a little while, then it catches up around 50s.  Graph attached.
 So it looks like you may be on to something with your flame temperature theory.  Initially,
not enough heat to enter into the other reactions.  Either way, the result obviously
isn't correct at this point.

Ok, I'll wait on guidance from you if you want me to check out or try something else.
 And I'll keep the test run going for now, even though its running quite slowly.

Original issue reported on code.google.com by Stephen.Olenick on 2013-06-07 14:29:19

---

• Attachment: hrr.pdf

[gforney]

What is the status of this issue?

Original issue reported on code.google.com by mcgratta on 2013-06-19 19:03:52

[gforney]

The of the remaining major time performance issues were solved by using an executable
compiled with the Intel compilers versus gnu compilers. FDS 6 is going to be more expensive
than FDS 5.5.3

As far as the CO-CO2 issues - they are dependent on the reaction scheme/mechanism used.
Finite Rate/Fast Chemistry/Mixed reaction mechanisms have an impact depending on grid/temperature
that I am working on minimizing.

Original issue reported on code.google.com by CraigWeinschenk on 2013-06-19 19:15:58

[gforney]

Kevin, on my end, I have a few models running testing the CO/CO2 reaction mechanism.
 And it does appear changing the compilers increased speed.  I'm not a coding guru,
so I'll have to look into that at some point as it appeared only some features were
causing the slow down when using the gnu compilers.  I am on travel basically this
week and the next two, so I"ll check out these models when I get back.  I'll additionally
try whatever new svn is available by then and see if you the changes you made to the
particle memory arrays clear up the resource grab.  Thanks.

Original issue reported on code.google.com by Stephen.Olenick on 2013-06-20 10:29:52

[gforney]

Craig-

Heres a graph of the hack in FDS6 vs. FDS5. Total mass of CO and CO2 a little higher
in FDS5, but we are getting closer to reality I think.  Most of this is well-ventilated,
though, as the simplified test I set up isn't really going underventilated.  Once I
have more time, I'll start a model with less ventilation so we can test the underventilated
CO production.

Original issue reported on code.google.com by Stephen.Olenick on 2013-06-21 14:46:13

---

• _Attachment: simplified_test_hack_fds5vfds6.pdf_

[gforney]

Also, to give you some metrics on the time:

FDS6 hack (svn16047 compiled by NIST) v. FDS5.5 (official release), same computer,
serial, etc:

@240s simulation time FDS6 - 184.5 hrs, FDS5 - 56.9 hrs - FDS6 3.25x slower
@240s, FDS6 - 14.571s/step, FDS5 - 5.323s/step - FDS6 2.73x slower

So the compiler change resulted in a faster result with FDS6, but still far slower
than FDS5.  Doesn't mean its the end of the world, but just good to know.

Original issue reported on code.google.com by Stephen.Olenick on 2013-06-21 14:56:59

[gforney]

Stephen,

Those results look promising. I call it a hack because there is no mechanism basis
for writing the reactions in that fashion. 

Those numbers make more sense based on our timing tests here.

Original issue reported on code.google.com by CraigWeinschenk on 2013-06-21 15:04:04

[gforney]

Shall I keep this issue open?

Original issue reported on code.google.com by mcgratta on 2013-07-03 18:05:28

[gforney]

Im on the road again this week so if you could keep it open for now, ill see where we
are when I get back.  I still need to verify the particle fix and I think Craig is
still tooling the mechs.  Thanks.

Original issue reported on code.google.com by Stephen.Olenick on 2013-07-03 18:53:28

[gforney]

Kevin, I have verified the particle resource drain that you added.  When I initially
ran a model in FDS6 with particles as the radiative heat flux target, it took 11 GB
of RAM.  The same model in FDS5 took 3.6 GB.  Your changes, allowing to go back to
non-particle radiative heat flux gas, the FDS6 model now takes around 4.7 GB.  The
jump is likely due to other changes in FDS.  The new number is far more reasonable.
 So I would say that part of this issue is verified.

I still need to evaluate the reactions and I think Craig is still fiddling with them,
so its up to you whether to keep this issue open, close it, or split it.  Thanks for
all the help.

Original issue reported on code.google.com by Stephen.Olenick on 2013-07-19 18:40:42

[gforney]

btw, I have not checked that that values coming out of the radiative heat flux gas are
proper, just that the ram is less.  I'll look into that at some point when I'm back
from my business trip next week.

Original issue reported on code.google.com by Stephen.Olenick on 2013-07-19 18:41:22

[gforney]

Thanks for looking into this.

Original issue reported on code.google.com by mcgratta on 2013-07-22 17:07:02

[gforney]

Steve -- any more news on this issue?

Original issue reported on code.google.com by mcgratta on 2013-10-10 13:27:00

[gforney]

Not really.  I think we are good on the radiant heat flux gas issue.  Your changes seemed
to have worked.  As for the combustion, I got some work arounds from Craig that seemed
to help, but he indicated that after he and Randy finish with some code cleanup, he
wants me to try to a new executable that hopefully will have addressed some of the
issues.  I've been tied up on a few projects lately and combined with the shutdown,
I just figured it wasn't high on anyone's radars right now.

Original issue reported on code.google.com by Stephen.Olenick on 2013-10-10 13:33:16

[gforney]

Thanks -- I'll turn the issue over to Craig and cc Randy. Actually, the shutdown is
giving us some time to tie up these various loose ends. 

Original issue reported on code.google.com by mcgratta on 2013-10-10 14:11:04

[gforney]

What is the status of this issue?

Original issue reported on code.google.com by mcgratta on 2014-08-08 21:35:38

[gforney]

We have the finite rate stuff running really well. It is going to be more expensive
than all fast chemistry but that is expected. If Stephen is using finite rate chemistry
in any of the FDS 6 releases without any major issue then we can probably close this.

Original issue reported on code.google.com by CraigWeinschenk on 2014-08-08 21:39:45

[gforney]

Clearing out issues?  Seems like a good activity for a Friday late afternoon :)

I am using co production (infinite first reaction, finite second) in a few fds 6.1.1
(latest release) models and I think it is working well.  Also, I am not noticing any
major drain on resources with particles.  So I recommend this get closed for now and
I'll start another issue if I notice potential problems again.

Many thanks to you guys for helping with these issues.  Hope it makes for a better
code.  Sorry I missed you at Ben T.'s presentation.  The crowd broke up pretty quickly.
  Guess everyone had to get back to work! I am going to try to get down there for more
seminars in the future and at worst, I should be at the FDS conference in September.

Thanks again.

Original issue reported on code.google.com by Stephen.Olenick on 2014-08-09 00:27:09

[gforney]

I will close this issue. If I don't see you at a seminar, then definitely at the fire
modeling conference in September. I will be giving a talk material related to this.

Original issue reported on code.google.com by CraigWeinschenk on 2014-08-11 14:22:15