CAPE-OPEN

Thanks for these very useful comments. I fixed the BSTR issues (by always using CComBSTR), and called Initialize and Terminate functions.

I do not use smart pointers for COM objects, but normal pointers initialized to NULL in the class constructor and released in the destructor, because they are class members declared in a .h file in which I do not want to include any COM stuff.

I agree that the difference can result from the solver tolerance. Note that the relative error can be as high as 1e-4 for certain values of p and T:

Computing internal energy and its derivatives:
T 2.704082e+002 p 6.816327e+006 U -2.533797e+005

Computing only internal energy:
T 2.704082e+002 p 6.816327e+006 U -2.534055e+005

Note that Terminate and Release must be done on 'primary PMC objects'. These are the ones you create (e.g. with CoCreateInstance), but also the ones that are created from a 'factory' object. Particularly property packages created by thermo systems or property package managers. Derived objects (parameters and ports of unit operations for example) do not need to be initialized and terminated.

It looks like the error on TEST3 has been fixed after I made the changes you proposed.

I played with TEA properties: it is not the Newton tolerance, but the value of the temperature and pressure perturbation, used to compute derivatives I suppose.

The strange thing is that I can set them to 1e-14 and get machine precision match between tests 1 and 2. I expected a value of about 1e-7 to be optimal.

The perturbation is used for enthalpy in case the approx enthalpy derivative model is not selected. The analytic derivatives for enthalpy require first order derivatives of (d ln Phi / d T) or (d ln gamma / d T) with respect to T, P and X, so second order derivatives of ln Phi and ln gamma. I have implementations that provide this, but not in TEA; TEA does these by perturbation. Internal energy is calculated from enthalpy, volume and pressure.

This should not affect the precision of the internal energy value itself though - merely its derivatives.

You are correct that there was a book-keeping problem there (in volume values, when volume is evaluated from the EOS calculation routine in combination with a perturbation, e.g. enthalpy.Dpressure, such as is done by the internal energy routine). Corrected, and the correction is available via CUP. Thank you for reporting this issue.