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

[chmarti1]

This is a new problem created by an edit I made in the modifications for v2.2.0. I used to use _tditer() instead of _p(). _tditer() correctly resolves values under the dome, so these weird conditions don't crop up. I'll either transition back to _tditer() or I'll implement a fix to make _p() avoid the issue. _p() is preferred for numerical efficiency. _tditer() is apparently preferred for numerical stability.

[jranalli]

Well, if that's the case, maybe it's worth doing the try/except approach. _hybrid1 definitely handles the vast majority of cases and you can benefit from its efficiency. I only found these via a test code that pointwise crawls the space. So simplest approach for best of both worlds would be something like:

try:
  self._hybrid1(args)
except pm.utility.PMParamError as e:
    self._tditer(args)

Related by not identical issue, these types of cases crop up in the _d() calculation as well. I was able to resolve those as well by changing temperature limits. 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. My fix is uglier this time, but it might at least give you an idea of what kinds of changes I had to do to the iteration limits to make it work out.

Commit here. One part of the fix is to use the critical density as a limit when temperature is above the dome and pressure is below. The other part is to come up with a limit for when both p & T are above the dome. It works to compute the density at Tc & pmax, which would be an expected minimum value, but it results in an ugly recursion and I don't recommend using my exact method there.

[jranalli]

Since I'm documenting other numerics issues here, let me add these as well.

One involves calling 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. But if you plot entropy as a function of density at that temperature you can see that it's got two possible density values that yield the entropy of interest and so your iteration code breaks. Better limits could maybe work here.

Something similar can happen with pressure and temperature for some cases. Here's the test condition

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

Leads to iteration of _p() based on T. Plotting pressure versus temperature shows that at very low temperatures there are two possible values of temperature that correspond to that pressure.

Just to be 100% clear, I'm not trying to nitpick here. I wrote some code to try to span the parameter space for all substances and I'm just diving into the test cases that errored out and trying to provide them so we can figure out what's going on with the numerics. No pressure as these aren't active cases I'm trying to use or anything.

[chmarti1]

Version 2.2.1 corrects the issue. For the time being, I have reverted to _tditer() instead of _p() for the error function. The alternative requires an algorithm to calculate the saturation temperature given the density, so we can establish a minimum temperature that keeps the iteration outside of the dome when the pressure is super-critical. That's really the right way to solve the problem efficiently. Writing that algorithm isn't horribly difficult, but implementing it requires some significant testing. This can remain a goal for the future.