Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Link FlameBase.to_solution_array to C++ SolutionArray #166

Closed
ischoegl opened this issue Mar 23, 2023 · 0 comments · Fixed by Cantera/cantera#1464
Closed

Link FlameBase.to_solution_array to C++ SolutionArray #166

ischoegl opened this issue Mar 23, 2023 · 0 comments · Fixed by Cantera/cantera#1464
Labels
Python work-in-progress An enhancement that someone is currently working on

Comments

@ischoegl
Copy link
Member

ischoegl commented Mar 23, 2023

Abstract

At the moment, the FlameBase.to_solution_array method assembles a SolutionArray in Python instead of accessing the Domain1D::asArray serialization method of the C++ object. One consequence is that the output order of components is incorrect.

Motivation

Describe the need for the proposed change:

  • What problem is it trying to solve? ... remove/deprecate redundant code
  • Who is affected by the change? ... users of Cantera 3.0
  • Why is this a good solution? ... the conversion should use the same tools as the C++ save/restore methods

Possible Solutions

There are two options:

  1. Implement Sim1D::asArray(const string& name) and link to FlameBase.to_solution_array; one complication is that the C++ route does not normalize, which is the current default behavior in Python.
  2. Implement Domain1D::asArray() and link to a new Domain1D.to_solution_array; here, the complication is that Domain1D knows its container, but is is accessed as OneDim, which does not hold the solution vector; as in other instances, the code uses raw pointers internally, which ideally would have to be converted to smart pointers.

References

@ischoegl ischoegl added feature-request New feature request help wanted Extra attention is needed Python labels Mar 23, 2023
@ischoegl ischoegl removed the help wanted Extra attention is needed label Mar 23, 2023
@ischoegl ischoegl added work-in-progress An enhancement that someone is currently working on and removed feature-request New feature request labels Mar 25, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Python work-in-progress An enhancement that someone is currently working on
Projects
No open projects
Development

Successfully merging a pull request may close this issue.

1 participant