Does TEA not support ICapeThermoMaterial?

[bcbooo]

I tried to connect to TEA(CAPE-OPEN 1.1), codes like following:

Code: Select all

iCapeThermoPropertyPackageManager->GetPropertyPackage(CBSTR(_T("PropertyPackageName")),&iDispatch);

It is successful. Then, I want to get other interfaces. like following:

Code: Select all

CComPtr<ICapeThermoPhases> capeThermoPhases;
hr=iDispatch->QueryInterface(__uuidof(ICapeThermoPhases),(LPVOID*)&capeThermoPhases);

All interfaces are achieved, but except the ICapeThermoMaterial.

So I wonder whether TEA (CAPE-OPEN 1.1) establishes the ICapeThermoMaterial?

[jasper]

Property Packages do not implement material objects: simulation environments are the software components that own and implement the Material Object. The Material Object is passed to a Property Package nearly at each call in thermo 1.0 (the first argument to CalcProp for example) or through the ICapeThermoMaterialContext interface in version 1.1.

[bcbooo]

Property Packages do not implement material objects: simulation environments are the software components that own and implement the Material Object.

As you say, ICapeThermoMaterial is owned by simulation environment, and others are owned by Property Package, means that ICapeThermoMaterial is seperated with others. So we can't use

Code: Select all

iCapeThermoMaterial->QueryInterface(IID_ICapeThermoCompounds,(LPVOID*)&iCapeThermoCompounds);

to get the ICapeThermoCompounds. But in your "CPP Mixer Splitter example", there are many codes like the preceding context.

[bcbooo]

Is it rational for the Property Package to imply ICapeThermoMaterial and ICapeThermoPropertyRoutine and so on together?

[jasper]

A v1.0 Property Package implements ICapeThermoPropertyPackage. A v1.1 Property Package implements ICapeThermoMaterialContext, ICapeThermoPhases, ICapeThermoCompounds, ICapeThermoPropertyRoutine, ICapeThermoEquilibriumRoutine, ICapeThermoUniversalConstant, error interfaces and perhaps persistence interfaces. A Property Package does not implement a Material Object, unless it needs to do so because it also serves as a PME from the point of view of another Property Package, but such a Material Object is not exposed to the PME (for example, TEA allows using third party property packages for equilibrium calculations or property calculations; in this case TEA must provide a Material Object to these property packages)

The simulation environment implements the Material Object, which represents for example a stream in a flowsheet.

[bcbooo]

Does the simulation environment still need to implement ICapeThermoEquilibriumRoutine, ICapeThermoPhases and so on?
In Unit Operation, the other interfaces are obtained by QueryInterface. If PME implemented ICapeThermoMaterial, but Property Packaged implemented others interfaces, it's not available to use "QueryInterface" function to get others.

[jasper]

Yes - the simulation environment implements all of the interfaces that a Property Packages does, on the Material Object, with exception of persistence and the Material Context. This is indeed the interfaces used by the Unit Operation. Plus ICapeThermoMaterial.

The implementation of most of the functions of these interfaces on the material object are similar to:

- set the context material on the Property Package, if this is not already the context material (it is important not to switch the context material in case this is not required, as this allows the Property Package to assume that the list of compounds on the Material Object remains unchanged)
- forward the call to the Property Package

There are some exceptions; particularly: the ICapeThermoCompounds "GetCompoundList" should not be forwarded by the Material Object to the Property Package; this is used by the Property Package to check which compound are available on the Material Object, which may be a sub-set of the total set of compounds exposed by the Property Package. Even if the Material Object exposes all compounds of the Property Package in the same order as the Property Package, forwarding this call will lead to a situation where the Property Package asks the Material Object and in turn the Material Object asks the Property Package, leading to stack overflow.

[bcbooo]

Thank you Jasper!

[jasper]

You are welcome. Please note that it makes sense to have the Material Object implemented by the PME and not by the Property Package: if there is no Property Package, the PME can use its internal thermodynamics to implement the Material Object functionality so that Unit Operations may use a Material Object whether or not a Property Package is actually used.

[bcbooo]

OK, I get it.