Flame Speed Calculation - Time integration failed

1,379 views
Skip to first unread message

Simon_Thermo

unread,
Mar 12, 2016, 4:46:29 PM3/12/16
to Cantera Users' Group
Hello,

I like to calculate the flame speed with Cantera and Python. Therefore, I use the tutorial flamespeed_sensitivity.py from http://www.cantera.org/docs/sphinx/html/cython/examples/onedim_flamespeed_sensitivity.html

However, if I change the input variales, Cantera returns a error message:

..............................................................................
Attempt Newton solution of steady-state problem...    failure.
Take 2 timesteps   Traceback (most recent call last):
  File "flamespeed.py", line 34, in <module>
    f.solve(loglevel=1, refine_grid=False)
  File "cantera\onedim.pyx", line 678, in cantera._cantera.Sim1D.solve (interfac
es\cython\cantera\_cantera.cpp:68784)
Exception:
***********************************************************************
CanteraError thrown by OneDim::timeStep:
Time integration failed.
***********************************************************************

My input variables are:
p   = 100000  # pressure [Pa]
Tin = 300.0  # unburned gas temperature [K]
reactants
= 'CH4:0.45,O2:1.0'

The code works for p = 110000 and fails again for p = 120000.

It would be great if you can help me or give me a hint.

Thank you,
Simon

Nick Curtis

unread,
Mar 14, 2016, 2:18:03 PM3/14/16
to Cantera Users' Group
Simon,
The absence of N2 (or any other bath gas) in your mixture is will cause very large adiabatic flame temperatures and consequently fast flame speeds making the numerical scheme unstable.
Did you mean to leave out N2?
If so, you may try lowering the tolerances

Nick

Simon_Thermo

unread,
Mar 19, 2016, 6:03:42 PM3/19/16
to Cantera Users' Group
Hello Nick,

Thank you for your answer. I liked to simulate an oxy-fuel-combustion.

I'm not sure if the adiabatic flame temperature is the reason. The code can solve this problem with a slightly higher pressure:
p = 100kPa -> Does not work
p = 110kPA -> Works
p = 120kPA -> Does not work

The change of tolerances has not helped. Sometimes, the code solves this problem, sometimes not (as the example above).

Thank you,
Simon

Nick Curtis

unread,
Mar 21, 2016, 10:27:08 AM3/21/16
to Cantera Users' Group
Simon,
One thing you could try is to slowly change your pressure from a working solution to one of the states where it doesn't solve, e.g. start at 110 kPa, use this to initialize the solution at 109 kPa, etc.. until you get to the desired condition

Nick

Ray Speth

unread,
Mar 28, 2016, 4:07:52 PM3/28/16
to Cantera Users' Group
Simon,

I recently made a number of improvements to the 1D solver which make it much more robust. If you are able to try using the current development version of Cantera, all of the cases you described should work fine.

Regards,
Ray


On Saturday, March 19, 2016 at 6:03:42 PM UTC-4, Simon_Thermo wrote:

amadeusSharp

unread,
May 5, 2016, 5:32:59 PM5/5/16
to Cantera Users' Group
I was having issues too computing flame speed in Cantera (with multi-component diffusion), but I can get the code to work only if I initialize the flame object twice:

f = ct.FreeFlame(gas, initial_grid)
f = ct.FreeFlame(gas, initial_grid)

Here is the code that I used (with Cantera 2.2.1. Also I run python using Anaconda notebooks):

%matplotlib inline
import cantera as ct
gas = ct.Solution('/Users/XXX/chemicalMechanisms/gri30/grimech30_chem.cti')

#Gas Composition and Physical Conditions                                                                         
#gas.X = {'CH4':1.0, 'O2':2, 'N2':2*3.76}
gas.X = {'CH4':0.45, 'O2':1}
gas.TP = 300, ct.one_atm

#Numerical knobs
initial_grid = np.linspace(0.0, 0.05, 10)  # m                                   
tol_ss = [1.0e-9, 1.0e-14]  # [rtol atol] for steady-state problem                                     
tol_ts = [1.0e-5, 1.0e-14]  # [rtol atol] for time stepping                                                             
loglevel = 1  # amount of diagnostic output (0 to 8)                                                                                                                    

#Flame object                                                                                                          
f = ct.FreeFlame(gas, initial_grid)
f = ct.FreeFlame(gas, initial_grid)
##### - The above is executed twice
##### - Only then the code works, for this and other conditions
##### - For gas compositions such as phi=0.5 (methane/air), no need
##### - to include the above line twice. 

#Assign numerical knobs, etc
f.flame.set_steady_tolerances(default=tol_ss)
f.flame.set_transient_tolerances(default=tol_ts)
f.set_refine_criteria(ratio=2, slope=0.1, curve=0.1)
f.set_max_jac_age(10, 10)
f.set_time_step(1e-5, [2, 5, 10, 20, 30])

#Model details
f.energy_enabled = True
f.transport_model = 'Multi'

#Point where we start praying
f.solve(loglevel=loglevel, refine_grid=True)

#Did the prayer work
print f.u[0]*100

So for Simon_thermo's initial conditions, the last few lines output is:
..............................................................................
Attempt Newton solution of steady-state problem...    success.

Problem solved on [178] point grid(s).

..............................................................................
no new points needed in flame
318.901701685

I see the same issue if I run the file named adiabatic_flame.py substituting CH4/air mixtures for H2/O2 and changing the mechanism file...

Whether I initialize f once or twice, the output of f.show_solution() is the same. 


On Saturday, March 12, 2016 at 4:46:29 PM UTC-5, Simon_Thermo wrote:

Ray Speth

unread,
May 5, 2016, 8:20:28 PM5/5/16
to Cantera Users' Group
Hi,

This is an interesting demonstration of how sensitive the 1D solver is under certain circumstances. The difference between the two cases is that the state of the "gas" object changes ever so slightly after the first FreeFlame object is created. You can see this by taking the difference between the two states:

T0, rho0, Y0 = gas.TDY
f
= ct.FreeFlame(gas, initial_grid)
print T0 - gas.T
print rho0 - gas.density
print Y0 - gas.Y

You will see that the density and the O2 mass fraction are different by an amount on the order of the machine precision. To verify that these differences are in fact the source of the change in the flame solve, set the state of the gas back to what it was before creating the "real" FreeFlame object:

gas.TDY = T0, rho0, Y0
f
= ct.FreeFlame(gas, initial_grid)

In which case you will see the same behavior whether or not you create the first FreeFlame object.

Two other things I would note:

- You should almost always solve the mixture-averaged problem first and then switch to the multicomponent formulation. The total simulation time will be much less this way, and this also happens to eliminate the convergence failure in this instance.

- The current development version of Cantera contains a number of improvements to the 1D solver which fix many of the cases where it would fail (especially ones where the error mode is to report "Time integration failed" without ever succeeding at any timestep).

Regards,
Ray

amadeusSharp

unread,
May 5, 2016, 9:21:26 PM5/5/16
to Cantera Users' Group
Hi Ray,

Firstly, and as always, thanks ! 

Solving for the mixture averaged formulation definitely sped up the computations as you suggested. That was very helpful

I am batch-computing flame speeds for a bunch of cases. Some statistics:

If I initialize the flame object twice and do just the multi-comp simulations (without computing the mix-averaged answer first) then 6/10 cases only come out correctly. Plus the computations are slow. However, after batch-processing, if I run those four cases manually without any other intervention, I get answers for the four cases. Perhaps another instance of sensitivity to machine-precision.

However, If I compute the mix-averaged value and then the multi-comp value, I get 9/10 cases without an error. Here I initialize the flame object only once

If I do the above, and initialize the flame object twice, I get 10/10 cases with no error. 

I'll try the development version later and post an update if that improves things

Regards,
Santosh
Reply all
Reply to author
Forward
0 new messages