Comments (5)
This is an interesting idea. If I understand the idea correctly, you are proposing methods that are specially constructed to deal with the special cases that the properties are under the dome.
As I think about it, I don't think a special function needs to be constructed. In theory, this should already be handled by the new _argparse() algorithm in version 2.2.0. In all of the test cases so far, T,h crashes because it is not well numerically (or theoretically) conditioned. However, you make a good point that it is numerically trivial under the dome. So far, my tests with T,h specified under the dome also fail in the working branch. I'll look more closely to see if we can just write this in.
from pyromat.
I guess I rambled, but it's kind of a two-part idea.
I think substance.phase()
that returns a string or ENUM value of the phase would be useful for a variety of purposes.
A separate idea, but one such purpose is adapting numerical conditioning for special cases of substance pairs, such as under-dome properties. There are certainly other ways to tackle that though.
from pyromat.
For a phase() property, there was a 2011 paper [1] that I've seen cited as proposing a "phase identification parameter" that uses partial derivatives w.r.t. T,v, and p. I have never read the original paper, but adding it as an available property would be one interesting way to satisfy the proposal. Fundamentally, the problem is that the boundary between the super-heated/-cooled regions and super-critical region is not clearly defined. Whatever choice one makes, it winds up being somewhat arbitrary.
I can confirm that _argparse already cases out properties under the dome just like you suggest, but for some reason it really doesn't like T,h - even under the dome. I'll dig in and figure it out.
[1] Venkatarathnam et al. Fluid Phase Equilibria, v301, pg225 2011.
from pyromat.
So I was thinking of liquid, vapor, mixture, supercritical categories. Textbooks and articles seem to define supercritical as both pressure and temperature exceeding the critical values, so there is a basis for using that as the boundary and skipping out on dealing with anything more detailed beyond that.
I skimmed the paper you mentioned and their specific motivation is in dealing with finding the phase for mixtures, where saturation properties are difficult to compute. They seem to suggest that if saturation properties are available, that's the typical method:
The identification of the vapor or liquid phase of a fluid is straightforward when the saturation properties are known.
The appendix of that reference does provide an implementation of the method, provided you can formulate your equation of state into their generic form. But since your current implementation of mp1 can unambiguously compute the steam dome, maybe just using the saturation props would be easier.
from pyromat.
I've found and corrected the problem in the working code for v2.2.0 that prevented specifying T,h under the dome. There was a typo in the new _argparse() method that caused it to always use entropy as the inverse property... no matter what.
Specifying (T,h) is theoretically sound in liquid and saturated cases. I've tested both for H2O, and they both converge correctly.
I'm going to punt for now on the phase() property. After a major code release, we usually have small fixes / adjustments in the next months. If we decide to, we can always add it there.
from pyromat.
Related Issues (20)
- Add properties method HOT 1
- air.T_s claims temperature out-of-bounds when using reverse values from air.s HOT 4
- [Review] LICENSE file does not contain actual license text HOT 1
- [Review] Example for pyromat.info() in docs does not work HOT 1
- [Review] Suggestion for the paper and a few typos I found going through the online documentation HOT 2
- [Review] Default unit converters for time are incorrect in subsecond range HOT 7
- [Review] Insert citation to NumPy in Paper HOT 1
- Inverse routines do not convert units HOT 1
- [Review] Repo/Docs are missing some guidelines for contribution HOT 1
- [Review] Include `extra_requires` in setup.py
- Proposal: unit confusion with default p&T HOT 3
- Test code breaks on d_s()
- Enhancement: Joule Thomson coefficient Addition HOT 6
- There is a problem with temperature-entalpy with air as ideal gas HOT 5
- Discussion: Error Codes HOT 2
- Create a state class HOT 2
- Easily capable to handle a simple inverse arg case for Ideal Gases HOT 3
- Code from Live-Page of PYroMat HOT 2
- Error in R1234ze Saturation Density
- General Inverse Property Lookup Functionality
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from pyromat.