|
CAPE-OPEN UPDATE, Volume 8
CAPE-OPEN UPDATE is a publication of the CAPE-OPEN Laboratories Network (CO-LaN), a non-profit consortium for the development of the CAPE-OPEN standard.
STAFF LISTING:
Kerry Irons, Editor
Editorial Board: Peter Banks, Bertrand Braunschweig, Celeste Colantonio, Ronald-Alexander Klein, Werner Merk, Hans Pingen, Michel Pons
Technical Support: ADDUCE GmbH
An Updated CAPE-OPEN Thermodynamics and Physical Properties Specification
Richard Szczepanski
Infochem
Computer Services Ltd.,
13 Swan Court
,
9 Tanner Street,
London
SE1 3LE
,
UK
30 March 2004
www.infochemuk.com
Introduction
The Thermodynamics and Physical Properties Specification (Thermo. spec.) was one of the earliest products of the CAPE-OPEN (CO) project.
It was recognised that thermodynamic and physical properties were often at the core of a company’s technology and that in-house
physical properties were a major barrier to exploiting the full range of available simulation/modelling software. The CO project
offered the possibility of taking the physical properties from one source and being able to use them across a range of applications
through a standard interface. The original Thermo. Spec. was published in 1999 with a revision in 2002 [1]. Along with the Unit Spec.,
the Thermo. Spec. is perhaps the most used and useful of all the products of the CO project – so why do we need a new version?
The Thermo. 1.1 Spec. has grown out of an effort by the Global CAPE-OPEN Inter-operability Task Force (ITF). The ITF had the task of
demonstrating that the CO vision could work in practice by interchanging unit operations and physical properties between commercial
process simulators. Although this effort has been successful it was by no means straightforward and many lessons were learned. Physical
properties were at the root of many incompatibilities. It was obvious that the 1.0 Spec. required clarification but it also needed a
fresh approach to move beyond the limited conception of 2-phase (vapour-liquid) equilibrium that informed its design.
This article describes the background and objectives of the Thermo. 1.1 Spec. and reviews some of the key features.
The prototype implementations of the specification together with the draft document [2] are available on the CO-LaN website.
Objectives
The objectives we had in mind when formulating a new Thermo. spec. included the following:
·
To improve the clarity - by removing ambiguities and defining the purpose and functionality of components in some detail.
The target audience is implementers of physical property systems and their clients, the suppliers of process simulation software.
·
To simplify implementation of Thermo. plugs and sockets by breaking down functionality into simpler units and removing redundant features (e.g.
the calcType specification).
·
To improve reliability by defining exceptions for each method and by providing a complete range of methods to check the capabilities of a component.
·
To support efficient implementations by simplifying methods and adding streamlined methods to handle the most frequently used
calculations.
·
To add new facilities and support future extensions. These include multiple phases, solids, completely general flash specifications, and
distributed properties.
The Thermo. 1.1 Spec. describes four types of software components.
·
Property Calculator (PC) – can calculate certain physical properties, possibly restricted to mixtures of particular compounds in
particular phases.
·
Equilibrium Calculator (EC) – can calculate the composition of mixtures, possibly restricted to mixtures of particular compounds
existing in particular phases and subject to certain constraints.
·
Property Package (PP) – combines the functions of a Property Calculator and an Equilibrium Calculator for a fixed set of
compounds and phases. In the remainder of this article the Spec. will usually be discussed in the context of a PP.
·
Property Package Manager – manages a set of Property Packages. It is responsible for instantiating Property Packages on request
and may allow packages to be edited and/or created. This component has a very specific and simple function and will not be discussed
further.
The purpose of these components is broadly similar to those defined in the 1.0 Spec. but we have (mostly) chosen different names to
describe better their functionality and to emphasise the different interfaces and methods supported.
An additional component is the Material Object (MO) which provides access to the data describing a material (e.g.
chemical species, composition…). The MO is used as a container to communicate between a Thermo component such as a Property
Package and a client such as the Process Modelling Environment (PME).
Interfaces and Methods
In the 1.0 Spec. there is a one-to-one correspondence between software components and interfaces whereas in 1.1 there are more
interfaces but each one may be implemented by several components.
The interfaces and their methods are summarised in the following list taken from a figure in reference [2]:
ICAPEThermo PropertyPackageManager
+GetPropertyPackageList()
+GetPropertyPackage()
ICAPEThermoPropertyRoutine
+CheckSinglePhasePropSpec()
+GetSinglePhasePropList()
+CalcSinglePhaseProp()
+CheckTwoPhasePropSpec()
+GetTwoPhasePropList()
+CalcTwoPhaseProp()
+CalcAndGetFugacityCoefficient()
ICAPEThermoEquilibriumRoutine
+CheckEquilibriumSpec()
+CalcEquilibrium()
ICAPEThermoUniversalConstants
+GetUniversalConstant()
+GetUniversalConstantList()
ICAPEThermoPhases
+GetPhaseList()
+GetPhaseInfo()
+GetNumPhases()
ICAPEThermoMaterial
+GetPresentPhases()
+SetPresentPhases()
+GetSinglePhaseProp()
+SetSinglePhaseProp()
+GetTwoPhaseProp()
+SetTwoPhaseProp()
+GetOverallProp()
+SetOverallProp()
+ClearAllProps()
+GetTPFraction()
+CreateMaterial()
+CopyFromMaterial()
ICAPEThermoContext
+SetMaterial()
ICAPEThermoCompounds
+GetCompoundList()
+GetCompoundConstant()
+GetConstPropList()
+GetNumCompounds()
+GetPDependentProperty()
+GetPDependentPropList()
+GetTDependentProperty()
+GetTDependentPropList()
ICapeThermoMaterial
This interface is implemented by a MO and it is used by any of the Thermo. components to communicate with a client.
The methods are mostly concerned with getting and setting properties in the MO. For example, a PP might use GetSinglePhaseProp to get
the temperature at which a calculation should be performed and SetSinglePhaseProp to return a calculated value.
ICapeThermoPhases
The methods of this interface provide information about the number and types of phases (gas, liquid, solid…) supported by a Thermo. component.
It would typically be implemented by a PP, PC and EC component. More details about phases are given in a separate section below.
ICapeThermoCompounds
This interface is implemented by components that provide information about chemical species. The methods can be used to identify
compounds and to request/provide property values for pure compounds.
ICapeThermoPropertyRoutine
The methods of this interface support property calculations. Properties may depend on a single phase, e.g.
enthalpy, or they may involve two phases, e.g. K-values or surface tension.
ICapeThermoEquilibriumRoutine
This interface provides methods for carrying out phase equilibrium calculations where the overall mixture composition is fixed plus
the values of two constraints such as temperature and pressure.
Uniform Structure
The methods giving access to properties and calculations have a uniform structure:
Enquiry methods – return a list of the supported properties. E.g. GetSinglePhasePropList.
Check methods – to allow a calculation specification to be checked prior to carrying out the calculation. E.g.
CheckSinglePhasePropSpec.
Calculate methods – to perform a calculation. E.g. CalcSinglePhaseProp.
This pattern is repeated wherever possible and appropriate.
Handling of Phases
The handling of phases in the 1.0 Spec. is rudimentary. An important advance in the 1.1 Spec. is the support of any number of phases and
any types of phases. Information about the phases supported by a component is provided by the methods of the ICapeThermoPhases
interface. A central concept is the phase label. This is an arbitrary string, e.g. “HydrocarbonLiquid,” that is used
to identify a particular phase and to refer to its attributes. The attributes provide information that helps client software or a human
being understand what sort of phase the label refers to. A list of attributes is given in the following table.
|
Phase attribute
|
Meaning
|
|
state of aggregation
|
the physical state: vapor, liquid or solid
|
key compound
|
identifier of the compound that is expected to be present in highest concentration in the phase – this helps to distin?guish
multiple instances of, say, liquid phases. E.g. for an aqueous liquid phase the key compound would be water
|
excluded compound
|
this is the opposite of the key compound, i.e. identifier of the compound that is expected to be present in low or zero
concentration in the phase
|
density description
|
description that indicates the density range expected for the phase, e.g. Heavy or Light
|
user description
|
description to help the user or PME identify the phase
|
|
type of solid
|
description that provides more information about a solid phase, e.g. PureSolid, SolidSolution, HydrateI etc.
|
A PP can support any number of phases, each with a unique phase label. The PME can use the ICapeThermoPhases interface to discover the
number and types of phases supported. Although a PP may support many phases this does not imply that a client should make use of all of
them. For example some PMEs may not be able to handle solid phases.
Phase Equilibrium Calculations
The methods of the ICapeThermoEquilibriumRoutine interface have been designed to make them as general as possible in order to allow for
multiphase calculations and any type of flash specification. Within the scope of the 1.1 Spec. a phase equilibrium calculation must
return the amounts and compositions of the phases at equilibrium (plus the temperature and pressure) given the overall composition of
a mixture and the values of two constraints. There are no fixed identifiers for the type of flash but instead two specification variables
are used to identify the constraints and the actual values of the constraints are retrieved using the MO. For example, in the
simplest case of an isothermal, isobaric flash the constraints are the temperature and pressure themselves. This scheme allows for
almost any flash specification.
A particularly important class of flash problems correspond to the specification of
the temperature or pressure plus the amount (phase fraction) of a particular phase. This is a generalisation of the familiar P/T plus
vapour fraction specification for vapour-liquid systems. Practical applications include the calculation of the water dew point or
hydrocarbon dew point in oil/gas/water systems or the calculation of a solid wax formation temperature.
A PP may support a large number of phases but it is not necessary to consider all of the phases in any given equilibrium calculation.
The SetPresentPhases method of the ICapeThermoMaterial interface may be used by the PME to define a subset of the phases supported by
the PP that should be considered in a phase equilibrium calculation. For example, to allow for hydrate formation modelling in general
a PP must support the following phases: gas, hydrocarbon liquid, aqueous liquid, solid ice, solid hydrate structure I, solid hydrate
structure II. In a high temperature section of a process it may not be necessary to consider the solids so SetPresentPhases could be
used to restrict the calculations to gas/hydrocarbon liquid/aqueous liquid. Of course the conditions may be such that an aqueous liquid
phase does not form so SetPresentPhases would also be used by the Equilibrium Calculator in the PP to report the actual phases present
at equilibrium.
Distributed Properties
It is recognised that some properties may not have a simple point value like the temperature or pressure. The Thermo. spec. already
caters for properties that have an intrinsic vector or matrix structure like the fugacity or diffusion coefficient. A further possibility
is a property that depends on a distribution that characterises a material. For example, the density of a particulate solid may depend
on the particle size distribution. To allow for the possibility of properties with complex data structures the methods for setting
and getting properties may return an interface pointer that can be used to invoke special methods to handle a property.
A set of extensions for handling distributed properties has been proposed by workers at the University of Technology Hamburg-Harburg
to support the SolidSim project.
Efficiency Considerations
It is a common assumption that open interfaces present a penalty in terms of computational efficiency when compared with native
interfaces. Work on the 1.0 Thermo. spec. showed that the penalty of using the CO interface could be reduced to a small margin but
this required considerable care in programming both the PME Thermo. socket and the Property Package plug. The experience gained has been
encapsulated in a document [3] which shows that a major barrier is overcoming the overheads of using COM. The lessons learned with the
1.0 Spec. have been incorporated in version 1.1 along with some important improvements to the interface structure and the methods.
ICapeThermoContext interface
When a PP is called with a request for a property calculation it needs to obtain information from the client using the MO. Instead of
passing the MO reference as an argument to the calculation methods as was done in the 1.0 Spec. the 1.1 Spec. provides the
ICapeThermoContext interface with a single SetMaterial method for this purpose. Any component that requires to access a MO must
implement this interface. The change has some important consequences. The MO reference is set by the SetMaterial call and the PP can
assume that the configuration of the MO remains unchanged until SetMaterial is called again. Thus any overhead associated with checking
that the MO is valid or any initialisation of the PP that depends on the configuration of the MO (compound list, phase list) need only
be carried out when SetMaterial is called instead of at every call for a property calculation or flash calculation. The new arrangement
allows code to be simplified and, assuming that changes in configuration of the MO are not frequent compared with property evaluations,
can make a significant improvement in calculation speed.
Calculation conditions
It is important to minimise the number of calls from one software component to another. Every property evaluation with the methods of
the ICapeThermoPropertyRoutine interface requires that the temperature, pressure and composition of a phase be retrieved by the PP
using the MO. The 1.1 Spec. optimises this operation by providing a special-purpose method GetTPfraction that fetches all the
information in a single call rather than requiring three separate calls to the GetSinglePhaseProp method. Furthermore the arguments of
all methods used to access properties are defined as input/output arguments even though their use is actually to provide output
information. This means that efficiency savings can be made in setting up and reusing storage - the technical background is given in
reference [3].
Fugacities
The most intensively used property is the fugacity coefficient [3] because it is the basis of all flash calculations. A special method
is provided in the ICapeThermoPropertyRoutine interface to optimise this calculation. CalcAndGetFugacityCoefficient does just what its
name suggests. The method is unusual in the CAPE-OPEN context because both calculation conditions (T, P, composition) and calculation
results (fugacity coefficients and their derivatives) are passed as arguments. The MO is not used. This arrangement allows the overhead
of procedure calls to be minimised.
Simplified Property Calculation Requests
The format of property calculation requests has been drastically simplified allowing for much improved software structure and
consequent improvements in efficiency and maintainability. Two classes of properties are defined for mixtures. Single phase properties
are those that depend on the state of a single phase, e.g. enthalpy, volume… Two phase properties depend on the state of
two phases in equilibrium, e.g. K-values, surface tension… Separate methods are provided in the ICapeThermoPropertyRoutine
interface to handle the two classes.
The structure of a method like CalcSinglePhaseProp in 1.1 is very simple – the arguments specify the list of (single-phase)
properties and a single phase label. This should be compared with the equivalent 1.0 method CalcProp that allows a list of
properties, a list of phases and a ‘calcType’ which indicates whether pure or mixture properties are required. The resulting
multiplicity of possible property and phase combinations in CalcProp makes the organisation of the calculation procedure complex and
difficult to optimise.
Exception Handling
The error handling strategy for CAPE-OPEN components is described in reference [4]. Although that document lists some exceptions for
Thermo. 1.0 components there is no definition of the circumstances in which the exceptions might be raised.
The 1.1 Spec. includes a list of exceptions for each method of every interface and carefully describes the conditions corresponding to
each exception. A great deal of time and debate was spent on this topic. The exception definitions were further refined as a result of
the prototyping of 1.1 components (see below). Experience suggests that the present exception list should allow reliable and effective
handling of error conditions for Thermo. components.
Prototyping
Prototype Thermo. 1.1 components have been developed by Infochem for the Co-LaN in conjunction with a parallel development of a new
CO-Tester at the Universitat Politècnica de Catalunya. For more details of the CO-Tester see reference [5].
The components developed were a Property Package and a Property Calculator. Both are
based on a very simple set of thermodynamic and transport property models for a limited number of compounds. The phases supported are
vapour, liquid and aqueous liquid and two phase equilibrium calculations are provided: P,T flash and P,H flash. The Thermo. 1.1
interfaces are implemented in a Visual Basic wrapper that is completely separate from the calculation procedures which are contained
in an independent dll. It is the intention of the Co-LaN that the prototypes should be available to help other developers that need to
understand or implement the 1.1 Spec.
The prototyping exercise was a very useful experience. As a result the descriptions of the methods, arguments and exceptions were
improved and clarified to remove ambiguities and to deal with unanticipated circumstances. In general the 1.1 Spec. was easy to
implement and allowed for considerable simplifications compared with the equivalent 1.0 code which was used as a starting point.
Conclusions
The 1.1 Thermo. spec. is the result of a major collaborative effort between suppliers of process modelling software, users, physical
property specialists and software specialists. It forms a basis for extending the current CAPE-OPEN standards to new areas of
application including multiple phases, solid phases and distributed properties. Prototype implementations have demonstrated that the
proposals are practical and useable.
References
1. CAPE-OPEN Open Interface Specifications. Thermodynamic and Physical properties Version 1.0,15 March 2002
2. CAPE-OPEN Open Interface Specifications: Thermodynamic and Physical properties Version 1.1 (Version 2.10, 14 November 2003.
3. Optimization for COM CAPE-OPEN Thermo Components, Daniel Piñol and Michael Halloran, Aspentech, December 2002.
4. Error Handling Strategy: Error Common Interface, 30 September 2000.
5. Towards the Standardisation of Thermodynamic and Physical Properties Packages, Benqlilou C., S.
Bel, M. González, M. Pons, R. Szczepanski, A. Espuña, and L. Puigjaner, presented at Escape 14, May 2004.
Acknowledgements
I would like to acknowledge the contributions of all the people who worked on the 1.1 Spec. over a period of some three years:
Peter Banks, Werner Drewitz, Michael Halloran, Daniel Piñol, Michel Pons, Juan Carlos Rodriguez and Malcolm Woodman.
I would also like to thank all those individuals and organisations that have provided feedback and support.
| 
