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.

Sign up for GitHub

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

Jump to bottom

Broken surf_pfr.py example #877

Closed
ischoegl opened this issue Jun 21, 2020 · 1 comment
Closed

Broken surf_pfr.py example #877

ischoegl opened this issue Jun 21, 2020 · 1 comment

Comments

@ischoegl
Copy link
Member

ischoegl commented Jun 21, 2020 •
edited
Loading

System information

  • Cantera version: development version
  • OS: Ubuntu 18.04
  • Python/MATLAB version: 3.6.9

Expected behavior

Example runs without error.

Actual behavior

Example errors with

In [1]: %run surf_pfr.py
    distance       X_CH4        X_H2        X_CO
---------------------------------------------------------------------------
CanteraError                              Traceback (most recent call last)
/src/interfaces/cython/cantera/examples/reactors/surf_pfr.py in <module>()
    108     upstream.syncState()
    109     sim.reinitialize()
--> 110     sim.advance_to_steady_state()
    111     dist = n * rlen * 1.0e3  # distance in mm
    112 

interfaces/cython/cantera/reactor.pyx in cantera._cantera.ReactorNet.advance_to_steady_state()

interfaces/cython/cantera/reactor.pyx in cantera._cantera.ReactorNet.step()

CanteraError: 
***********************************************************************
CanteraError thrown by Phase::setDensity:
density must be positive. density = -1.3738258649251213e-27
***********************************************************************

To Reproduce

See above.

Additional context

Error potentially introduced in the context of #720

A switch back from YAML to CTI input removes the issue, i.e. the error appears to be due to a bug in YAML conversion or parsing, see #902.
This was referenced Jun 21, 2020
Open
Merged
This was referenced Jul 5, 2020
Closed
Closed
@ischoegl
Copy link
Member Author

Closing this issue as it is superseded by #902.

@bryanwweber bryanwweber mentioned this issue Jul 29, 2020
Merged
4 tasks
bryanwweber added a commit to bryanwweber/cantera that referenced this issue Aug 1, 2020
@bryanwweber
[Reactor] Fix gas phase production on surfaces
bb191ed 
The calculation for the production of gas phase species from
surface reactions assumed that the gas phase species were stored at the
beginning of the rate-of-production array. This is only the case when
the gas ThermoPhase instance is the first phase in the Kinetics thermo
vector, which is not guaranteed to be the case.

It happens that XML input usually forced the gas phase to be the first
phase in the thermo vector, so everything worked out fine. This was
because the associated phase(s) for a surface phase had to be listed in
an XML file, and the XML initializer reads that list to fill the
Kinetics thermo vector.

In the YAML format, the associated phase does not need to be explicitly
listed. Instead, instances of the appropriate phases are passed to the
constructor when the InterfaceKinetics is created. The gas phase can
then come before or after the surface phase, meaning there is no
guarantee of the order of species.

This change checks for the starting index of the gas phase species in
the InterfaceKinetics species-length arrays to make sure that the
appropriate rates of production are added for the gas phase species.

Fixes Cantera#902, Cantera#877, Cantera#873
bryanwweber added a commit to bryanwweber/cantera that referenced this issue Aug 2, 2020
@bryanwweber
[Reactor] Fix gas phase production on surfaces
b110846 
The calculation for the production of gas phase species from
surface reactions assumed that the gas phase species were stored at the
beginning of the rate-of-production array. This is only the case when
the gas ThermoPhase instance is the first phase in the Kinetics thermo
vector, which is not guaranteed to be the case.

It happens that XML input usually forced the gas phase to be the first
phase in the thermo vector, so everything worked out fine. This was
because the associated phase(s) for a surface phase had to be listed in
an XML file, and the XML initializer reads that list to fill the
Kinetics thermo vector.

In the YAML format, the associated phase does not need to be explicitly
listed. Instead, instances of the appropriate phases are passed to the
constructor when the InterfaceKinetics is created. The gas phase can
then come before or after the surface phase, meaning there is no
guarantee of the order of species.

This change checks for the starting index of the gas phase species in
the InterfaceKinetics species-length arrays to make sure that the
appropriate rates of production are added for the gas phase species.

Fixes Cantera#902, Cantera#877, Cantera#873
bryanwweber added a commit to bryanwweber/cantera that referenced this issue Aug 20, 2020
@bryanwweber
[Reactor] Fix gas phase production on surfaces
5c7fe83 
The calculation for the production of gas phase species from
surface reactions assumed that the gas phase species were stored at the
beginning of the rate-of-production array. This is only the case when
the gas ThermoPhase instance is the first phase in the Kinetics thermo
vector, which is not guaranteed to be the case.

It happens that XML input usually forced the gas phase to be the first
phase in the thermo vector, so everything worked out fine. This was
because the associated phase(s) for a surface phase had to be listed in
an XML file, and the XML initializer reads that list to fill the
Kinetics thermo vector.

In the YAML format, the associated phase does not need to be explicitly
listed. Instead, instances of the appropriate phases are passed to the
constructor when the InterfaceKinetics is created. The gas phase can
then come before or after the surface phase, meaning there is no
guarantee of the order of species.

This change checks for the starting index of the gas phase species in
the InterfaceKinetics species-length arrays to make sure that the
appropriate rates of production are added for the gas phase species.

Fixes Cantera#902, Cantera#877, Cantera#873
bryanwweber added a commit to bryanwweber/cantera that referenced this issue Aug 20, 2020
@bryanwweber
[Reactor/1D] Fix gas phase production on surfaces
f2c2ab4 
The calculation for the production of gas phase species from
surface reactions assumed that the gas phase species were stored at the
beginning of the rate-of-production array. This is only the case when
the gas ThermoPhase instance is the first phase in the Kinetics thermo
vector, which is not guaranteed to be the case.

It happens that XML input usually forced the gas phase to be the first
phase in the thermo vector, so everything worked out fine. This was
because the associated phase(s) for a surface phase had to be listed in
an XML file, and the XML initializer reads that list to fill the
Kinetics thermo vector.

In the YAML format, the associated phase does not need to be explicitly
listed. Instead, instances of the appropriate phases are passed to the
constructor when the InterfaceKinetics is created. The gas phase can
then come before or after the surface phase, meaning there is no
guarantee of the order of species.

This change checks for the starting index of the gas phase species in
the InterfaceKinetics species-length arrays to make sure that the
appropriate rates of production are added for the gas phase species.

Fixes Cantera#902, Cantera#877, Cantera#873
speth pushed a commit that referenced this issue Aug 21, 2020
@bryanwweber @speth
[Reactor/1D] Fix gas phase production on surfaces
e4c54ba 
The calculation for the production of gas phase species from
surface reactions assumed that the gas phase species were stored at the
beginning of the rate-of-production array. This is only the case when
the gas ThermoPhase instance is the first phase in the Kinetics thermo
vector, which is not guaranteed to be the case.

It happens that XML input usually forced the gas phase to be the first
phase in the thermo vector, so everything worked out fine. This was
because the associated phase(s) for a surface phase had to be listed in
an XML file, and the XML initializer reads that list to fill the
Kinetics thermo vector.

In the YAML format, the associated phase does not need to be explicitly
listed. Instead, instances of the appropriate phases are passed to the
constructor when the InterfaceKinetics is created. The gas phase can
then come before or after the surface phase, meaning there is no
guarantee of the order of species.

This change checks for the starting index of the gas phase species in
the InterfaceKinetics species-length arrays to make sure that the
appropriate rates of production are added for the gas phase species.

Fixes #902, #877, #873
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@ischoegl