You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Originally posted by ischoegl April 19, 2021
Cantera is quite large, and mixes core and toolbox objects within the same libraries. Some users may only be interested in linking to core objects (species, reactions and their YAML importers), but may not require reactor networks and one-dimensional simulations.
Within C++, a core C++ cantera library would be much leaner than application toolboxes (no sundials, etc.), which may be attractive for those working with OpenFOAM, or any other 3rd party application. I personally do not believe that a split into multiple repositories makes sense whatsoever, as zerod and onedim toolboxes are an integral part of Cantera.
For Python, all objects are currently available at the root level
importcanteraasct
...
where users pick what they need. As an alternative, objects could be topically sorted
which may be more intuitive/instructive to new users. I do realize that the same is possible by writing from cantera import Solution, Reactor, but my point is that those are really two different contexts. Splitting the Python API actually would not require a corresponding split at the C++ level, but doing both would be consistent.
One of the main questions here is the difficulty of splitting libcantera into multiple libraries for core and zerod/onedim? Outside of stock cantera, it is relatively straight-forward to compile against cantera headers and libraries (which I have done several times over the years; as an aside, code compiles much faster), so the question is whether it is feasible to do this the same repository.
This certainly would be a long-term aspirational project,.
PS: The discussion was originally started in #93, but per @bryanwweber and @speth feedback deserves its own thread.
The text was updated successfully, but these errors were encountered:
Converting #97 into a feature request.
Discussed in #97
Originally posted by ischoegl April 19, 2021
Cantera is quite large, and mixes core and toolbox objects within the same libraries. Some users may only be interested in linking to core objects (species, reactions and their YAML importers), but may not require reactor networks and one-dimensional simulations.
Within C++, a
core
C++ cantera library would be much leaner than application toolboxes (no sundials, etc.), which may be attractive for those working with OpenFOAM, or any other 3rd party application. I personally do not believe that a split into multiple repositories makes sense whatsoever, as zerod and onedim toolboxes are an integral part of Cantera.For Python, all objects are currently available at the root level
where users pick what they need. As an alternative, objects could be topically sorted
which may be more intuitive/instructive to new users. I do realize that the same is possible by writing
from cantera import Solution, Reactor
, but my point is that those are really two different contexts. Splitting the Python API actually would not require a corresponding split at the C++ level, but doing both would be consistent.One of the main questions here is the difficulty of splitting
libcantera
into multiple libraries for core and zerod/onedim? Outside of stock cantera, it is relatively straight-forward to compile against cantera headers and libraries (which I have done several times over the years; as an aside, code compiles much faster), so the question is whether it is feasible to do this the same repository.This certainly would be a long-term aspirational project,.
PS: The discussion was originally started in #93, but per @bryanwweber and @speth feedback deserves its own thread.
The text was updated successfully, but these errors were encountered: