Using COCO Tea in a C++ code

[jasper]

[seb007]

[jasper]

Glad to hear it works.

[seb007]

Hi,

I am progressing, but I still have an issue. I try to access directly to the material object, using DECLARE_NO_REGISTRY() in the ATL/COM class; then calling MyCapeOpenCOM::CreateObject() from the dll.

However, MyCapeOpenCOM type has an incomplete type in may main C++ code.

- Do I have to remove the #import of the COM dll, as I use it as a regular dll?
- Do I have to #include the MyCapeOpenCom.h file instead? When I try I get a compilation error (CComObjectRootEx is not a template).
- Do I have to export the interface as a regular dll?

Also, I have another question for the future. You said that I need to implement ICapeThermoCompounds. Isn't that included in property package?

Thanks for your help.

[jasper]

Just #include the header in which you define the class... ComObjectRootEx is declared in the ATL headers. You may need to include those as well.

Yes, the compounds interface is implemented by the PP, which provides the compound definitions. However, the material object may contain a sub-set of the compounds in the PP. So the PP will call GetCompoundList on the MO's implementation to see which compounds are present on the MO.

If you always keep PP order, I suppose you can pass this call back on the PP, and let the PP answer its own question.

Note that the PP will likely ask you this once in between every call to SetMaterial and store the result. At least, this is how the MaterialContext is intended (not all implementations may follow this strategy). So if you have only one material object to work with, only call SetMaterial once. However, if you change the compound list on the material object, you must call SetMaterial again.

[seb007]

Thanks! By implementing ICapeThermoCompounds (just calling the Property Packages's methods), I can now do property calculations and even call calcEquilibrium. I still cannot create a material object other than through the COCreateInstance, but I will let that for later...

My idea for using a property package was to compute pressure and temperature FROM density and enthalpy rather than the opposite. This does not seem to be possible (at least when looking at the properties that TEA can compute), and I need to perform iterations on my side (which I tried to avoid). Is there any other way to get pressure and temperature from density and enthalpy?

[jasper]

No - in CAPE-OPEN, T and P are chosen as the degrees of freedom for mixture properties.

Well - that is, theoretically you could do a flash at T and rho and only allow for the phase of interest. Clearly in the case of a cubic equation of state (or any equation of state explicit in volume) you can avoid the iterations on both ends if you would do the calculation directly.

TEA does not currently support this flash though, and I doubt any other implementation has this special case of a single phase flash implemented in a non-iterative manner. And implementing this special case is easy enough, but it would make sense if I were to supply P-V flash support for the VL system as well, which is a bit more work. Also the single phase PV flash would of course not work for an incompressible liquid model. And would still be iterative for any model that is not explicit in volume.

[seb007]

OK. Iterating with TEA through COM calls is quite slow (compared to my own PR implementation), so I will use pre-computed tables and interpolate, which will be valid if the composition does not change.

Thanks a lot for your help in setting up the COM interaction with CAPE-OPEN components!

[jasper]

For a well-implemented material object, the CAPE-OPEN overhead is small if the number of compounds is more than a few. There may be an impact in systems with a very limited number of compounds.

As mentioned at the start of this thread, TEA itself is not the fastest. It was not designed with fast in mind. It was designed with interoperability in mind.