More rigorous treatment of extensive states#330
Merged
prehner merged 2 commits intodevelopmentfrom Feb 14, 2026
Merged
Conversation
3569089 to
421a92e
Compare
7bca649 to
76a6c90
Compare
7cb43ee to
0831756
Compare
13d6ac6 to
711b625
Compare
2b9f8e4 to
ad2ae46
Compare
ad2ae46 to
7a5d4ff
Compare
89bf0bd to
03ea575
Compare
03ea575 to
8234c31
Compare
8234c31 to
6577305
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is something I wanted to improve on since running into some issues in phase equilibrium algorithms. The core ideas:
I actually tried to do this at compile-time, which worked and actually helped a lot identifying all problems that would only be visible in run-time now. However, having yet another generic parameter to ultimately avoid some errors in edge cases is simply not worth it.
total_molesis anOptionnowThe key for evaluating extensive properties is
All state methods for extensive properties have to call this method and therefore have a
Resultas return value. This has almost no impact on phase equilibrium solvers because those should not depend on the size of the system (there is a small inconsistency in the stability analysis here, which I wasn't able to fix immediately). Some previous fields ofStateare now getters instead (volume,moles,partial_density).The field
total_moles: Option<Moles<D>>is set depending on the inputs with which the state is created. This is done via theCompositiontrait.The
Compositiontraitstate creations that need the full composition (only NVT and NVU) will err if the composition does not provide the total moles.
The
Compositiontrait is implemented for the following structs:()Molesf64OVector<f64,N>&OVector<f64,N>OVector<f64,N-1>Dynonly&OVector<f64,N-1>DynonlyMoles<OVector<f64,N>>&Moles<OVector<f64,N>>This gives the opportunity to organize the state creator methods a bit. The following methods are now implemented:
With a lot of the logic being moved to the new traits, the use cases for the
StateBuilderdwindle and I suggest to remove it.Changes to
PhaseEquilibriumTo be more rigorous in the handling of extensive multi-phase states, the
PhaseEquilibriumstruct was adapted accordingly:The addition of
phase_fractionsenables the calculation of properties like molar enthalpies or entropies without relying on the total moles in each state. To evaluate extensive properties, the total moles of the entire multi-phase state are stored separately analogously to how it is implemented inState. Thetotal_moleswithin thestatesshould not be touched anymore when the states are part of aPhaseEquilibrium, however, there is currently nothing stopping people from simply doing so. (This would be possible to enforce, if the extensivity of the states were done on the type level, but as mentioned above, that is a bit unnecessarily complex)