A look into the CAPE-OPEN kitchen of COCO by Dr Jasper van Baten (Amsterchem)

Abstract: COCO by AmsterCHEM is a component based CAPE-OPEN simulation environment. It implements a flow sheeting environment, unit operations, a thermodynamics package, and a reaction package manager. The presentation shows an overview, test cases and demonstrates interoperability. COCO has proven to be a valuable tool for development and interoperability testing.

HIDiC in Aspen Plus by Gregor Fernholz (PSE Ltd) and Michel Pons (CO-LaN CTO)

Abstract: One of the major achievements of CAPE-OPEN is certainly the enhanced inter-operability of simulation software packages enabling the end user to simultaneously take full advantage of the strengths of several software packages and to minimise the model implementation effort at the same time. This presentation demonstrates how a rigorous state-of-the-art model of a heat integrated distillation column (HiDiC) is implemented and simulated in gPROMS, exported into a CAPE-OPEN Unit plug and finally used in an Aspen Plus flowsheet.

Beyond compliance by Joseph Holmes (HTRI)

Abstract: The focus of the talk is to encourage the software vendors and CO-LaN itself to look at issues beyond technical compliance with the CAPE-OPEN standards to drive acceptance of these interfaces in the marketplace. The paper presents some examples of work HTRI is doing in this direction.

CAPE and Property Packages: Air Liquide approach by Philippe Arpentinier (Air Liquide)

Abstract: The presentation summarizes first the evolution of the Air Liquide demand for thermodynamic properties (pure substances and mixtures) since the beginning of the nineties and the main difficulties currently encountered in R&D as well as in the Engineering Department for the estimation of thermodynamic properties and more generally on the level of process simulation due to the large variety of situations met with a lack of structure and tools for storage and re-use of information. Then the main actions decided to answer to the evolution of the demand for thermodynamic properties and to solve the current difficulties are presented: i) adoption of a thermodynamic standard usable at each step of the cycle of development of a process (pure substances: DIPPR; mixtures: Simulis-Prosim), ii) development of the concept of open "thermodynamic property package" dedicated to an application (interoperability of models, reproducibility of results, perpetuation of the in-house knowledge, improvement of the quality of accessible information for a relevant later re-use), iii) adaptation of the existing tools and development of the new tools with the CAPE-OPEN standard.

UniSim CAPE-OPEN Thermo and Unit Operation by Murugesh Palanisamy (HTSL)

Abstract: With UniSim CAPE-OPEN as an extension to UniSim Design Suite, simulation solutions will be enhanced providing customers to access other chemical process models built based on the CAPE-OPEN interface standard. UniSim CAPE-OPEN comprises UniSim CAPE-OPEN Socket and UniSim CAPE Thermo Plug In. UniSim CAPE-OPEN socket allows any third party CAPE-OPEN compliant Thermo packages and Unit Operations to plug and play within UniSim Flow sheeting environment. For example, a complex unit operation model built using gPROMS can be plugged into UniSim steady state design suite with which process capabilities of gPROMS could be used. Further, UniSim flow sheet can also leverage other vendor thermo property packages like InfoChem MultiFlash equilibrium package capabilities through UniSim CAPE Thermo Socket interface. Besides, UniSim’s powerful advanced thermo engine can be packaged and exported as CAPE compliant Thermo component and can be made available to other simulator vendor’s packages.

INDISS with Thermo and Unit by Didier Paen (RSI)

Abstract: RSI is involved in CAPE-OPEN Unit SIG and has developed inside INDISS Process Modelling Environment an implementation of dynamic CAPE-OPEN unit operations. The latest development done is the steady state resolution with CAPE-OPEN unit operations. Steady state resolution is adapted for initialization of dynamic simulation, but the switch to dynamic resolution requires some specific constraints on network. After steady state resolution, the dynamic mode can be activated to test transient behaviour. This feature has been used with IFP CAPE-OPEN pipelines. Tests have been done also with external thermodynamic packages as Simulis Thermodynamics from Prosim SA and we are now evaluating testing solutions with CO-LaN support.

Thermodynamic SIG achievements in 2005 by Werner Drewitz (BASF AG)

The CAPE-OPEN interface to COSMO-RS, a novel a priori predictive method for solution phenomena and fluid phase thermodynamics by Frank Eckert (Cosmologic), Jasper van Baten (Amsterchem), Richard Baur (Amsterchem)

Abstract: The CAPE-OPEN interface to the COSMOtherm program is presented. COSMOtherm is the premium software of the COSMO-RS method [1], which is a novel method for the a priori prediction of activity coefficients and vapor pressures of almost arbitrary chemical compounds in liquid solvents and mixtures.

SolidSim - A novel simulation system makes use of the CAPE-OPEN standard by M.Pogodda, C. Reimers, D. Schwier, E.-U. Hartge, J. Werther, G. Gruhn (Hamburg Technical University)

Abstract: To improve the acceptance of the novel simulation system SolidSim interoperability with established simulation systems and thermodynamic packages was an important point. This presentation gives a short summary on how this was achieved using the CAPE-OPEN standards. The difficulties which originate from the fact SolidSim is focusing on processes including solids are outlined. Special focus is put on the integration of physical property packages since simulations can only be performed if all necessary physical properties are available. By way of example the interoperability with Multiflash using the 1.1 CAPE-OPEN thermo standard is demonstrated.

An industrial case study for the upgrade of an existing software interface to the CAPE-OPEN standard by Alan Scott (TÜV-NEL)

Abstract: This presentation describes a project involving TUV NEL Ltd (suppliers of PPDS software), ABB Engineering Solutions (suppliers of PEL software) and INEOS Fluor (licencees of PEL and ASPEN Plus software). INEOS Fluor is a leading supplier of specialist services in Fluorine based processes. For many years the company has licenced modules from the PEL software suite for general applications, and also use Aspen Plus for some simulation projects. Specific thermo models have been developed within the PEL software for some key processes. To access these models, an interface was written (by ABB-PEL) to provide this information to Aspen Plus in the form of User Models. More recently the PEL software has been adapted to use the PPDS ThermoServer as the property and phase equilibrium calculation engine. The new models were also added to the PPDS code. Although the Aspen Plus interface could have been rewritten, it was decided that this provided an excellent opportunity to use the CAPE-OPEN methodology to provide a flexible and easily maintainable interface. The presentation gives a full example of creating a Property Package, and running a typical calculation directly in PEL-PhysPack and then the same calculation within a simulation in Aspen Plus through the CAPE-OPEN interface.

Beyond VLE – a CO Thermo 1.1 Property Package using MultiFlash by Richard Szczepanski (Infochem)

Abstract: One of the important objectives of the latest CO 1.1 Thermo standard is to extend and generalize the types of phase equilibrium calculations that can be handled. This presentation reports on the practical experience of producing a Property Package implementing the new standard and show examples of calculations involving multiple liquid and solid phases.

UNIT SIG achievements in 2005 by Richard Baur (Shell Global Solutions)

gPROMS CAPE-OPEN Unit socket as applied in the VPDM project by Thomas Williams (PSE Ltd)

Abstract: The Virtual Plant Demonstration Model (VPDM) Project is a major on-going collaborative R&D initiative in the UK power industry. Its main aim is to support "arms-length" inter-organisational collaborative modelling, allowing companies to make their models available in a strictly controlled manner to collaborating organisations, with which they may potentially be competitors in different contexts. VPDM has adopted the CAPE-OPEN standards. The presentation describes three software packages that PSE have developed to support this project: a CAPE-OPEN unit socket for gPROMS, a simple framework for making legacy unit codes CAPE-OPEN compliant and a framework for making CAPE-OPEN units available securely over the internet.

ChemSep in motion by Harry Kooijman (ChemSep)

Custom Process Unit Models in a Flowsheet Simulator - User Experiences by Wilma Hensen, Jan Willem Verwijs, Philippe Hayot (Dow)

The use of CAPE-OPEN modules – demonstrated in Aspen Plus by Martin Breil (DTU-IVC-SEP)

Abstract: The IVC-SEP research centre has investigated and developed a thermodynamic Property Package containing four thermodynamic models. The strength of this package is that it offers its users the benefits of the CPA and PC-SAFT models. These thermodynamic models are capable of handling mixtures of compounds with strong hydrogen bonds (associating compounds), such as water, alcohols, or carboxylic acids. Besides the thermodynamic property package, the IVC-SEP has produced a unit operation that combines the built-in thermodynamic models of the process simulator with our own algorithm of the PT-flash.

Methods&Tools SIG by Bertrand Braunschweig (IFP)

PLATINA by Pascal Roux and Martin Gainville

Abstract: IFP and Total are involved in a collaborative R&D project whose aim is to develop a tool including platform and components to allow user to perform steady state and transient simulation of multiphase flow from the reservoir to the top side facilities. One of the main idea is to address the issue of consistent data set and physical models (thermodynamic and hydrodynamic) in the field of flow assurance. A live demonstration is performed on a real case. The assembly of native and CAPE-OPEN Unit operation demonstrates inter operability. Moreover, interchangeability is shown while changing thermodynamic component from INDISS native thermodynamic to MultiFlash.

Distributed CAPE-OPEN Simulation of Oilfield Production Networks on PC Clusters by Laurent Pigeon

Abstract: Process simulations are more and more evolving to characterize the transient behaviours of unit operations composing a process flowsheet. Such simulations might require a huge computational effort in order to sustain the accuracy of some of the unit operations. Pipe unit operations represent a good example of them. Depending of the requested accuracy and the complexity of their model (number of meshes, inner iteration loop to solve flow/pressure equations), the completion of one time step for only one unit operation can require several seconds. Previous results based on steady state simulations have proved that such CAPE-OPEN simulations can benefit (in terms of performance) from being launched in a distributed way using clusters of PCs oriented architecture. We will present our approach to solve this problem on CAPE-OPEN compliant dynamic simulations. We also propose a demo, based on INDISS simulator, simulating oilfield production networks on a “little cluster” of workstations.

IFP UNIT Wizard for C++ code by Pascal Roux

Abstract: IFP has developed a Wizard to help engineers in the development of CAPE-OPEN Unit Operations. This tool was developed for internal use and it seemed worthwhile to give it to CO-LaN. The presentation focuses on the motivations of the development of such a tool and on a demonstration where a very simple unit operation is created and connected into PRO/II.

Development of a CAPE-OPEN Complaint Process Modelling Environment and Process Modelling Components in Microsoft .NET by William Barrett

Abstract: The CAPE-OPEN middleware standards were created to allow process modelling components (PMCs) developed by third parties to be used in any process modelling environment (PME) utilizing these standards. The CAPE-OPEN middleware standards were originally based upon both Microsoft’s Component Object Model (COM) and the Object Management Group’s (OMG) Common Object Broker Architecture (CORBA). Since the inception of the CAPE-OPEN project, Microsoft updated COM to the .NET Framework. This paper discusses the implementation of PMCs in .NET and the interoperability issues associated with using COM-based CAPE-OPEN compliant PMCs in a .NET based PME, and the testing of .NET-based unit operations in the CAPE-OPEN Tester.

Experiences on implementing CAPE-OPEN components using the .NET framework by Lars von Wedel

Abstract: The .NET framework has been introduced a few years ago by Microsoft as the upcoming technology for software development on Microsoft Windows. Numerous changes and improvements over COM, the current middleware integrated into Windows, have been made available as part of this framework. The talk briefly introduces the underlying principles of the framework and important changes over current technology. Further, experiences from implementing a CAPE-OPEN compliant unit operation developed using .NET in combination with existing code written in C will be shared. Especially questions regarding infrastructural issues such as error handling, implementing persistence, and user interfaces will be discussed. The talk will summarize open issues to be resolved in order to achieve interoperability between CAPE-OPEN compliant PMEs and PMCs based on current COM an future .NET technology.

REACTOR Special Interest Group Underway

A new SIG is forming within CO-LaN. The focus is refinery reactors and reactor engineering. The leader of this SIG is Ignasi Palou-Rivera (Ignasi_Palou-Rivera@bp.com). The SIG will focus on extending the CO standard in the reactor area and developing a prototype. Please contact him if you have interest in this key technology area.

Simulation Of Refinery Reactor Scenarios

Many of the concepts in this short document have been extracted or inspired by the Open Interface Specification: Petroleum Fractions Interface version 2 in the CO-LaN website. The reader is strongly advised to refer to it as background material.

There are two different situations when using refinery reactor models in a simulation environment:

• Continuous properties: There is a single slate of petroleum fractions (as defined by a series of cut points) for the whole flowsheet. The properties of the petroleum fractions (MW, critical properties, and thermo properties defined from them) can change per stream. This is, the properties of NBP-XXX (petroleum fraction defined by a XXX degree cut point) might be different in stream Y than those in stream Z.
Non-continuous properties: Thermodynamic properties for petroleum fractions are defined for the whole flowsheet. Multiple slates of petroleum fractions are needed in this case to compensate for the non-changing nature of the properties. When properties change (i.e. at the outlet of a refinery reactor) a new set of petroleum fractions needs to be used to compensate for the change in properties. The co-existence of several petroleum fraction slates implies the need for a mixing operation and corresponding unit.

Two scenarios will be presented to deal with the two cases above. In both cases the reactor unit needs to communicate to the simulator executive that it is a refinery unit. The simulator executive then needs to provide a material object containing petroleum fraction properties (e.g. octane number(s), distillation curves, etc.)

There is another important architectural issue related to the above two cases: whether the reactor model needs to be made aware of the simulator’s ability to support continuous properties or not. Naturally this is a non-issue when the simulator does support continuous properties. When continuous properties are not supported by the simulator, any adjustments could be made in two different places:

a) Refinery reactor interface wrapper on the simulator side.

b) Refinery reactor interface wrapper on the reactor side.

Case a) provides a cleaner architectural solution as it keeps the reactor side independent from any non continuous property support. However, the implementation of this solution might be more involved especially in the case of a reactor with more than one differently defined inlet. This situation is addressed in more detail in scenario 2. see below.

Continuous Properties Scenario

Conceptually this is a simple scenario:

a) When the reactor is initialized, it tells the simulation executive of its refinery nature so that it has access to all specific refinery properties in the material object.

b) The rector inlets are defined by the simulator. The inlets’ composition is expressed by a single set of components: some of them real pure components, some “representative” pure components, and a single slate of petroleum fractions. In this scenario there is no problem with a refinery reactor having more than one inlet as they are defined using the same composition basis.

c) The reactor performs its calculations (possibly using the refinery material object from the simulator executive), and then defines its outlets. All of the material outlets will be defined using the same component set as the inlets. The refinery outlets will also redefine the properties of the petroleum fraction components present in the flowsheet.

Non-Continuous Properties Scenario

a) Same as a) in scenario 1.

b) As in the continuous properties case the simulator defines the inlets to the reactor. However depending on the reactor’s awareness of the simulator’s support of continuous properties, different scenarios are supported:
i. Reactor is not aware of lack of support for continuous properties: any unit would expect all the inlets to be defined using the same composition basis. Therefore when the unit has more than one inlet and they are using different petroleum fraction slates one of two operations need to be performed by the simulator:
a. Mixing the inlets creating a new slate of petroleum fractions and then use it to express the mixed inlet stream.
b. Create a new slate of petroleum fractions to use in expressing the composition of all the inlets, but leaving the inlet streams unmixed. (Calculating the new slate of fractions is indeed a mixing operation, but the inlet streams are then left unmixed.)
ii. Reactor is aware of lack of support for continuous properties: the reactor model takes care of the inlet compositions and any transformation.

c) Similar to c) for the continuous properties case. However, the outlet composition definition would be different depending on the reactor’s awareness:

i. Reactor is not aware of lack of support for continuous properties: the simulator interprets the command to re-define the petroleum fractions properties as needing to create a new slate of petroleum fractions with the specified properties and express the outlet compositions using this new slate of petroleum fractions.

ii. Reactor is aware of lack of support for continuous properties: the reactor takes care of the creation of the new slate of petroleum fractions with their own properties and expressing the outlet composition using these petroleum fractions.

A fundamental point of the two ii scenarios is that the refinery reactor model would be unchanged and unaware of its residence in a continuous or non-continuous properties simulation executive. The simulation executive would be responsible for interpreting the reactor requests (e.g. update of petroleum fraction properties) in the appropriate way, and to provide the necessary facilities (e.g. special mixer), including their inclusion in the flowsheet, for the use of refinery reactors. Support for continuous properties is a characteristic of the simulation executive and therefore all responsibilities derived from them would stay with the simulator.

Chemical Characterization

Petroleum fractions do a physical characterization of the oil composition. Pure component compositions are both physical and chemical characterizations of the oil. Representative pure components are an approximate physical and chemical characterization. Historically petroleum fraction representations were created for modelling non-reactive operations (e.g. crude unit) where a chemical characterization is not needed. In refinery reactor operations a chemical characterization of the oil is needed. Therefore when the inlet oil is characterized by petroleum fractions (and representative components too, to a lesser degree) a chemical representation of the oil should accompany its physical representation. Although in widespread use in specialized refinery reactor models, these chemical characterizations are not incorporated into existing simulators and currently need to be adapted using user-defined variables. It is necessary that the refinery reactor interface provides an explicit implementation of a general chemical characterization array for any oil stream.

One possible way to incorporate this chemical would be to extend the petroleum fractions interface, both in scope and in name. These extended fractions should encompass petroleum definitions both at the physical and chemical levels.

Refinery Reactor Prototypes

Two different units should be used in order to prototype the implementation of the refinery reactor interface: the first one is a complex mixer/splitter used to test any issues with combining, and updating (or creating) petroleum fractions and chemical characterizations of oils; the second one is a simple lumper/de-lumper used to test issues when changing the basis for the oil’s characterizations.

Complex Mixer/Splitter:

Lumper/De-Lumper:

=======================================================

CAPE-OPEN Update Subscription

If you want to «subscribe» or «unsubscribe» CAPE-OPEN Update, please send an email to technologyofficer@colan.org with subscribe or unsubscribe as subject, respectively. If you need to contact the CO-LaN about the distribution list (if you have trouble unsubscribing or have questions about the list itself), please contact technologyofficer@colan.org