Cantera Structure - Revision history

Admin: /* The Cons */

2017-04-17T08:31:05Z

The Cons

← Older revision		Revision as of 08:31, 17 April 2017
Line 82:		Line 82:
	==The Cons==		==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).		* More work is required of the user: writing or selecting appropriate numerical solvers. This would depend on governing equations and physics, and could heighten the barrier to entry.
			* 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.)		* 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.)

Admin at 08:29, 17 April 2017

2017-04-17T08:29:39Z

← Older revision		Revision as of 08:29, 17 April 2017
Line 1:		Line 1:
	~~{{Orphan\|date=April 2017}}~~
	=Background Information=		=Background Information=

Line 90:		Line 89:
	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.		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.

	~~[[Category:Cantera]]~~		=Flags=

			{{CanteraFlag}}

Bleep bloop: Bot: Orphan page, add template

2017-04-17T02:39:23Z

Bot: Orphan page, add template

← Older revision		Revision as of 02:39, 17 April 2017
Line 1:		Line 1:
			{{Orphan\|date=April 2017}}
	=Background Information=		=Background Information=

Admin: /* Conclusions */

2013-12-19T22:03:34Z

Conclusions

← Older revision		Revision as of 22:03, 19 December 2013
Line 85:		Line 85:
	* 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.)		* 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.)

	=~~Conclusions~~=		=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.		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.

	[[Category:Cantera]]		[[Category:Cantera]]

Admin at 22:03, 19 December 2013

2013-12-19T22:03:20Z

← Older revision		Revision as of 22:03, 19 December 2013
Line 1:		Line 1:
			=Background Information=

	==Overview of Cantera's Structure==		==Overview of Cantera's Structure==

Line 28:		Line 30:
	* OneDim		* OneDim
	* CVodesIntegrator		* CVodesIntegrator

	~~=Begged Questions=~~

	==Why Is Identifying Cantera's Layers Important?==		==Why Is Identifying Cantera's Layers Important?==

Admin: /* Overview of Cantera's Structure */

2013-12-19T22:02:31Z

Overview of Cantera's Structure

← Older revision		Revision as of 22:02, 19 December 2013
Line 5:		Line 5:
	[[Image:CanteraTwoLayer.png]]		[[Image:CanteraTwoLayer.png]]

	If the user is ~~simulating reactors and solving engineering problems, they are probably~~ interfacing with the solvers and numerics layer. if the user ~~is using~~ Cantera as part of an external routine to evaluate kinetics and transport properties~~, they are probably interfacing with the bookkeeping layer~~.		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 Bookkeeping Layer==

Admin: /* Overview of Cantera's Structure */

2013-12-19T21:59:22Z

Overview of Cantera's Structure

← Older revision		Revision as of 21:59, 19 December 2013
Line 4:		Line 4:

	[[Image:CanteraTwoLayer.png]]		[[Image:CanteraTwoLayer.png]]

			If the user is simulating reactors and solving engineering problems, they are probably interfacing with the solvers and numerics layer. if the user is using Cantera as part of an external routine to evaluate kinetics and transport properties, they are probably interfacing with the bookkeeping layer.

	==The Bookkeeping Layer==		==The Bookkeeping Layer==

Admin at 21:50, 19 December 2013

2013-12-19T21:50:09Z

← Older revision		Revision as of 21:50, 19 December 2013
Line 1:		Line 1:
	==Overview of Cantera's 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 structure of Cantera is bicephalous (meaning, two-headed). This two-layered structure can be explained using the following diagram:

	[[Image:CanteraTwoLayer.png]]		[[Image:CanteraTwoLayer.png]]
Line 7:		Line 7:
	==The Bookkeeping Layer==		==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 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 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.		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

	=Begged Questions=		=Begged Questions=
Line 21:		Line 35:
	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.		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.		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.

	~~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.''		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?==		==What Does This Mean For Future Cantera Development?==

	All of this is important to ~~understanding where~~ Cantera is ~~going in~~ the ~~future~~.		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).

	~~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:		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:

	<pre>		<pre>
Line 35:		Line 55:
	</pre>		</pre>

	or even		(or even

	<pre>		<pre>
Line 41:		Line 61:
	</pre>		</pre>

	~~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.		). 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=		=A Modest Proposal=

	The modest proposal I put forward, then, is to ~~simplify~~ the ~~Cantera~~ code base ~~to the point where~~ <code>pip install cantera</code> 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 modest proposal I put forward, then, is to strip Cantera of its numerics layer, making the code base simple enough that <code>pip install cantera</code> 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 new structure looks something like this:
Line 60:		Line 80:
	==The Cons==		==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).		* 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).
	* ~~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.)		* 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.)

	=Conclusions=		=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.		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.

	~~What do you think? Email me your thoughts~~.

	[[Category:Cantera]]		[[Category:Cantera]]

Admin at 21:26, 19 December 2013

2013-12-19T21:26:52Z

← Older revision		Revision as of 21:26, 19 December 2013
Line 68:		Line 68:

	What do you think? Email me your thoughts.		What do you think? Email me your thoughts.

			[[Category:Cantera]]

Admin: Created page with "==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: ..."

2013-12-19T21:21:17Z

Created page with "==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: ..."

New page

==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:

[[Image:CanteraTwoLayer.png]]

==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:

<pre>
pip install cantera
</pre>

or even

<pre>
brew install cantera
</pre>

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 <code>pip install cantera</code> 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:

[[Image:CanteraOneLayer.png]]

==The Pros==

* Simplified program structure, allowing simplified installation procedure, e.g., <code>pip install cantera</code>
* 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.