Non-Adiabatic Flame Calculations

[joshua.s...@gmail.com]

Hello all,

I have been using Cantera for a short while but have not yet dug around in the source code much.

One area of interest is in the modeling of non-adiabatic flames, such as one might use in a flamelet table for flamelet generated manifolds. For such calculations it seems like the requirement would be to simply add a source term to the energy equation to account for heat loss. In more complex models this term might be a function of flame parameters but for me, right now, it would be sufficient to have a simple scalar designated by the user. It would be ideal to pass the value of this scalar (the heat loss) as an attribute of the FreeFlame object.

Something like:

f = ct.FreeFlame(gas, initial_grid)

f.set_heat_loss_units('J')

f.set_heat_loss(1000)

As far as I can tell, the closest thing Cantera has to this is in the BurnerStabilizedFlame object, where one can pass the burner temperature. Presumably this value contributes to conduction in the energy equation. This is less than ideal for me, however, because the heat loss cannot be controlled a priori.

Is there an existing version/branch of Cantera with similar behavior already extant in the 1D flame equations? If not, where is the best place to insert it?

Thanks in advance,

Josh Sykes

[Ray Speth]

Josh,

There isn't anything quite like this currently in Cantera. My understanding was that a common approach for developing flamelet tables was to look at strained flames, where increasing the strain rate increases the losses and at high enough values leads to extinction. In this case, you could use the strained flame models already present in Cantera, e.g. the opposed flow premixed flame or opposed flow twin flame.

If you wanted to have an explicit heat loss term, you would need to think about how that is distributed spatially within the flame. I think the simplest approach that wouldn't result in severe numerical problems would be as a heat transfer coefficient between the flame and an environment at some specified temperature.

Regards,

Ray

[joshua.s...@gmail.com]

Ray,

Thank you for your quick response.

I have used the opposed flame utilities for flamelet generation and they have been useful so far. They do indeed fulfill most FGM models but I am attempting to use heat loss (independent of stretch) as an additional variable in table generation--that is, flamelets are determined by equivalence ratio, stretch rate, and some heat loss to surroundings. I may end up doing as you suggest to implement the heat loss term and just solve the equations in my own solver.

Thanks for your help! Cantera has been very useful.

Josh Sykes

[Ray Speth]

Josh,

Adding this term to the energy equation in the StFlow class should be fairly easy. I think the slightly challenging part would be in making it possible to specify the heat flux from the Python interface, depending on how you want to define it. If you decide to go with this approach, let me know and I can provide some pointers on how to add the relevant interface functions.

Regards,
Ray

[joshua.s...@gmail.com]

Ray,

I think I accidentally sent this message as a "private message" earlier, for which I apologize.

As far as adding the heat loss term to StFlow.cpp, my method is to add it after the divHeatFlux, sum, and sum2 terms in the if(m_do_energy[j]) {... section on line 437. For context I am compiling Cantera 2.2.1.

Concerning passing variables through interfaces, I had some thoughts but wanted to see if you had pointers. I know I need to add some type of "heat_loss" attribute to the FlameBase class in onedim.py. This code would then "seen" by onedim.pyx to be legible in C. My question is: from where in the C++ files are the attributes of FlameBase "visible?" How will the C++ code know about the existence of these attributes at the time of compiling?

Any pointers you may have would be appreciated.

Thank you,

Josh Sykes

[Ray Speth]

Josh,

Right, that's the equation you want to modify in class StFlow. The question is what the form of the heat loss term is. You could in principle use anything from a constant value to an arbitrary function of location, temperature, and mixture composition or anything inbetween. There's a bit of a tradeoff between simplicity of implementation and flexibility of use that needs to be made. Do you have some concept for what you want this heat loss term to look like?

The steps from there are to add variables and methods necessary to implement this to the C++ StFlow class. After that, you can add the wrappers for the Cython module. I think you need to invert your concept of how the C++/Python interface works: Cython is used to call methods of C++ objects from Python, but with a few exceptions, the C++ code knows nothing about the existence of Python objects.

I would strongly recommend starting not from the Cantera 2.2.1 release but from the current 'master' branch on Github, both to take advantage of improvements that have been made to the 1D solver since Cantera 2.2.1 was released and to make it easier to integrate your changes with the master branch in the future.

Regards,

Ray

[joshua.s...@gmail.com]

Ray,

I have migrated to Cantera 2.3 but this has let to some unexpected compiling difficulties. Although I have compiled 2.2 successfully, in the case of 2.3 SCons throws the following error:

A shared library should have exactly one target with the suffix: .dll

Looking into the SCons documentation seems to indicate that this comes from mingw.py, where SCons attempts to find a "cantera_shared.dll" for linking purposes. In the case of Cantera 2.2.1 this file appears in build\lib\cantera_shared.dll but in 2.3.0 this .dll does not exist in my copy of the cantera file structure. I know that the "build" folder is only created after some compiling has taken place but I am confused as to why 2.2 can do this without issue but 2.3 seems to have this problem.

Do you know the reason for this discrepancy, or have I missed something?

Thank you,

Josh Sykes

[Ray Speth]

Josh,

Can you provide the full output of 'scons build VERBOSE=y' command (please run 'scons clean' first)?  Also, can you specify the versions of SCons and your compiler (I guess you're using MinGW?).

Regards,

Ray

[joshua.s...@gmail.com]

Ray,

I have attached a text file which contains the full SCons output including the "clean" and "build verbose" steps. I am using SCons 2.5.0 and MinGW for the build.

Thank you,

Josh Sykes

[Ray Speth]

Josh,

There seems to be a bug in recents versions of SCons on this. If I use SCons 2.5.0, I get the behavior you describe. Downgrading to SCons 2.3.6 resolves the issue for me, and I expect that will work for you as well (let me know if it doesn't, though).

I'll try to produce a more minimal example and take it up with the SCons developers. Thanks for reporting the issue.

Regards,

Ray

[joshua.s...@gmail.com]

Ray,

Thanks for your response and patience. I am sorry to keep bringing up issues but I am having difficulty even after the migration to SCons 2.3.6. Although the "shared_library" issue no longer appears, the C++ base of Cantera still throws errors I have not seen mentioned on this forum. I have attached a text file containing the SCons output. If you have suggestions on how to eliminate these errors I would appreciate it.

For good news, my version of Cantera 2.2.1 with the heat loss attribute in Python does work--in Python 2, since the Python 3 module has other compiling issues. I can post the changed files as soon as the 2.3 compiling is successful.

Thank you,

Josh Sykes

[Ray Speth]

Josh,

That error looks like you are using a compiler version that does not implement all of the C++11 standard. What version of GCC are you using (not the version of MinGW -- the version of the underlying compiler, i.e. what you get by running 'g++ --version')? You need to use at least GCC 4.7.

Regards,

Ray

[joshua.s...@gmail.com]

Ray,

Indeed, I was using GCC 4.5. After upgrading to a new distribution of MinGW, however, SCons seems to have difficulty locating the Boost libraries. (I got MinGW 14.0 from here: https://nuwen.net/mingw.html because I am compiling on an offline machine.)

I have attached the config.log from the failed Cantera 2.3.0 build. I did set the "boost_inc_dir" SCons variable to "MinGW/include/boost" (my location of the boost library) but the error is persistent. I'm not sure why the compiler can see "cmath.h" and other headers but not the Boost ones even when seemingly directly pointed to them. If you have ideas on how to resolve this it would be appreciated. I guess I could go into the SConstruct and remove the calls for the Boost libraries but that seems like a violent solution that could affect other parts of the program.

Thank you,

Josh Sykes

On Thursday, November 17, 2016 at 5:26:25 PM UTC-5, Ray Speth wrote:

[joshua.s...@gmail.com]

Quick clarification here, in my last post I said that I had set the "boost_inc_dir" SCons variable to "MinGW/include/boost" but I really meant that I used "MinGW-new/include/boost", which should be reflected in the config.log file I posted.

Thanks again,

Josh Sykes

[Ray Speth]

Josh,

Does the directory "C:\mingw-new\include\boost" contain "version.hpp"? From your link, it looks like you have a copy of MinGW that should have Boost bundled and therefore it should not be necessary to specify boost_inc_dir.

Are you certain that the correct copy of MinGW is what's on your path and is being used by SCons? What is the output of the command:

    g++ -E -x c++ - -v

This should list the compiler's default include search directories.

Modifying SConstruct to remove the check for Boost will not work. You will just run into compilation errors later when trying to compile parts of Cantera that actually need the Boost headers.

Regards,

Ray

[joshua.s...@gmail.com]

Ray,

I did have the required header files in the correct folders. The issue, as you guessed, was that gcc's CPATH did not include the "C:\mingw-new\include\" directory. This is the only MinGW release I've seen that doesn't automatically link the "include" directory but I did fix it by passing an "-I path/to/include" in the "ccflags" options for SCons. Something of a blunt solution but it does pass the header.

Despite this change the "std::mutex" error is still occurring (my gcc version is now 6.1.0). It seems that other versions of MinGW have had issues with this command in the past: http://stackoverflow.com/questions/14191566/c-mutex-in-namespace-std-does-not-name-a-type. It's supposedly been resolved but perhaps a related issue is affecting my build.

It appears that I am just cursed. Thanks for your help and patience.

Josh Sykes

[Ray Speth]

Josh,

Interesting. You might want to try the MinGW distribution from http://mingw-w64.org/doku.php. This is where I installed it from, and can confirm that their builds have support for the C++ threading features (or at least the subset used by Cantera).

Regards,

Ray

[joshua.s...@gmail.com]

Ray,

Thank you for your suggestion. I have tried to use installers from that website but unfortunately I the machine on which I run Cantera is offline. My workplace requires that any machine with admin access has no internet connection and any machine with internet connection has no admin access.

I think for now I will continue using the 2.2.1 build. I know it does not take full advantage of the 1D solver capabilities but in this way I can still generate flamelet tables for my original purpose. I'll continue working with the MinGW issues on the side.

If you want I can still post the modified 2.2.1 files or even post modified 2.3.0 ones. Although I couldn't compile them it seems likely that I could make the same changes in 2.3.0 without issue.

Thank you,

Josh Sykes

[Ray Speth]

Josh,

I was recently reminded about TDM-GCC, which is a MinGW distribution that (a) appears to have C++11 thread support and (b) has an offline installer. If you are able to try building the current development version using this compiler version, please let me know how it turns out.

Regards,

Ray

[SenthilKumar Narendran]

Hello all,

Please let me the status of this implementation. I am having a similar situation to implement heat loss for counter flow premised flow.
Thanks
Senthik

[ananda sreenivas]

HI Ray,

Could you kindly let me know the instructions to build cantera once I edit the C++ file of stagnation flow. Do we have build instructions in a repository?

Thanks

Ananda

[Bryan W. Weber]

Ananda,

We have compilation instructions in the documentation: http://cantera.org/docs/sphinx/html/compiling/index.html It has recently been rewritten to (hopefully!) be clearer, if you find any places where improvements can be made, please do let us know.

Best,

Bryan

[Kévin Bioche]

Hello,

I find my question should fit in this discussion.

I am implementing convective heat loss added to the 1D freely propagating flame model. It works fine with C++, now I want to use the python interface and am looking for some hints on how to modify the sources.

ABOUT THE MODEL :

 It is expressed as alpha_loss*(T - T0). alpha_loss being a convective heat loss coefficient and T0 a reference temperature (to be set to the initial temperature in most cases).

HERE IS WHAT I DID regarding C++ :

I installed the sources and made some modifications to the following files:

1) /include/cantera/oneD/StFlow.h

I defined a new function,

+    // setConvectiveHeatLossesParameters
+    void setConvectiveHeatLossesParameters(double alpha_loss, double T0) {
+       m_alpha_loss = alpha_loss;
+       m_T0 = T0;
+    }

And set-up the defaut values

+    // alpha_loss and T0 for convective heat losses
+    double m_alpha_loss = 0.0;
+    double m_T0 = 300.0;

2) /src/oneD/StFlow.cpp

I added this term to the energy equation (slightly modified to have convenient dimensions)

+                rsd[index(c_offset_T, j)] -= (m_alpha_loss / (m_rho[j] * m_cp[j])) * ( T(x,j) - m_T0);

In conclusion:

I ran successfully such computation from c++ programs, e.g. I modified one of the samples

/samples/cxx/flamespeed/flamespeed.cpp

+       // heat losses
+       double alpha_loss = 5.0E3;
+       double T0 = 300.0;

+       flow.setConvectiveHeatLossesParameters(alpha_loss, T0);

and got what intended.

QUESTIONS regarding the python interface :

I would like to use a similar function within my python run, something like:

+ flame.set_convective_heat_losses_parameters(alpha_loss,T0)

before solving the case.

I have a hard time understanding how to make c++ sources understand that such a declaration in my python run would correspond to the function "setConvectiveHeatLossesParameters" of the sources.

I looked for an example of such process in the file present in /build/python/cantera/ but did not find how to do. 

Which files should I modify and how ?

Best,

Kévin