Cantera Structure

Overview of Cantera's Structure

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

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.

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.

Begged Questions

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, 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.

This observation is 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 understanding where Cantera is going in the future.

Currently, one of the most significant barriers to using Cantera is its installation procedure. In order to make Cantera a more widely-used and ubiquitous tool, and a competitive alternative to Chemkin, the complications involved in installing Cantera must be resolved. Ideally, we need an installation procedure as simple as:

pip install cantera

or even

brew install cantera

To develop either of these options with Cantera as it currently exists would be a mess. But much of the mess comes from the Numerics layer.

A Modest Proposal

The modest proposal I put forward, then, is to simplify the Cantera code base to the point where pip install cantera is feasible, by doing away with the Numerics layer. This would eliminate the parts of Cantera that do things that other software does better, and focus Cantera (and future Cantera development) on the things that Cantera does well.

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, but there are ways to ease this difficulty (such as creating additional Cantera "modules" that would create APIs for different solvers like Sundials or Scipy).
• The API may need some enhancement, and additional examples or documentation would need to be added to illustrate how to interface the bookkeeper with the numerics. (But as mentioned above, a smaller code base and a wider user base would help alleviate some of this.)

Conclusions

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

What do you think? Email me your thoughts.