Cantera/Structure

Background Information

Overview of Cantera's Structure

The structure of Cantera is bicephalous (meaning, two-headed). This two-layered structure can be explained using the following diagram:

Typically, the user is interfacing with the solvers and numerics layer, because Cantera was written such that the Reactor and ReactorNet classes, or Sim1D or OneDim equations, which wrap differential equation solvers, could be used to solve practical engineering problems. However, the user can interface with the bookeeping layer of Cantera directly, if, for example, they want to use Cantera as part of an external routine to evaluate kinetics and transport properties for a CFD solver or a more sophisticated numerical solver.

The Bookkeeping Layer

The first layer of Cantera, the Kinetics/Thermo/Transport Bookkeeping layer, consists of the classes that handle tasks such as importing XML or CTI files, which contain reaction mechanisms, transport mechanisms, and thermodynamic data, and using that information to set the state of particular phases. It also consists of Cantera phase objects, such as ideal gases. Some classes in the bookkeeping layer include, but are not limited to:

• ChemEquil
• GasKinetics
• ReactionStoichMgr
• Phase
• IdealGasPhase
• SurfPhase
• MultiTransport
• MixTransport

The Numerics Layer

The second layer of Cantera, the Solvers/Numerics layer, contains most of the pieces that the user typically interfaces with - the reactors, the reactor networks, the 1D domains, the stagnation or symmetric flames, and so on. This is also the layer that interfaces with the Sundials library. Some classes in the numerics layer include, but are not limited to:

• Reactor
• ReactorNet
• Domain1D
• Sim1D
• OneDim
• CVodesIntegrator

Why Is Identifying Cantera's Layers Important?

Now, you may raise the question: why is this important?

If you're using a stock install of Cantera to simulate precisely the kinds of problems that Cantera's numerical routines were designed to solve, you'll run into few limitations.

However, as soon as you want to extend Cantera's non-combustion capabilities to solve 1D problems or to incorporate transport effects, or extend Cantera's combustion examples to use more complex numerical schemes, or couple Cantera to an already-existing equation solver like OpenFoam, you quickly run up against the limitations of the numerical layer of Cantera. This is because the numerical layer of Cantera is intended primarily to solve ordinary differential equations - which is why Cantera is linked to the Sundials library - and is not intended to solve more complex partial differential equations. And while the Sundials library is powerful, it is only powerful for ordinary differential equations, i.e., equations that are function of a single dimension.

Furthermore, while it is possible to extend Cantera's equation solvers to larger and more complex problems, this is reinventing the wheel. There are many libraries that already provide the classes and interfaces needed to solve these problems, and do it much better than the average user implementing their own version within the confines of Cantera.

Here is why these observations are important: Cantera's primary usefulness is not its numerical routines, as there are huge number of libraries that provide various approaches to solving various differential equations.

Cantera's primary usefulness is in its bookkeeping capabilities.

What Does This Mean For Future Cantera Development?

All of this is important to figuring out a direction for Cantera, moving forward.

Currently, Cantera's installation procedure is onerous and temperamental, subject to the constantly-changing compiler toolchains of operating systems (cough cough, APPLE).

In order to make Cantera a more widely-used and ubiquitous tool, and a truly competitive alternative to Chemkin, the complications involved in installing Cantera must be resolved, and an installation procedure developed that is as simple as:

pip install cantera

(or even

brew install cantera

). Developing either of these options with Cantera as it stands would be difficult. But much of the difficulty comes from the Numerics layer.

A Modest Proposal

The modest proposal I put forward, then, is to strip Cantera of its numerics layer, making the code base simple enough that pip install cantera would be feasible. This would eliminate parts of Cantera that do things that other software does better anyway, and focus Cantera (and future Cantera development) on the things that Cantera does well - kinetics, thermodynamics, and transport bookkeeping.

The new structure looks something like this:

The Pros

• Simplified program structure, allowing simplified installation procedure, e.g., pip install cantera
• A wider user-base, thanks to simplified installation procedure
• Greater flexibility in Cantera applications; the user is no longer limited to Cantera's numerical capabilities
• Smaller code base, covering less redundant topics (e.g., not implementing numerical solvers and routines that dozens of other libraries have already implemented) and encouraging further development

The Cons

• More work is required of the user; specifically, the user has to write the numerical solvers. This means that the user has to take the extra step of understanding what their governing equations are, and how to discretize them. This would heighten the barrier to entry. (However, there are ways to ease this difficulty, e.g., by creating Cantera "modules" or APIs for different solvers like Sundials or Scipy).
• Additional examples and documentation for examples would be needed (but, as mentioned above, a smaller code base and a wider user base would help alleviate some of this.)

Bottom Line

Eliminating the Numerics layer from Cantera would lead to a simpler, more flexible, and less redundant library that would be easier to install and have a wider user base.