Freeflame under autoignitive conditions

[Rafael Meier]

Hello guys,

I am studying free flame propagation under autoignition conditions where the inlet temperature is sufficiently high that low-temperature chemistry starts to act before the flow reaches the flame front. So, the flame speed depends on the domain length.

I faced some problems to find the flame speed for constant width using "refine_grid" method. After talking with some guys that worked in this area, I figured out that I could improve the solution by starting with an initial guess profile but using a fixed mesh. However, as the domains get bigger, the simulation time grows exponentially since the mesh is quite fine.

I would like to ask if there any python script configuration to keep using "refine_grid" without loss solution quality or, if there is any modification to be done in Cantera kernel to be able to keep the optimization process of "refine_grid" running.

Thanks

Rafael

[Ray Speth]

Hi Rafael,

I'm not sure I entirely understand your question - the use of grid refinement is independent of keeping the domain length constant. The latter just requires solving without using the `auto=True` option. In addition, there is no limitation on the use of an initial mesh of your choice while still using Cantera's grid refinement algorithm. Depending on how fine your initial grid is, you might consider setting the `prune` parameter in the grid refinement to a non-zero value, to allow the algorithm to remove excess points.

If you have some idea where in the domain the flame should be, you can also use that to create an initial grid that does not have uniform spatial resolution.

If you're continuing to have problems, it might be helpful if you could provide a concrete example, including your code and relevant input files.

Regards,

Ray

[Rafael Meier]

Hello Ray,

Thank you for your answer.

Specifically, in my cases, I am working on fuels that present low-temperature chemistry, and depending on the main flame position, a double flame structure is formed. Running Cantera with refine_grid I notice that in regions of the cool flame front, the number of grid points is not sufficient to compute the flame speed correctly. My previous question means that if there's a way to increase the Cantera sensibility to refine the grid in the cool front region. 

About nonuniform spatial resolution. In some cases, I run with a nonuniform grid (I am sending attached a case that worked out) that I generated through interpolation. However, in many attempts, even with a good resolution near the flame, the Cantera solver had a convergence error. And then, I had added more points to the grid. But the simulations increaseed hugely in time.

I am sending the script that I use to generate the first guess and that to solve the problem with the initial guess as well the chemical mechanism and the initial temperature guess profile. 

Thank you

Rafael

[Ray Speth]

Hi Rafael,

This is an interesting problem. In a couple of cases I ran with grid refinement and pruning enabled, it seems as though the solver likes to prune points which affect the location of the first flame front and cause it to push up against the left boundary of the domain. Is this what you were observing?

The grid refinement criteria implemented by Cantera are designed to properly resolve the structure when diffusion is important, but I think they have trouble for this initial autoignition-like behavior demonstrated by the “cool flame”. One possibility would be to base the refinement criteria on the change relative to the local concentration in each species’ composition (perhaps with some absolute cutoff), rather than the change relative to the global change in that species across the domain. This is more akin to the tolerances applied in the zero-dimensional reactor model, which of course does a good job of resolving ignition behavior.

I think you could experiment with this or other grid refinement strategies by implementing them in Python. The idea would be to solve on a fixed grid, then compute a refined grid based on some criteria, and then solve again on the modified grid. This is basically what the existing grid refinement algorithm is doing under the hood, anyway. You can see an example where the grid and solution values are updated between successive calls to FreeFlame.solve in the example diffusion_flame_extinction.py.

Regards,
Ray

​

[Rafael Meier]

Hello Ray,

About the pruning effect, yes. I computed the flame front position for different domains width and I notice that because of the existence of the "cool front",  sometimes the entire structure is pushed to the left boundary.

Ok, I will see this script.

Thank you

Rafael

[Ingmar Schoegl]

Dear Rafael,

This indeed sounds like an interesting problem. The 'pushing-effect' may be linked to the fixed point temperature: if it is too high, - meaning at a temperature where reactions start to impact results, - it will shift the profile as this is the point that 'anchors' the simulation. Beyond, I have run a fair number of free flame simulations with inlet temperatures close to ignition. My approach was to generate a preliminary solution with ~100 points, which I used to 'remesh' externally, which allowed me to distribute grid points strategically. Once I had that, I restarted simulations where I turned remeshing off. I guess this isn't too far from Ray's suggestion, but my first step involved a regular Cantera simulation. As an aside, starting with Cantera 2.5, you can 'restart' from a suitably defined SolutionArray, which should work nicely for this purpose. Best of luck,

-ingmar-

[Rafael Meier]

Hello Ingmar,

My strategy is quite similar to what you described. I start from a normal simulation just fixing the width. And from the result, I remesh externally through an interpolation script that generates a nonuniform grid for temperature. Then I simulate using the guess temperature profile with refine_grid off. However, for conditions where the main flame front is quite affected by low-temperature combustion (large domains), the Cantera presents difficulties to converge. If you try to run the script that I attached to Ray, it took almost 22 hours to finish. I tried to use less refined grids before, but they crashed.

Thank you for your attention.

Regards,

Rafael

[Ingmar Schoegl]

Hi Rafael

I had a look at your scripts, and while you do impose a profile, I went a bit beyond that. In my most refined version (which unfortunatly uses the long-obsolete Python 2 interface), I wrote the entire solution to csv, and recreated all species profiles for the restart. If you restart without that information, the solver has a really hard time to find a solution and I am not surprised that it took a very long time. The new 'restart' I referred to in Cantera 2.5 sets the initial guess (see https://cantera.org/documentation/docs-2.5/sphinx/html/cython/onedim.html#cantera.FlameBase.set_initial_guess), so things should now be a lot more convenient. The other item I mentioned that I found to be extremely important is the 'fixed temperature' (https://cantera.org/documentation/docs-2.5/sphinx/html/cython/onedim.html#cantera.Sim1D.fixed_temperature), which needs to be higher than the inlet temperature but not so high that it puts the fixed point into the reactive region. I believe I remember that the default settings set by cantera internally often don't work with highly preheated inlet conditions.

-ingmar-

[Rafael Meier]

Hello Ingmar,

I implemented something similar what you described in your previous email. Then, out of curiosity, I killed the solver during the simulation's beginning to check if the profiles that I imposed were being used by the solver. Surprisingly, when I plotted, for instance, plot(f.grid,f.Y[gas.species_index('fuel')]);, it returned the standard profile that Cantera uses to start any simulation (a linear decay). I wonder, if this is what you should expect? I attached the files.

[Ingmar Schoegl]

Hi Rafael,

While this is similar to what I used to do, I remember that it was tricky to replace profiles with that approach. For Cantera 2.5.1, you should be able to accomplish this with a much simpler command. One example for this is buried in the unit tests; you may be able to glean some insights from this here: https://github.com/Cantera/cantera/blob/be6e971dc6436dbc2bf86e56a41cab4b511a3dc3/interfaces/cython/cantera/test/test_onedim.py#L294-L306

The important line here is line 300, which initializes all profiles to what is provided in the SolutionArray 'arr' (which in this case is the result from a previous simulation). What you'd have to do in your case is to create a SolutionArray based on an interpolation for the grid you'd like to use. There is actually a converter for pandas to SolutionArray, so this should be simple (see https://cantera.org/documentation/docs-2.5/sphinx/html/cython/importing.html#cantera.SolutionArray.from_pandas).

-ingmar-

[Rafael Meier]

Hello Ingmar,

Thank you for your help. It is running properly.

Regards,

Rafael

[Ssue]

Hi Ingmar,

I searched the source code defining the fixed temperature and put it here as following for convenience. It seems that the fixed temperature is set around the Tmid=0.75 * T0 + 0.25 * Teq, in which Teq is the equilibrium temperature. 

# Pick the location of the fixed temperature point, using an existing point if a reasonable choice exists
T = self.T
Tmid = 0.75 * T0 + 0.25 * Teq
i = np.flatnonzero(T < Tmid)[-1] # last point less than Tmid
if Tmid - T[i] < 0.2 * (Tmid - T0):
self.fixed_temperature = T[i]
elif T[i+1] - Tmid < 0.2 * (Teq - Tmid):
self.fixed_temperature = T[i+1]
else:
self.fixed_temperature = Tmid

However there is one thing still puzzling me here. That is, why the manually setting of fixed temperature should not be to high. My understanding is, as long as temperature profile is present as a whole, the final flame speed should be the same. Is there a spatial boundary for the fixed temperature in Cantera? Sorry for my limited knowledge about both deflagration and Cantera code. And could you give me a hand?

Ssue

[Ingmar Schoegl]

Hi Ssue,

My comment was based on some of my experience in the past. You are correct that the result should be the same, regardless of the choice of fixed point temperature. However, it does make a difference for the solver, as the fixed point temperature 'pins' the flame to the grid (it's an eigenvalue problem after all); the way I interpreted this back when I ran those simulations it is that any change of the temperature solution means that the profile of the flame needs to be shifted (which involves adjustments of flame speeds etc.). The 'reasonable' choice for the default above assumes that Tmid is in the preheating zone, where shifts are fairly predictable. For highly preheated flames, the default choice for Tmid puts the temperature into a zone where reactions impact the temperature, meaning that the profile gets pushed around, resulting in regridding etc.. I honestly haven't looked at the code at the moment, so this is based on my recollection but hopefully isn't too far off.

-ingmar-