firemodels / fds

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

DNS combustion does not burn #1297

Closed gforney closed 9 years ago

gforney commented 9 years ago
Jason, this simplified version of Cup-burner is using lumped species but DNS but it
does not burn.

The flame does not spread to the edge of the burner as it should.

If I set AUTO_IGNITION_TEMPERATURE = 540. on ohe REAC line, the flame dies when the
ignitor is removed. 

This used to burn OK before the species overhaul.

Original issue reported on code.google.com by shostikk on 2011-02-04 15:22:26


gforney commented 9 years ago
I'll take a look.

Original issue reported on code.google.com by drjfloyd on 2011-02-04 15:38:30

gforney commented 9 years ago
When making the species changes, based on discussions with Randy I set the mixing time
for DNS to TAU_D where previously it was DT.  This is the reason for the change as
the mixing time is going from ~0.001 s to ~ 0.06 s at the edge of the burner.  If I
change it back to DT, then the flame quickly establishes itself at the edge of the
burner.

Randy, what should we be doing for DNS mixing time?

Original issue reported on code.google.com by drjfloyd on 2011-02-04 16:10:05

gforney commented 9 years ago
The point behind this was to try to get a convergent scheme.  So that if LES was refined
to the point where MU_TURB became zero, we would recover a DNS.  But we have other
inconsistencies the MU and DIFFUSIVITY throughout the code that have not been fixed
yet.  For DNS, TAU_D should be based on D(YY,TMP), not MU/SC in my opinion.  Maybe
this would not fix the current situation.

The way we solve the species transport equation is to first transport (advective +
diffusive transport from cell to cell).  At this point in time we have species in the
cells that have been moved from cell to cell, but not mixed.  We then solve dY_F/dt
= Y_F/TAU_MIX.  This ODE is integrated from 0 to DT.  If we use DT for TAU_MIX, you
are condemning DYF to be

DYF = Y_LIMITER*(1-EXP(-1)) = .63*Y_LIMITER

I don't like this as a combustion model.

For the sake of getting papers out, it might be better to use the old version for which
the extinction model was originally developed.  These models clearly interact strongly
with each other and cannot be considered separately.

What we use for TAU_MIX is a model and it apparently interacts strongly with the extinction
model.

Original issue reported on code.google.com by randy.mcdermott on 2011-02-04 16:38:15

gforney commented 9 years ago
I agree that DT is not the right way to go.  And clearly SC RHO / MU isn't quite right
either.  I'll test with the actual DNS diffusivity. 

Original issue reported on code.google.com by drjfloyd on 2011-02-04 16:49:41

gforney commented 9 years ago
Tried adding a call to get_diffusivity.  A little better than the SC RHO / MU but not
by much.  

Diffusivity of methane into air is ~0.2 cm^2/s or 2E-5 m^2/s.  With delta=0.001 m,
we get TAU_D ~ 0.05. With a DNS timestep of 0.001 - 0.0001 s we would burn only a couple
of percent of the fuel in a time step.  

Original issue reported on code.google.com by drjfloyd on 2011-02-04 17:02:29

gforney commented 9 years ago
I thought about this a little the last time someone brought up the extinction submodel.
Another way to define the timescale is by the Strain rate tensor S_ij. The strain rate
magnitude is (S_ij:S_ij)^0.5 (or |S| depending on your notation style) in units of
1/s. Therefore a reasonable timescale is (S_ij:S_ij)^-0.5, which could be much smaller
than the diffusive timescale. I'm not sure about the implementation in the code, but
it is an alternative that should be a valid timescale for mixing. 

Original issue reported on code.google.com by williamson.justin.wade on 2011-02-07 14:59:43

gforney commented 9 years ago
Justin,

TAU_D = SC*RHO*DELTA^2/MU = SC*DELTA^2/NU_TURB = SC*DELTA^2/((CS*DELTA)^2*|S|) = SC/(CS^2*|S|)

So, you see, the diffusive time scale is inversely related to |S|.

R

Original issue reported on code.google.com by randy.mcdermott on 2011-02-07 15:06:00

gforney commented 9 years ago
Yes, I agree that is true for LES. But for DNS, the relationship is broken because the
Smagorinsky model no longer applies. 

Original issue reported on code.google.com by williamson.justin.wade on 2011-02-07 16:18:07

gforney commented 9 years ago
Why do you think the strain rate is a good time scale for mixing in DNS?  Suppose |S|=0,
but you have still have grad Y.  You should get mixing and reaction.  This is why we
want to converge to TAU_DIFF = DELTA**2/DIFFUSIVITY, which is more or less the definition
of the mixing time scale.

Original issue reported on code.google.com by randy.mcdermott on 2011-02-07 16:42:05

gforney commented 9 years ago
I see your point that |S| is not always valid in DNS. Your point about grad Y just reminded
me of the scalar dissipation rate:
chi_Y = 2*DIFFUSIVITY*|grad Y|**2
and the scalar dissipation timescale is approximately:
1/chi_Y

This is very similar to your original expression TAU_DIFF = DELTA**2/DIFFUSIVITY but
includes the effects of nonzero scalar gradients. The problem is 1/chi_Y >= TAU_DIFF,
so it won't improve the situation. 

Sorry to derail the discussion, I just like the topic.

Original issue reported on code.google.com by williamson.justin.wade on 2011-02-07 17:38:03

gforney commented 9 years ago
No problem.  If you have good ideas, we are always eager to hear them.  I did play with
using the scalar dissipation rate at one point, but did not find it solved all our
problems (at the time).

Original issue reported on code.google.com by randy.mcdermott on 2011-02-07 17:48:54

gforney commented 9 years ago
Randy,

Right now for DNS we have MIXING_TIME = TAU_D 

Shouldn't there still be some form of TAU_U for DNS?  If I have two quiescent fluids
then sure mixing is solely diffusive, but if I were to have two opposing jets of fluid,
then mixing is going to be driven by advection over diffusion.

Original issue reported on code.google.com by drjfloyd on 2011-02-08 19:25:04

gforney commented 9 years ago
In a DNS, you are basically defining the mixing process to be TAU_D.  You need to be
resolving things to the point where this is true, else shouldn't call it DNS.  All
the chaotic stirring, that I suppose you getting at with your opposed jet example,
should be resolved on the grid.

Original issue reported on code.google.com by randy.mcdermott on 2011-02-08 19:38:34

gforney commented 9 years ago
I guess that is more my question. If in DNS we have resolved all the chaotic stirring
(in some sense saying the fluid in the cell is 100 % mixed) why then are we limiting
the rate of combustion to the very slow time scale of molecular diffusion? 

Original issue reported on code.google.com by drjfloyd on 2011-02-08 19:52:48

gforney commented 9 years ago
I disagree with the idea that the fluid in the cell is 100% mixed. I think you are confusing
diffusive transport with molecular mixing.  The diffusion term in the scalar equations
moves stuff from cell to cell.  Rightly or wrongly (I am arguing it is right), our
scheme is time split so that we first transport, then we mix.  If anything mixes (at
the molecular level), it also reacts.  The splitting is the problem.  Like the CO problem
we looked at before, the equations for transport and reaction are coupled.  The real
solution has simultaneous transport and mixing (reaction) going on.  So, our numerics
is at issue here.  Our splitting scheme is first order, even though our transport scheme
is second order.  I can be persuaded to use the 100% mixed approach.  We just need
to think about how to do this in LES mode as well so that we converge.

I am trying to find this article, which might help, I recall Pat McMurtry just used
F+O2=>P.  But NIST in its wisdom does not have an online subscription to AIAA (apparently).

McMurtry, P.A., Jou, W.-H., Riley, J.J. and Metcalfe, R.W. “Direct Numerical Simulations
of a Reacting Mixing Layer with Chemical Heat Release,” AIAA Journal, 24, pp. 962–970,
1986

Original issue reported on code.google.com by randy.mcdermott on 2011-02-08 20:40:23

gforney commented 9 years ago
The only possible limiting factor would be a chemical time scale, but invoking that
would mean invoking a finite-rate combustion model. With infinitely fast chemistry,
DT sounds actually quite right, provided we are doing proper DNS.

Original issue reported on code.google.com by jukka.vaari@vtt.fi on 2011-02-08 20:58:14

gforney commented 9 years ago
I see Randy's point on this. In order for the simulation to be a true DNS, TAU_DIFF
<= DT or the rate of molecular diffusion is fast enough to mix the components of a
grid cell within the numerical time step. If you don't meet that criteria, you are
not performing a true DNS, and you need some subgrid mixing model to compensate. You
might be able to achieve true DNS for the case if you reduce the grid size in the cup
burner from 1mm to 0.1mm (though the time step will also reduce due to CFL limits,
so I'm not sure if it is ever feasible to achieve this diffusion time constraint).

Looking back at the TAU_DIFF = DELTA**2/DIFFUSIVITY expression, this is a characteristic
scalar dissipation rate assuming |grad Y| = (0.5)**(0.5)/DELTA.

Original issue reported on code.google.com by williamson.justin.wade on 2011-02-09 14:29:37

gforney commented 9 years ago
Well with 0.2 mm grid the flame establishes itself at the cup edge in 0.03 s.

Original issue reported on code.google.com by jukka.vaari@vtt.fi on 2011-02-09 19:33:46

gforney commented 9 years ago
Ran the Smyth slot burner cases over the weekend in 2D at 0.25 mm resolution.  The 1-step
is very close to before when we set MIX_TIME=DT, but the 2-step (CO_PRODUCTION=.TRUE.)
is off quite a bit (maybe be some error in coding for the new species stuff).  

Original issue reported on code.google.com by drjfloyd on 2011-02-14 14:09:12

gforney commented 9 years ago
Randy,  been a while since either of us have commented on this issue.  Does it need
to stay open?

Original issue reported on code.google.com by drjfloyd on 2012-05-18 18:51:31

gforney commented 9 years ago
Jason,

I am going to have Craig set this case up with his CO model.

R

Original issue reported on code.google.com by randy.mcdermott on 2012-05-21 14:16:32

gforney commented 9 years ago
Looking at the latest validation results these cases appear to be working OK now.  I
am closing this as verified.

Original issue reported on code.google.com by drjfloyd on 2012-08-28 17:23:47