High: [Phases] Multi-temperature VaporPhase mass-basis latent heat drops component columns

[andres9403]

Maintainer triage (July 7, 2026)

• Status: Verified bug against PR Fix VaporPhase mass-basis latent heat weighting #100 head (56c68351166867a09d3cdae8eb11cf029303c61f); adjacent code path is pre-existing and not introduced by PR Fix VaporPhase mass-basis latent heat weighting #100.
• Severity: High.
• Area labels: area:phases, area:thermo.
• Tackle batch: P2 - shared thermo, phase, and basis correctness.

The source review and a local reproduction confirmed that the cited code path and failure mode are present. The original audit details are preserved below for reproduction notes and suggested fixes.

---

Original audit details

Severity: High · Category: shape/basis mismatch · Found during PR #100 review

Multi-temperature mass-basis latent heat drops supercritical component columns before mixture weighting

Location: PharmaPy/Phases.py:651-655 (VaporPhase.getHeatVaporization, mass-basis multi-temperature branch) and PharmaPy/Phases.py:732-733 (VaporPhase.getEnthalpy mixture weighting)

When getHeatVaporization receives multiple temperatures, it builds a full (num_temp, num_comp) deltahvap array and fills only the subcritical component columns. In the basis='mass' branch, it then reassigns deltahvap = deltahvap[:, idx] / self.mw[idx] * 1000, shrinking the second dimension from all components to only the subcritical component subset.

VaporPhase.getEnthalpy(..., basis='mass') subsequently computes np.dot(deltaVap, mass_frac). When any component is supercritical across the requested temperatures, deltaVap no longer has the same component dimension as mass_frac, so the mixture enthalpy calculation raises a shape mismatch.

• Trigger: A multi-component VaporPhase with array-like temp, basis='mass', and at least one component above its critical temperature while another remains subcritical.
• Wrong result: getHeatVaporization(temp_array, basis='mass') returns a reduced latent-heat array such as shape (2, 1) for a two-component phase, while getEnthalpy(temp=temp_array, basis='mass') dots that against a full length-2 mass-fraction vector and raises ValueError: shapes (2,1) and (2,) not aligned.
• Suggested fix: Preserve the full component dimension in the mass-basis multi-temperature branch, converting only the populated subcritical columns to J/kg and leaving supercritical component columns at zero latent heat.
• Net-new (not a duplicate): Related to Critical: [Phases] VaporPhase mass-basis enthalpy weights latent heat by mole fraction #18 because both involve VaporPhase mass-basis latent heat, but Critical: [Phases] VaporPhase mass-basis enthalpy weights latent heat by mole fraction #18 is the single-temperature mixture-weighting bug fixed by PR Fix VaporPhase mass-basis latent heat weighting #100. This issue is a separate multi-temperature shape mismatch in getHeatVaporization.

Minimal reproduction on PR #100 head:

temps = np.array([660.0, 680.0])
phase.getHeatVaporization(temps, basis="mass").shape  # (2, 1)
phase.getHeatVaporization(temps, basis="mole").shape  # (2, 2)
phase.getEnthalpy(temp=temps, basis="mass")

Observed error:

ValueError: shapes (2,1) and (2,) not aligned: 1 (dim 1) != 2 (dim 0)

Related existing issues (referenced, not modified): #18 (VaporPhase.getEnthalpy mass-basis latent heat weights by mole fraction) -- related but distinct; #18 does not cover the multi-temperature latent-heat array shape reduction.

---

Found during PR #100 review; confirmed by source review and a local reproducer.

[Mazhar331]

Coordination note from PR #116 / issue #48 review:

PR #116 originally exposed a small test-fixture ambiguity around Drying.energy_balance: using the same count for drying nodes and volatile components made a length-2 latent-heat vector hard to read. That PR has now changed the regression fixture to 3 nodes and 2 volatiles, so its latent_heat stub is clearly per volatile component.

The broader shape contract still belongs here in #101. When VaporPhase.getHeatVaporization(..., basis="mass") is fixed to preserve the full component dimension for multi-temperature calls, please also audit the Drying consumer:

drying_terms = (dry_rate[:, self.idx_volatiles] * latent_heat * 2).sum(axis=1)

Today this may work incidentally because the current #101 bug can shrink latent_heat down to subcritical/volatile columns. After #101 preserves full component columns, Drying should explicitly select the volatile latent-heat columns before multiplying, with appropriate handling for scalar/1-D return shapes. In effect, the Drying side likely needs the equivalent of latent_heat[:, self.idx_volatiles] for the multi-node/full-component case.

Suggested acceptance coverage for #101:

• VaporPhase.getHeatVaporization(temp_array, basis="mass") preserves (num_nodes, num_components) and leaves supercritical latent-heat columns at zero.
• A Drying coverage case uses num_nodes != num_volatiles with a supercritical carrier, and proves energy_balance consumes only volatile latent-heat columns.

This is intentionally not folded into #48/#116: #48/#116 are about molar-to-mass drying-rate basis in energy terms; this issue owns the latent-heat shape/provider contract and the associated Drying consumer audit.