First efforts with Ember

[Jon Tegner]

Hi,

We are in the process of evaluating different kinetic models in a fluid flow combustion solver, and as a way to explain the differences we see we would like to (among other things) see how the different models are affected by strain.

Here we want to try Ember (thanks Ray!), and in a first attempt I wanted to do simulations of the "Twin Opposed-Jet Flame" case (as described in

http://speth.github.io/ember-doc/sphinx/html/flame-configurations.html). After looking at the examples, I thought this case could be achieved with the following:

#!/usr/bin/python

from ember import *

conf = Config(

    Paths(outputDir='run/twinOpposedJet_SMOOKE',

          logFile='twinOpposedJet_SMOOKE'),

    General(twinFlame=True,

            unburnedLeft=False,

            fixedLeftLocation=True),

    InitialCondition(fuel='CH4:1.0',

                     equivalenceRatio=0.70,

                     nPoints=200,

                     xRight=0.005),

    StrainParameters(initial=200000,

                     final=200000),

    Chemistry(mechanismFile="mixture.xml"),

    TerminationCondition(tEnd=0.020))

if __name__ == '__main__':

    conf.run()

The strain parameter is really big here, and the reason for this is that I wanted to see if I could extinguish the flame(s). However, this does not seem to happen, instead it seems (no systematic study here) that the flame converges to a certain position when the strain parameter is increased. I have tried two different mechanisms, with more or less the same result.

What might I be doing wrong here?

Regards,

/jon

/jon

[Ray Speth]

Hi Jon,

If you want to be able to extinguish the twin flame, the configuration option you need to set is General.fixedBurnedVal = false. If you set this, then you'll probably find that the flame extinguishes with a strain rate more on the order of 1000 1/s.

One thing to be careful of when looking for the extinction strain rate is that you probably want to start from a steady-state non-extinguished flame, and then increase the strain rate. If you start with the arbitrary initial profile that Ember generates, you may find extinction at a lower strain rate.

Regards,

Ray

[Jon Tegner]

Thanks!

Adding the line

fixedBurnedVal=False (under General)

gave the same profiles (at least in "picure norm"). Temperature is still fixed at left boundary (stagnation point in this case) - seemingly preventing the flame to become extinguished.

Could there be some other option I'm missing?

Regards, and thanks again,

/jon

--
You received this message because you are subscribed to the Google Groups "Cantera User's Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cantera-user...@googlegroups.com.
To post to this group, send email to canter...@googlegroups.com.
Visit this group at http://groups.google.com/group/cantera-users.
For more options, visit https://groups.google.com/groups/opt_out.

[Jon Tegner]

Ray,
Sorry to bother you  again , but I am stuck with this issue. Adding the line fixedBurnedVal=false did not change anything for me. I have tried different settings, and now I am starting to suspect I somehow managed to do something wrong when installing Ember, or when setting up the case.

If you have any hints it would be much appreciated.

Thanks again!
/jon

--

[Ray Speth]

Hi Jon,

I took a look at this configuration, and it seems there was a bug in the default initial profile generation for the twin flame. The code was generating an initial velocity profile that was non-zero at x=0, and holding that value fixed. While this is an intended configuration (simulating a source at the symmetry plane), it's not the intended default. I have corrected this in the most recent commits to Ember on Github. Also, the option fixedBurnedVal=False is now the default for twin flames.

For the example you gave, I now get extinction for a flame with strain rate 500 1/s when using GRI Mech 3.0.

Regards,

Ray

[Jon Tegner]

Super! Your help makes it a joy to work with Cantera/Ember!

I'll rebuild Ember as soon as I get to my office.

Thank you!

/jon

[Jon Tegner]

A quick rebuild (with your updated version) seemed to have resolved my issues!

Thanks again!

/jon

[H.C. Lee]

Hi Jon and Ray,

I have a couple questions regarding Ember.

I am planning to simulate lean-premixed counterflow to obtain the velocity profile along the x-axis, but Cantera only allows non-premixed. The first question is "can I use the "Twin Opposed-Jet Flame" to model it?". I only interested in SteadyState solution at this moment, and I understand Ember is used to find the time-dependent solution.

From my understanding, it seems plausible to use Ember to simulate steady state lean-premixed counterflow set-up. However, would it be easier for me to modify the non-premixed counterflow code to accomodate premixed?

One last question, why wasn't this great program (Ember) be written inside Cantera? (I am just curious.)

Hope to hear from you guys!

Thank you so much for all of your time!

Thanks,
Lee

[Jon Tegner]

Hi! From my VERY limited experience I would say that it would be easy to use Ember. Even though Ember is time dependent, a steady profile emerges quickly (for the cases I have tried, and if a steady solution exist).

Regards,
/jon

[H.C. Lee]

Thanks Jon! I will try out Ember!

Thanks Ray for developing such a great software!

Thanks,
Lee

[Ray Speth]

Hi Lee,

I've used Ember extensively for studying steady premixed counterflow flames, so a fair amount of effort has gone into getting good performance for this problem in particular. Solving the time dependent problem can be somewhat less computationally efficient than using a steady-state solver, but in my experience it's worth it for the increase in robustness. I find the convergence failures of the steady-state solvers to be a bigger hassle. The only cases where the using the time-dependent solver is particularly slow is for low strain rates, where you have a long physical settling time before the flame reaches steady-state.

Regards,

Ray

[Jon Tegner]

Sorry, me again!

Something else confusing me now:

When doing a fresh install of Ember on a different computer I found, when trying "import ember" in python that it can't find the module "Cantera". I'm building against Cantera 2.1, and it seems there the module is named "cantera" (lower case)?

However, when putting Cantera 2.0.1 in PYTHONPATH Ember seems to be running - should I be happy with this, or is this something I should do something about?

Furthermore, when trying to build Ember against Cantera 2.0.1 I got an error of the type

update_rates_T' is not a member of 'Cantera::GasKinetics'

Regards,

/jon

[Ray Speth]

Hi Jon,

Ember currently requires the older version of the Cantera Python module (capital "Cantera"). If you need to build the old version of the Python module for Cantera 2.1, you can use the option "python_package=full" when running "scons build", or you can just keep a copy of the Cantera 2.0 Python module around. I'll be updating Ember to support the new Cantera Python module (lowercase "cantera") once Cantera 2.1 is officially released.

The error you're getting about "update_rates_T" is because Ember requires Cantera 2.0.2 or newer. I believe this is mentioned in the build requirements.

Regards,

Ray

[Jon Tegner]

Thanks for explaining! Should have read a bit more careful...

/jon

[H.C. Lee]

Hi Ray and Jon,

Thank you so much for all the valuable insight. You guys have been very very helpful and knowledgeable.

Thanks,
Lee

[Jon Tegner]

OK, now it is running, but I have problems when running a list of strains:

AttributeError: 'ember._ember.FlameSolver' object has no attribute 'writeStateFile'

Most probably i missed something either in Config, or in the build process of Ember.

Thanks!

/jon

[Jon Tegner]

Bah, I'm just asking (sometimes stupid) questions ;-) But I obviously share your gratitude over Rays knowledge and support.

/jon

[Ray Speth]

Hi Jon,

Nothing wrong with what you're doing. I apparently missed a few things in the multi-strain rate feature when I was updating the Python interface to use Cython. It should be better now (as of the latest commit to 'master' on Github).

Regards,

Ray

[Jon Tegner]

Great!

I can confirm that it is working now.

Thanks,

/jon