Tabular backends and phase specification

[jowr]

I know that the tables can yields "wrong" results for inputs close to saturation. I tried to circumvent this by specifying the phase because I know the phase for all calls beforehand. Unfortunately, this does not seem to make a difference. This could be related to #739 and #656

Is that a correct observation? Do we have plans about implementing such functionality?

[ibell]

What inputs? That's not a bad idea, to make sure you get the right phase
if phase is imposed
On Nov 26, 2015 5:41 AM, "Jorrit Wronski" notifications@github.com wrote:

I know that the tables can yields "wrong" results for inputs close to
saturation. I tried to circumvent this by specifying the phase because I
know the phase for all calls beforehand. Unfortunately, this does not seem
to make a difference. This could be related to #739
#739 and #656
#656

Is that a correct observation? Do we have plans about implementing such
functionality?

—
Reply to this email directly or view it on GitHub
#882.

[jowr]

Typically, I would use T,p inputs that are very close to saturation and then I impose the phase to tell CoolProp whether I want the results for gas or liquid.

[ibell]

That makes sense to me. I can see that being useful.
On Nov 26, 2015 12:15 PM, "Jorrit Wronski" notifications@github.com wrote:

Typically, I would use T,p inputs that are very close to saturation and
then I impose the phase to tell CoolProp whether I want the results for gas
or liquid.

—
Reply to this email directly or view it on GitHub
#882 (comment).

[mapipolo]

So do I understand correctly that phase specification using AbstractState.specify_phase() is currently ignored for tabular calculations? It doesn't seem to make a difference for me either with QT or TP inputs. This feature would be very useful for me too, and could eliminate the need to fudge the pressure and temperature away from the saturation line to ensure that CoolProp calculates for a gas rather than a mixture (the "fudging" method is not especially reliable).

[ibell]

Phase specification will never be needed or used for QT as that is always
two-phase. PT, on the other hand, could be made much more reliable by
using the specified phase, which would fix the "bumping" issue.
On Nov 30, 2015 8:02 AM, "mapipolo" notifications@github.com wrote:

So do I understand correctly that phase specification using
AbstractState.specify_phase() is currently ignored for tabular
calculations? It doesn't seem to make a difference for me either with QT or
TP inputs. This feature would be very useful for me too, and could
eliminate the need to fudge the pressure and temperature away from the
saturation line to ensure that CoolProp calculates for a gas rather than a
mixture (the "fudging" method is not especially reliable).

—
Reply to this email directly or view it on GitHub
#882 (comment).

[ibell]

This is a little bit complex to implement - I'll have to think about how to resolve the problem. Should be doable though. Should greatly improve the reliability near saturation.

[ibell]

I've made progress in tabular_refactor branch. I merged update functions from TTSE and bicubic into the common backend. Now only have one location to update code. I'm about ready to merge it back in I think.

PT in liquid phase at low temperatures is very difficult - we quickly run out of space to bump to lower temperature, might have to consider using TTSE down there.

[jowr]

I have some time to look at this today and can do some testing. What do you mean by might have to consider using TTSE down there? instead of bicubic?

[ibell]

It seems that in the wedge near triple point pressure and between minimum
temperature and saturation temperature, it is quite often (actually most of
the time) that the algorithm yields an entirely wrong density as function
of t and p. This is because all four nodes must be to left of saturation
curve to yield a truly liquid solution. In vapor phase, this is very
simple to resolve. I think the only way to solve this for liquid near
triple point pressure is to use TTSE rather than bicubic. In this way, you
only need one node in the liquid phase.

Does that make sense?
On Dec 7, 2015 1:44 AM, "Jorrit Wronski" notifications@github.com wrote:

I have some time to look at this today and can do some testing. What do
you mean by might have to consider using TTSE down there? instead of
bicubic?

—
Reply to this email directly or view it on GitHub
#882 (comment).

[jowr]

Yes it does, thanks for the clarification. I'll have a look at it. At a first glance, it looks like the PT-update with imposed phase is not finished is that correct? Did you push all your work?

[ibell]

Sadly, yes, I pushed my work, but I put up a testing script :
0887e37

I haven't fixed the vapor side yet, but that is simple to handle. Same
logic, just bump to the right, which is very simple. I ran out of time
last night when I noticed how hard the liquid side is.

On Mon, Dec 7, 2015 at 2:32 AM, Jorrit Wronski notifications@github.com
wrote:

Yes it does, thanks for the clarification. I'll have a look at it. At a
first glance, it looks like the PT-update with imposed phase is not
finished is that correct? Did you push all your work?

—
Reply to this email directly or view it on GitHub
#882 (comment).