Does TEA not support ICapeThermoMaterial?

[bcbooo]

[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]

[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.