Metal/electron-cloud: thermo consistency errors caused by placeholder density
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 52/100
Research direction
Start with the electron-cloud thermo model and its MetalPhase class, then inspect the YAML documentation for the density field. Review molarVolume(), partial molar volume methods, and intEnergy_mole() against the requested volumeless behavior. Done means the phase reports zero volume, the density field is deprecated, and the listed thermodynamic quantities remain consistent.
Written by the indexing model from the issue text.
Description
Problem description
The electron-cloud thermo model (class MetalPhase) includes a specification for the density, which is described in the YAML documentation as "the density of the bulk metal". However, this density is then used to determine the molar volume of the electron cloud "phase" and used in a thermodynamically inconsistent way in the calculation of gibbs_mole, enthalpy_mole, and intEnergy_mole.
For a phase with a constant density (or equivalently, molar volume), the following thermodynamic identities should be satisfied:
$$ \left(\frac{\partial G}{\partial P}\right)_T = V $$
$$ \left(\frac{\partial H}{\partial P}\right)_T = V − T\left(\frac{\partial V}{\partial T}\right)_P = V $$
$$ \left(\frac{\partial U}{\partial P}\right)_T = \left(\frac{\partial H}{\partial P}\right)_T − V − P\left(\frac{\partial V}{\partial P}\right)_T = 0 $$
However, the current implementation instead currently gives:
$$ \left(\frac{\partial G}{\partial P}\right)_T = 0 $$
$$ \left(\frac{\partial H}{\partial P}\right)_T = 0 $$
$$ \left(\frac{\partial U}{\partial P}\right)_T = -V $$
Since this model is meant to represent conduction electrons in a metal, where these electrons are not a phase with their own volume but rather a bookkeeping device, the thermodynamically meaningful quantity is the electron's partial molar volume: the change in system volume when one mole of conduction electrons is added at fixed T, P, and host composition. This partial molar volume should be zero and any real volume change of an electrode as it charges/discharges belongs to the host phase's equation of state (for example, the binary-solution-tabulated electrode).
If we set the molar volume of this phase to zero, then we will obtain thermodynamic consistency with all three of the above partial derivatives being equal to zero.
Suggested fix: make the phase volumeless
Give the electron-cloud phase zero (partial) molar volume, declared directly rather than derived from a density:
-
Override the volume to zero. Make
molarVolume()and the partial molar volumes return0. This is the operational way to express "layered into another phase; adds no volume of its own" in Cantera's additive-volume multiphase model. -
Leave the potentials alone.
gibbs_mole(),enthalpy_mole(),entropy_mole(),getChemPotentials(),getStandardChemPotentials(),getPartialMolarEnthalpies()stay at0. They are now legitimately consistent withV = 0. -
Remove the
intEnergy_mole()override. WithH = 0andV = 0, the base-classU = H − PV = 0is automatic. -
Deprecate the
densityfield. It no longer defines the thermodynamic volume.
System information
- Cantera version: 4.0.0a1 /
mainbranch at 622e3051b - OS: any
- Python/MATLAB/other software versions: any
This Issue description was partially written using Claude Opus 4.8.
- Dominant language
- C++
- Stars
- 883
- Forks
- 436
- Avg merge
- 3h 41m
- Merged PRs (30d)
- 1
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from Cantera/cantera
-
Names for cantera library in LibCantera.jl don't match built library names, preventing Julia cantera interface from loadingPossibly taken @redwing509 claimed this 1 day ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
Incorrect reference state in some of the YAML files.Possibly taken @hazalkoom claimed this 57 days ago. OpenInput
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
Reactor cloning loses stoichiometric precision, eliminating small net species source termsPossibly taken @redwing509 claimed this 1 day ago. Open
Difficulty 3/5 1-2 days Newbie friendliness 62/100
-
[Bug]`ReactorNet.advance()` is not reproducible when an advance limit is set (root-finding arrays left uninitialized when `CVodeRootInit` is toggled per call)Possibly taken @kimurap claimed this 43 days ago. Open
Difficulty 4/5 3-5 days Newbie friendliness 55/100
-
CI
Difficulty 4/5 3-5 days Newbie friendliness 48/100
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 69/100
-
area:qmc bug
Difficulty 2/5 1-3 hours Newbie friendliness 69/100
Maintainers usually reply within 3 days
-
bug good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
ASGC-Game-Jam/asgc-gamejam-2026#563 ·
Maintainers usually reply within 1 day
-
area/ysql kind/bug priority/medium status/awaiting-triage
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
yugabyte/yugabyte-db#37523 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 66/100