Laminar flame speed: high temperature and pressures unexpected behaviour

[Leonardo Giordo]

Hello,

I'm struggling to understand why at high temperatures and pressures the results of the laminar flame speed are completely off (T=900K and p=200bar). In the image the black line is the target, and the blue contain the results from Cantera. For reference black line max values are <1 m/s while the blue curve is mainly between 1 and 2 m/s. What is puzzling for me are, of course, the high values of lfs for lambda < 1.

What can be causing this behavior?

BR,

Leonardo

[Steven DeCaluwe]

Hi Leonardo,

Can you say a bit more to help us understand your approach / problem?

1. Where does your “target” data come from?  Is this a previous calculation? An experimental measurement?

2. Can you tell us what code you are using to calculate the flame speed?

3. Similarly, what mechanism file are you using?

My initial suspicion is that you are using the ideal gas equation of state, and that the discrepancies you see are a result of the limits of that model’s validity at high pressure.  

Thanks,

Steven DeCaluwe

--
You received this message because you are subscribed to the Google Groups "Cantera Users' Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cantera-user...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/cantera-users/6ccd7c87-669e-4588-baf0-450173ceaa29n%40googlegroups.com.
<lfs.png>

[Leonardo Giordo]

Dear Steven,

unfortunately, I can't share the exact values, but the target results should be coming from experimental data.

I can share a template of the code I used for the calculation.

The reaction mechanism used is the NUIG1.1:  Mechanism Downloads - University of Galway.

Being this RM very big I had to reduce it.
I followed the approach suggested in: Mechanism reduction — Cantera 3.2.0a1 documentation.
After doing some simulation with different number of reactions I was able to get to a converged result above 1000 reaction.

With 1000 reactions the simulation time is still acceptable (from 2 to 6 minutes with 32cpus).

In this section I set the thermal model as ideal gas, is it possible that the problem is coming from here? Is it possible to select other models in the mechanism reduction?

As you can see from the code, the refinement used is pretty coarse...this was working fine at lower temperatures and pressures. I tried with a finer grid which lowered the curve by 0.5 K, but keeping the same shape.

Thank you for your assistance!

BR,

Leonardo

[Z. Weng]

Hello, Leonardo,

In addition to the potential issue due to the ideal gas model, it seems that you are using a fixed domain width (1mm) for all the simulations. The flame thickness becomes longer for fuel-lean mixtures. Is the 1mm domain enough to resolve the flame? In addition, there is also an auto-ignition issue for high-temperature flame simulation. In this case, the flame speed varies with domain size. 

Best regards,

Z. Weng 

[Leonardo Giordo]

gas2 = ct.Solution(thermo='Redlich-Kwong', kinetics='gas', species=species, reactions=reactions, transport_model='high-pressure')
I will try setting up the gas with the 'Redlich-Kwong' model and  'high-pressure' models.

[Leonardo Giordo]

Hello Weng,

isn't the width referring to the flame width? Which I thought to be automatically increased and/or decreased by the flame solver during the computation.

BR,

Leonardo

[Leonardo Giordo]

"gas2 = ct.Solution(thermo='Redlich-Kwong', kinetics='gas', species=species, reactions=reactions, transport_model='high-pressure')
I will try setting up the gas with the 'Redlich-Kwong' model and 'high-pressure' models."

Of course, this approach is not feasible with the NUIG mechanism which only has NASA7 polynomials.

I can confirm that the width is automatically adjusted by the solver if the auto option is activated. The problem is that if it doesn't find a physical solution, it keeps increasing the width and consequently the simulation time gets very long. Furthermore I can't stop the process because I have no control over what the function is doing. 

[Leonardo Giordo]

Dear Mr. Weng,

now I have the situation a bit clearer. The width as you told me was fixed. With the auto option activated, the solver automatically increases it if no solution is found. 

When the auto option is deactivated, the simulation stops (I guess when the flame width reaches the domain width).
At high temperatures, if I increase the width, the LFS value increases, this tells me that the width was not sufficient to resolve the flame.
If instead of 1mm I select 5cm I get 80m/s. Being the value so high, can I conclude that the simulation diverged?

I tried increasing the width on the solution which was matching the experimental data (at lower temperatures and pressures). With my surprise instead of having the same lfs I got much higher values. 

With the auto option active the lfs matches the values calculated with width = 1mm.

How is the width affecting the results?

BR,

Leonardo

On Tuesday, March 25, 2025 at 11:09:44 AM UTC+1 zfwe...@gmail.com wrote:

[Z. Weng]

Hello, Leonardo,

Thank you for your information. 

I think you are right in terms of the domain width. I am sorry that I didn't realize the function of 'auto' option. 

For low initial temperature (without auto-ignition), the flame speed should be not sensitive to the domain width. For high initial temperatures, a higher mass flow rate (i.e. higher flame speed) is required at the inlet to maintain the flame inside the domain when the domain width becomes larger. You might get some ideas from this paper: https://asmedigitalcollection.asme.org/ICEF/proceedings-abstract/ICEF2013/56093/244838. 

Best regards,

Zifeng

[Steven DeCaluwe]

Hi Leo,

If my memory serves, it should be doable to use Redlich-Kwong (or Peng-Robinson) with this input, with a few caveats.

Essentially, the nasa coefficients are used to calculate ideal gas properties, and then the R-K model calculates the departure function for any properties, relative to the ideal gas.

So the nasa polynomials are still used, but Cantera needs to know the an and b R-K parameters for the departure function.  There are three possible ways to provide these:

1. Explicitly provide an and b for each species, using an `equation-of-state` field in the species entry.  You would need to edit the yaml file, here. See https://github.com/Cantera/cantera/blob/main/data/nDodecane_Reitz.yaml for an example.

2. Provide the critical pressure and temperature for each species, using a `critical-parameters` field in the species entry.  You can see an example of this approach here. Again, you would want to create a copy of your input and edit those entries manually.

3. The third option is that we have a database of critical properties for a set number of species.  If you specify the R-K phase model but do not provide the required species parameters, Cantera attempts to find the species in our database.  You can see the database here.

Note that you can mix and match all three approaches.  Obviously the easiest is option 3, but for a large mechanism like NUIG, I would guess the odds are low that the database has everything you need.

Cheers,

Steven

--
You received this message because you are subscribed to the Google Groups "Cantera Users' Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cantera-user...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/cantera-users/3994e4f2-5c15-48a5-a367-15be79f6497dn%40googlegroups.com.

[Leonardo Giordo]

Hello, I wanted to update you on my recent discoveries.

The main issue was that the width which I was using, at high temperatures, was not small enough. Decreasing the value to 0.3 mm made it work.
This is what I think is happening and what I should focus on:
Giving that:

• The flame thickness in general decreases with temperature
• At high temperatures the domain’s width influences the laminar flame speed

It is necessary to keep the initial domain very small otherwise the solver will capture the "bad" influence of the domain's width.

My logic is ... if it is too small the solver fails.

  
But this means that for low temperatures the solver will not be able to solve the flame.
So, due to the fact that my end goal is the creation of a table with the LFS function of T, P, phi and EGR, it is necessary to implement a logic that increases the width when the simulation fails at low temperatures Error: Time integration failed. Minimum timestep (1e-16) reached.

I will try with 2 approaches:

1. Auto option on with callback control on speeds --> if speed is unphysical stops the sim
   I don't like the auto option because it will also try switching on the energy equation and all other things that slow down the sim
2. Width increase
   Try: --> While: width < threshold_width: --> flame.solve()
   Except: --> width *= 10 
   

Are there any issues with my though process that can make the results unphysical?
My main assumption is that the smallest width at which Cantera is able to find a solution, will give as an output the correct flame speed, because it is the smallest width which is able to capture the flame thickness without influencing the laminar flame speed.

Thank you so much for your help. 

BR, 

Leonardo