Error in water Cp

[agzijlstra]

There seems to be an error in class-handling as instances are clearly not independent. When repeating calculation of Cp of water for example, the same command gives different results:

The first is correct, the second and third clearly not!

[tedhyu]

Hi: This is an interesting issue. I took a look at this, and this is what I saw. It looks like the program remembers the previous method used and no longer ranks it.

1) For water_Cp, at 300, the method used is 'Zabransky spline, constant-pressure'. This is the highest ranked method. This calculates the correct Cp.

2) For water_Cp_2, the temperature is at 250 which would make it ice, but Cpl determines the heat capacity of a liquid. 'Zabransky spline, constant-pressure' is not valid at this temperature and the highest ranked method is 'Dadgostar and Shaw (2011)', which calculates an incorrect heat capacity.

3) water_Cp_3 is the problem. It retains the highest ranked method of Dagostar and Shaw. This is due to a part of the code called: "Optimistic Track".

Here is the code for it:

Optimistic track, with the already set method

    #if self.method:
        # retest within range
    #    if self.test_method_validity(T, self.method):
    #        try:
    #            prop = self.calculate(T, self.method)
    #            if self.test_property_validity(prop):
    #                return prop
    #        except:  # pragma: no cover
    #            pass

1) if self.method: #It sees there is an existing method "Dagostar" 2) self.test_method_validity(T, self.method) #It tests if the method is valid at the temperature of 300, which it is. 3) return self.calculate(T, self.method) #Since it's valid, it will return the Cpl at 300 using Dagostar which is not the highest ranked method at 300.

The optimistic track seems to be overwriting the ranking method at 300. If I comment it out, the results for water_Cp_3 will be correct

[CalebBell]

Hi all, That particular cache is one of the worst decisions I've made. It severely hindered my development of the library and also made me not want to work on those TDependentProperty objects at all.

The new Thermo update resolve the issue. Thermo won't try to switch between methods anymore, it will just use the selected method, and perform configurable extrapolation when outside of bounds.

I'm very sorry I wrote the code this way originally. The only consolation you will find is that it has very likely caused me much more pain than you.

Sincerely, Caleb