chmarti1 / pyromat

PYroMat thermodynamic properties in Python

PYroMat

Thermodynamic tools for Python

Originally authored by Chris Martin [email protected]
Now co-authored by Joe Ranalli

PYroMat is a flexible platform for conveniently working with thermodynamic data. The expanding collection of substances includes data for the properties people need most, exposed in an intuitively designed object interface Come read more.

Installation from the Python Package Index

If you have pip installed, you can install PYroMat with a single command.

$ pip install pyromat 

If you are upgrading, you can always use

$ pip install pyromat --upgrade

Some of you will want to specify the version of python being used (e.g. on many flavors of Linux)

$ python3 -m pip install pyromat

Getting started

>>> import pyromat as pm
>>> O2 = pm.get('ig.O2')
>>> h = O2.h(492,1.01)  # enthalpy at 492K, 1.01bar
>>> pm.info('ig.O2')     # where did these data come from?
>>> pm.config['unit_pressure'] = 'psi'  # Don't like working in bar?
>>> help(pm.search)		# How do I look for more substances?

To get up and running quickly, see the Introductory Tutorial. For detailed documentaiton, see the PYroMat User and Developer Handbook.

Contributing

As an open source project, PYroMat appreciates the participation and engagement of community members.

If you think you've found a bug, please first search in Issues. If you can't find your bug, feel free to open a new issue where we will discuss how to resolve the problem.

If you have an idea for a new feature, we'd love to hear from you! Many of PYroMat's features came from user requests. Please feel free to open an new Discussion or open a new Issue. You can even Email Me - I always enjoy hearing from users.

If you wish to contribute by resolving an open issue, please fork the respository as described in the Github Guide. Please see the full documentation in the handbook for details of the code structure. Even if your code isn't pulled verbatim, a number of issues have been resolved from user-inspired solutions.

To run development tests found in the src/test directory, you can install with the "development" option, which requires the pytest package.

python -m pip install pyromat[dev]

Please be aware:

• PYroMat DOES NOT COME WITH A WARRANTY. Tests help make the code better, and we work hard to make the code as reliable as we can, but users should always skeptically evaluate these models to ensure they are suitable for their application. I've never met the test suite yet that catches all errors.
• The behavior and design of the testing suite is not documented. Unlike the rest of PYroMat, it is subject to change without notice.
• Users coding their own models will need to construct their own validation data from original sources.

License

Copyright (c) 2015-2022 Christopher R. Martin

PYroMat is released under the GNU General Public License v3.0.

This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

pyromat's Issues

Example doesn't work

Hello there,
I am having the following issue
"""
s = O2.s(T,p)
Traceback (most recent call last):
File "", line 1, in
File "/usr/local/lib/python3.9/site-packages/pyromat/registry/ig2.py", line 821, in s
out = self._s(T,p)[0] - pm.units.const_Ru * np.log(p/self.data['pref'])
File "/usr/local/lib/python3.9/site-packages/pyromat/registry/ig2.py", line 645, in _s
if diff:
ValueError: The truth value of an array with more than one element is ambiguous. Use a.any() or a.all()
"""
when running the example
"""
import numpy as np
import pyromat as pm
O2 = pm.get('ig.O2')
T = np.linspace(300.,2000.,101)
p = np.linspace(1.,100.,101)
s = O2.s(T, p)
"""
.... it seems to me that the method _s takes as second a argument a boolean and not an array....
Many thanks for any help !

Bugs in mp1.d_s

Some weird behaviors in mp1.d_s

First, when seeking values above the critical point:

import pyromat as pm

pm.config['unit_pressure'] = 'MPa'
F = pm.get('mp.H2O')

F.d_s(T=1209.35, s=5.5)  # Should yield around 580.555 kg/m3
# Raises PMParamError: _HYBRID1: At least one max/min value does not bracket a solution!

When seeking values below the critical point but not requesting the quality be returned:

import pyromat as pm

pm.config['unit_pressure'] = 'MPa'
F = pm.get('mp.H2O')

F.d_s(T=500, s=5.5)
# Raises UnboundLocalError: local variable 'x' referenced before assignment

Bugfix Pull Request incoming

Typo bug in igmix.py

Call in igmix.py should be pm.units.temperature_scale()

Pressure inverse property routines for igmix

Why doesn't the igmix class have the inverse methods p_s and p_d (which ig does have)? Wouldn't this work in the same way as _invT, or am I missing some details from thermodynamics?

[Review] Example for pyromat.info() in docs does not work

In the README, the following example is given:

>>> import pyromat as pm
>>> O2 = pm.get('ig.O2')
>>> h = O2.h(492,1.01)  # enthalpy at 492K, 1.01bar
>>> pm.info('O2')     # where did these data come from?
>>> pm.config['unit_pressure'] = 'psi'  # Don't like working in bar?

However, attempting the info() function with pyromat 2.2.1, I get an error:

PM ERR: No substanced named "O2" was found in the loaded data.
---------------------------------------------------------------------------
PMParamError                              Traceback (most recent call last)
Input In [19], in <cell line: 1>()
----> 1 pm.info('O2')

File ~/miniconda3/envs/romat/lib/python3.9/site-packages/pyromat/__init__.py:275, in info(members, target, **kwarg)
    273     members = [members]
    274 elif isinstance(members, str):
--> 275     members = [get(members)]
    277 # If operating verbosely, we'll need to print to stdout
    278 if target is None:

File ~/miniconda3/envs/romat/lib/python3.9/site-packages/pyromat/__init__.py:81, in get(idstr)
     79 if out is None:
     80     utility.print_error('No substanced named "' + str(idstr) + '" was found in the loaded data.')
---> 81     raise utility.PMParamError('Invalid substance ID string')
     82 return out

PMParamError: Invalid substance ID string

This is resolved if the phase is included (i.e. by running pm.info("ig.O2")).

Please change the README to reflect proper usage of the info() function, or else change info() to enable functionality without specifying phase information.

[Review] LICENSE file does not contain actual license text

Very small issue: License.txt makes reference to the GPLv3 license but does not actually reproduce the text. For acceptance into JOSS, the contents of the license should actually be provided (see here).

Convergence failure with high densities

In version 2.2.1 and probably before, there are some multi-phase models (like N2 and CO2) that fail to converge at low temperatures and very high pressures. The minimum,maximum density limits contained in the multi-phase dlim data element are not used by the front end, but they are used to establish iteration boundaries in the back-end. A standard value of 1600kg/m3 was set when developing for steam, and it was kept by default when expanding to other substances. Through an oversight, it was never re-evaluated for other substances, so certain high-pressure, low-temperature conditions are not currently accessible even though they should be. It wasn't caught in development because most validating data sets provided by the original model authors do not include data at the extrema - the focus is usually near the critical point and the phase transitions.

This will be fixed in a future release, but in the meantime, users can quickly fix this themselves if it becomes a problem. Users can manually overwrite the loaded data (this is not permanent). In this example, we reset the maximum density to be 2000kg/m3.

import pyromat as pm
co2 = pm.get('mp.CO2')
>>> co2.h(T=190., p=7900.)
... raises an error ...
>>> co2.data['dlim'] = [0., 2000.]
>>> co2.h(T=190., p=7900.)
array([-64.1399237])

Proposal: unit confusion with default p&T

I know this came up before in #29 and elsewhere. The documentation is correct at this point, so there's no bug, and please just mark this "wont fix" and close if you like.

I'm opening it though to make a proposal after I was looking at what we'd have to do to implement default value conversions for PMGI. My proposal is simple I think:

Add a pm.config['def_T_units'] and pm.config['def_p_units'] config value. This would enable building conversions based on those into all the _argparse methods and others that load default values.

Advantage: this kind of recasts def_T and def_p as a standard state (which in this case defaults to 25 deg C, 1 atm) instead of just being fixed numeric values. If calcs that use standard states (e.g. enthalpy of formation) ever become part of the library, that concept may have actual uses and so this may future proof. In terms of strict user experience though, I think it's reasonable to expect that users digging deep enough to change default p&T value settings could also update the corresponding unit flag.

Enhancement: Joule Thomson coefficient Addition

We know for ideal gases JT coeff is zero; but can we add this parameter or somehow calculate it?

Important for HVAC community.

It is possible to express the Joule-Thomson coefficient in terms of measurable properties

https://chem.libretexts.org/Bookshelves/Physical_and_Theoretical_Chemistry_Textbook_Maps/Physical_Chemistry_(Fleming)/04:_Putting_the_First_Law_to_Work/4.05:_The_Joule-Thomson_Effect

[Review] Insert citation to NumPy in Paper

Hi @jranalli and @chmarti1,

since the package depends on NumPy, you could insert a citation here, see: https://numpy.org/citing-numpy/.

PYroMat/joss2022/paper.md

Line 101 in ffe8f45

Using the Numpy library for compiled back-end numerical efficiency, `PYroMat` has been designed to efficiently handle large arrays of input data. The iterative back-end operations on hundred-thousand-element arrays consistently execute in a few seconds on a single core of an old laptop.

running the rankine.py demo

I've pip installed PYroMat 2.1.3, but can't get to run the rankine cycle demo at http://www.pyromat.org/src/rankine.py . I get the error

'pyromat.utility.PMParamError: Saturation temperature and pressure cannot be simultaneously specified'

and it seems to have something to do with the line

h1,h5 = steam.hs(p=p1,T=T1) # these are faster with T and p

in the file.

Test code breaks on d_s()

The test code breaks on mp1.d_s() now that I have reverted back to version 2.1.10 call signatures. It tries to pass pressure as an argument, but that was not originally supported. I'd recommend that we simply stop testing these deprecated functions. Unless there are community-raised issues with them, we shouldn't need to touch them again.

Bugs in igmix

When passing density as a parameter in the functions for enthalpy, entropy and internal energy

air = pm.get('ig.air')  
pm.config['unit_temperature'] = 'C'  
pm.config['unit_pressure'] = 'kPa'
d0 = air.d(T=298.15, p=101.325)
air.s(T=300,d=d0)

The following error is raised.

`KeyError                                  Traceback (most recent call last)
<ipython-input-37-ffa8537a3566> in <module>
      3 pm.config['unit_pressure'] = 'kPa'
      4 d0 = air.d(T=298.15, p=101.325)
----> 5 air.s(T=300,d=d0)

c:\python38\lib\site-packages\pyromat\registry\igmix.py in s(self, *varg, **kwarg)
    678 """
    679         self._bootstrap()
--> 680         T,p = self._argparse(*varg, temperature=True, pressure=True, **kwarg)
    681         s = self._s(T)[0] - pm.units.const_Ru * np.log(p/(1e5*self._pref_bar))
    682         pm.units.energy(s, from_units='kJ', inplace=True)

c:\python38\lib\site-packages\pyromat\registry\igmix.py in _argparse(self, T, p, d, temperature, pressure, density)
    209 
    210         if d is not None:
--> 211             d = pm.units.matter(np.asarray(d,dtype=float), self.data['mw'], to_units='kmol')
    212             pm.units.volume(d, to_units='m3', exponent=-1, inplace=True)
    213             if d.ndim==0:

KeyError: 'mw'

When trying to use igmix.gam, igmix.cp or igmix.cv:

air.s(T=300,d=d0)

AttributeError                            Traceback (most recent call last)
<ipython-input-60-6447cf26e838> in <module>
      2 pm.config['unit_temperature'] = 'C'
      3 pm.config['unit_pressure'] = 'kPa'
----> 4 d0 = air.cp(T=298.15, p=101.325)
      5 air.s(T=300,d=d0)

c:\python38\lib\site-packages\pyromat\registry\igmix.py in cp(self, *varg, **kwarg)
    544 Returns:    Spec. Heat  [unit_energy / unit_temperature / unit_matter]
    545 """
--> 546         self._boostrap()
    547         # Parse the arguments to isolate temperature in K
    548         T = self._argparse(*varg, temperature=True, **kwarg)

AttributeError: 'igmix' object has no attribute '_boostrap'

Bug in mp1.hsd()

Observed a crash in mp1.hsd(). Crash occurs because it attempts to combine arrays of different sizes, since parts of the calculation are not properly indexed.

Minimal code to demonstrate the crash:

import pyromat as pm
h2o = pm.get('mp.H2O')
h2o.hsd(p=[1.611654e-2, 2.8095e-2], d=[999.056])

Fix is easy affecting lines 3080 and 3081 of mp1.py, pull request incoming.

pm.units.show() function not working

Dear Christopher, when trying to use the pm.units.show() function, the function is not working correctly, returning an AttributeError: 'dict' object has no attribute 'iteritems' Regards.

how to get for different phases

forgive me, i'm unclear how to get the values for the enthalpy and entropy of liquid states, for instance, from the ig table. to solve problems like, calculate the enthalpy and entropy for the following reactions:

H2O(l) -> H2O(g)
or
2HCl(g) + Pb(s) -> PbCl2(s) + H2(g)

thank you in advance, lucas

Small errors near critical point

There is a bug in the multi-phase class that causes small deviations (about 0.5%) in specific heats near the critical point. It will be corrected in the next release.

Feature Suggestion

Just wanted to say: Pretty cool library. I'm coming from EES and need something that can handle matrices/arrays better, which is why I'm using Python, but I think this library could benefit from:

.v() method for getting specific volume. I know you can just do 1/air.d(), but I would think this would be fairly simple to add.

There is a problem with temperature-entalpy with air as ideal gas

I am testing the property values on different fluids. so far, i have seen an error with the values

Context => suppose I want to find the enthalpy of air in KJ/kg at 300K

import pyromat as pm

air = pm.get("ig.air")
T_1 = 300 #Kelvin
h_1 = air.h(T=T_1)

The result of this operation is -2.407 KJ/Kg

I made the same in the website

Compared to other guide tables as Yinus Cengel

[Review] Suggestion for the paper and a few typos I found going through the online documentation

Hi,

Paper

• PYroMat/joss2022/paper.md

  Line 101 in ffe8f45

  Using the Numpy library for compiled back-end numerical efficiency, `PYroMat` has been designed to efficiently handle large arrays of input data. The iterative back-end operations on hundred-thousand-element arrays consistently execute in a few seconds on a single core of an old laptop.

  
  I suggest you are either a little bit more specific about the system (single core of an old laptop) or just remove that last part of the sentence.

Online Documentation

• See chmarti1/pyrodoc#4

ideal gas Cp discontinuities

There 121 (out of 390) ideal gas data sets that have jumps in specific heat at the piece-wise boundaries. As a result, the data fail the built-in ig class data integrity check (see test2.log and test3.log), but the data actually agree with the NIST webbook. The NIST website shows the same discontinuities. The data were either originally formulated to tolerate a jump condition, or there is an error in the original source data.

PYROMAT: SO2 - ideal gas behavior

Hi. I'm an engineering student from Brazil and I'm implementing in Python an EES program from my Professor. While working with SO2 entropy and enthalpy I noticed a big difference between EES and Pyromat values. Initially I thought it was a reference state difference, but while analyzing the delta between two different temperatures these differences persisted. I worked with CO2, H2O, N2, O2 and for these compounds Pyromat is the same as EES to enthalpy and entropy values (for delta T and individual values), only SO2 doesn't yield the same values as EES. I will be grateful if you can help me.

Thank you very much in advance.
Best regards

Custom gas mixture

Hello,
Is it possible to create custom gas mixture from existing 'ig' given the molar or mass ratio of the diffrent species ?
Or is the igmix restricted to the predefined mixtures from the aatabase?

thank you in advance,
Mahmoud

Python package index excludes ideal gas mixtures

The igmix data (including ig.air) is missing from the python package index's copy of the v2.1.0 package. This is due to an error in setup.py or MANIFEST.in that was not noticed in testing.

Numerical iteration chokes on non-monotonic functions.

I encountered two example test cases where we get iteration/bracketing issues due to the function we're iterating becoming non-monotonic at the conditions of interest. This means there will always be multiple possible solutions, which is a difficult problem to fix period, but right now they're not even reporting a possible answer because they choke on the bracketing.

Here if we call things based on entropy

sub = pm.get('mp.CH4')
ref = sub.d(T=223, s=-5.529)   # should be legit, 
# value expected is around 460 based on the forward calculation with p=2475 & T=223

The underlying codes do an iteration of _s based on density. Plotting _s(d, T) reveals that two possible density values correspond to the target entropy and so the iteration code breaks.

Here's a similar test condition that results from _p(T, d)

sub = pm.get('mp.N2')
sub.T(p=1.6e4, d=1355)  # errors out, should come out to be around 68

Default pressure does not obey units

Hi, apologies in advance if this is not the correct place to ask this or if this is a stupid user error rather than an actual bug (I am very new to PyroMat).

I have modified my config.py file to set unit_pressure = 'Pa' rather than bar and this works well with one exception. If I run the pressure method with no arguments, e.g. air.p() I get the result in bar still rather than Pascals: array([1.01325]). Running it with named arguments, however, air.p(T=300, d=1.225) returns Pascals as expected: array([105491.85213083]). This does not seem to be the case for the default enthalpy when I change the energy units from kJ to J and it reports the enthalpy in J as expected.

Am I missing something obvious?

Thanks!

[Review] Include `extra_requires` in setup.py

Something like

...
    extras_require={
        'dev': [
            'pytest',
        ]
    },
...

is very useful in my opinion, so people can install pip install pyromat[dev] or pip install -e .[dev] if they want to have all requirements for the development process as well.

[Review] Default unit converters for time are incorrect in subsecond range

Following the logic of the length converters

PYroMat/src/pyromat/units.py

Lines 277 to 281 in d65cb2c

	'cm':.01, # Centimeter
	'mm':1e-3, # Millimeter
	'um':1e-6, # Micrometer
	'nm':1e-9, # Nanometer
	'A':1e-10, # Angstrom

, the time converts for subsecond time should be with a negative power, or?

PYroMat/src/pyromat/units.py

Lines 292 to 294 in d65cb2c

	'ns':1e9, # Nanosecond
	'us':1e6, # Microsecond
	'ms':1000., # Millisecond

I unfortunately did not yet find a way to test it myself, that's why I opened the issue.

Sometimes state() can return NaN while leaving -1 in the quality array, which can be confusing.

One of our old documented bugs that was deemed to be a fix that should be handled later. Just migrating it here in github for better workflow now that 2.2 was released.

TestCode

w = pm.get('mp.H2O')

h = [1694.095, 4372, 4373]  # kJ/kg
p = [5, 100, 1000]  # bar
ans = w.state(h=h, p=p)  # expect ans['x'] = [0.5, -1, np.nan]

Former reply: The “right” way to handle this is to have _argparse maintain a separate index array that points to all out-of-bounds indices while it’s working. Then, at the final step, it should force NaN on all of those indices to all results. The tidiest way to do this would be to modify the _argparse structure so that there is only one return line and to modify _hybrid1 to return an out-of-bounds index list. I'm willing to do that, but I’d like to leave it for a later revision.

Issue in numerical backend for _T() under certain multiphase conditions

Ok, I'm moving this discussion here because it's going to benefit from some conversation that shows code.

I've found a few cases where we are unable to calculate multiphase p&d properties, because of bracketing errors on the numerical inversion routines.

Here are two cases that fail:

sub = pm.get('mp.H2O')
p = 2497
d = 525
T = sub.T(p=p, d=d)  # expect 1026.xxx, get bracket error

p = 2497
d = 1090
T = sub.T(p=p, d=d)  # expect 291.xxx, get bracket error

The issue occurs because of code within the function mp1._T(), which uses _hybrid1() to compute an inversion seeking the temperature of interest using _p(T, d). For supercritical pressures, on line 2115 it calculates the limits for that inversion as the upper and lower limits of the temperature for the substance.

Because we're supercritical, there are cases where the target density will be under the dome if we really evaluate at the lowest possible temperature, and according to the documentation, _p() doesn't produce valid results under the dome. My observation for the first test case is that the reported value from _p(T=Tmin, d=525) is ridiculous and on the order of 10^20. So that's why we get a bracket error.

You may have expertise that can provide a different/better fix, but I've pushed one viable solution to my working branch. Basically, I'm computing new lower temperature limits for the _hybrid1() iteration that are based on temperature at which our density intersects the dome (if it does). Computing that value of ds requires its own inversion though and is therefore expensive. So I made it conditional on the return, such that it only tries the fix after we've already gotten a bracket error. See this commit.

I haven't exhaustively tested this out yet, but it does solve the problem for all of the individual conditions I've tested for water. It needs to be run on arrays and other substances before we can be sure.

Here's the test code I ran against for now pending further discussion:

import pyromat as pm
sub = pm.get('mp.H2O')
print(sub.T(p=2497, d=525))   # errors with the old method, works with the new, expect around 1026
print(sub.T(p=2497, d=1090))  # density doesn't intersect the dome, should work for old or new method, expect around 291
print(sub.T(p=2497, d=1100))  # really out of range, sub.d(p=2497, T=Tmin is around 1097), expect errors

Problems with mp1.hsd

These two calls produce different results for h (and s and d too).
steam.h(p=400,x=0.25)
and
steam.hsd(p=400,x=0.25)

Feature Suggestion: Suppress stdout display within config

I'd propose that you add a config option config['reg_printerror'] or similar to allow suppression of pm.utility.print_error and pm.utility.print_warn output to the stdout. Those outputs are helpful when doing command line programming, but can be an obstacle to try: except: structures meant to handle the error.

Example: To generate a constant entropy line on a pv diagram, you pass a list of pressures at a fixed entropy to T_s(p=p, s=s). There are some conditions where the list of pressures would make T exceed the maximum allowable T, so you could use a try: except pm.utility.PMParamError: structure to catch the error and retry with a limited pressure range in that case. It's useful not to have the error hit the stdout, since it's being handled. This is especially true when we're doing this for cgi figures in pyrodoc, where the stdout is generating useful code/image data.

S2 gives invalid values

There calls to diatomic sulfur (S2) properties return strange results. The data appear to be corrupt at the phase transition point (882.117 Kelvin). It isn't clear where the source of the error is. This error will be addressed in new releases.

Multi-phase specific heats

Multi-phase specific heats currently return nonsense values for states under the dome. This is not technically a bug, but it is not proper behavior. This is an accidental artifact from when the code was originally being developed. Placeholder calculations were added and never removed. This behavior will be changed in the next release.

Numerics iteration boundary issue in ._d()

Similar to issue #43, initial guesses for certain cases end up being unacceptable for generating the initial iterations. A few test cases for _d() are:

sub = pm.get('mp.CH4')
print(sub.d(p=0.11707696, T=624.375)) # T supercritical, p low
print(sub.d(p=9999.0, T=624.375)) # T&p supercritical

What I found here is that at high temperatures and various pressures, you get insane pressures at the high density boundary and it screws up the initiation of the iteration. You need better guesses of the possible limiting densities.

Temperature above the dome, and pressure below can use the critical density as a lower limit. The lower limit for both supercritical is harder to come by and I don't have a perfect suggestion there.

Suggestion: functionality in mp1 for returning a string of the phase

This is potentially a wormhole, but I think it might be useful to have a function that computes the phase for multiphase substances, and/or make it an option to have the string return from the quality function. It is of course easy to determine for yourself, but requires several calls back to pyromat after you get a quality of -1.

It also occurred to me that this might be useful if you ever need to case out certain types of iteration algorithms. For example, fixing state properties given T & h is hard outside the steam dome, but trivial underneath. Whether there are cases where knowing liq vs gas vs supercritical can be useful to the numerical approaches I can't say off the top of my head, but it seems possible. One thing that does come to mind is that you'd expect finding things as a function of T&d to be stiff in the liquid region due to incompressibility, so maybe knowing that would help determine expected uncertainty/accuracy in that region?

Even if it doesn't provide anything for casing out other operations, I can say that it is definitely useful pedagogically.

Literal verbose flag in mp1.py

It looks like while debugging, you left a verbose flag set to True, because it's outputting unnecessarily:

mp1.py line 2111 param={'fn':self._p, 'd':d}, verbose=True)

Custom units ignored by igmix

In 2.1.10,

import pyromat as pm
pm.config["unit_molar"] = "mol"
o2 = pm.get("ig.O2")
o2.mw()

yields 0.032 kg/mol, which is correct. However:

air = pm.get("ig.air")
air.mw()

yields 28964 which is the correct numerical value, but seems to be in units of g/kmol. This is even more confusing, because pm.config["unit_mass"] indicates kg as the unit used.

So far I've been using 2.0.12, where this wasn't a problem. Just now, I upgraded to the latest version of pyromat, and this problem appeared.

Another bracketing issue

Getting some bracketing errors in the supercritical region. Here's some sample code:

import pyromat as pm

pm.config['unit_pressure'] = 'MPa'

water = pm.get('mp.H2O')
#  d works
d = water.d(p=25, T = 650)  # yield 488.840
#  p works
d = water.p(T=650, d=488.840)  # yield 24.999...
# T fails
T = water.T(p=25, d=488.840)  # raise PMParamError

Bug in cp(), cv(), and gam()

I tried calling air.cp(), air.cv(), and gam(), but found that the "bootstrap" method had a typo:

`AttributeError Traceback (most recent call last)
~\AppData\Local\Temp/ipykernel_16868/1963525599.py in
----> 1 air.cp()

C:\ProgramData\Anaconda3\lib\site-packages\pyromat\registry\igmix.py in cp(self, *varg, **kwarg)
544 Returns: Spec. Heat [unit_energy / unit_temperature / unit_matter]
545 """
--> 546 self._boostrap()
547 # Parse the arguments to isolate temperature in K
548 T = self._argparse(*varg, temperature=True, **kwarg)

AttributeError: 'igmix' object has no attribute '_boostrap'`

Anaconda

Hello,
Thanks for this great package.
Is there an easy way to install pyromane with anaconda ?
Cheers

air.T_s claims temperature out-of-bounds when using reverse values from air.s

import pyromat as pm
air = pm.get("ig.air")
s = air.s(250,1)
air.T_s(s,1)

should result in 250, but raises the following error: PMParamError: All of the specified states were out-of-bounds. Legal temperatures for ig.air are between 200.0 and 6000.0 Kelvin.

ig2 class breaks igmix

The creation of the ig2 class in the alpha branch has broken the igmix class. Ideally, ig and igmix should be updated to be compatible with the new interface.

Enthalpy of formation for Acetylene

Dear Christopher, when calculating the enthalpy of formation for Acetylene (C2H2), it returns a value of 414,785.804. This value is different to the value that is shown in other literatures of 226,730 kJ/kmol.

C2H2 = pm.get("ig.C2H2")
C2H2.h(T=25+273.15)*C2H2.mw()

Numerical issue in water saturation routine

Found a case where the numbers go a bit crazy. This is nowhere near the critical point (which is 220 bar). Expected value is around 592 K, which is also not especially near the critical point.

import pyromat as pm
h2o = pm.get('mp.H2O')
h2o.Ts(p=110) # yields nan

Crash in mp1.d_s under certain conditions

Found a crash within d_s. To see the crash, run the following code in version 2.1.8:

import pyromat as pm
import numpy as np

h2o = pm.get('mp.H2O')

s = 8
T = np.linspace(275, 1270, 50)
d = h2o.d_s(T=T, s=s)

Basically, it happens because of an indexing bug within mp1.py in the d_s routine when the index I is not uniformly true, leading to different size for s_ on line 3479 and I. The fix is to change the following two lines to just reference s_ instead of s_[I].

3488     s_ = self._s(T=T[I], d=da[I])[0]
3489     I[I] = s_ < s[I]

Add properties method

We should add class-specific properties() method that lists the supported input and output property strings. This is useful for applications to dynamically probe substance models to see which properties are available.

[Review] Repo/Docs are missing some guidelines for contribution

Especially for less experienced git users and new developers, who want to contribute to your project, it would be very helpful to have short section in the GitHub repo and/or the documentation with information on

• how and where (e.g. have some module overview) to make changes in the source code and open pull requests,
• how to run the software tests (kind of related to #66) and
• code style and code documentation guidelines.

Inverse routines do not convert units

In version 2.2.2, the inverse routines like T_h, T_s, and p_s do not convert the units of the results. They always return their results in the native units of the model. For temperature, that is always Kelvin, but for pressure it could be bar or Pa. This is a bug and not the documented behavior.

The Problem
As of version 2.2.0, the inverse methods are simply wrapper functions around the new argument parsing system. They are deprecated in favor of calling property methods directly (e.g. T(s=s, p=p) instead of T_s(s=s, p=p)). We've had a couple of bumps (see issue #52) caused by implementing these wrappers without sufficient caution for the number of ways they can break.

The Fix
There is already a plan to release version 2.2.3, in which this issue will be addressed, but users can address the issue right away by transitioning to the new property interface in favor of the old inverse routines. The new argument parsing system will accept combinations of entropy, enthalpy, density, specific volume, temperature, pressure, and quality.

Import error on pyromat.aps.cycle

Import error on calling

import pyromat.aps.cycle

It complains about the call from the aps.__init__.py

PYroMat/src/pyromat/aps/__init__.py

Line 1 in 7e3d5d2

import cycle

ModuleNotFoundError: No module named 'cycle'

I admittedly am horrible at python packaging but I tried every permutation of the cycle import I could and get errors no matter what. I think there's something wrong with the namespace there. On a test copy, I removed the import in aps.__init__.py and it works, but that may not be the namespace you were trying to create.