On October 13, 2015, within the CAPE-OPEN 2015 Annual Meeting, Sergej BLAGOV, col-leader of the Thermo SIG with Jasper van BATEN (AmsterCHEM) presented (PDF, 562 Kbytes) a report on the Thermo SIG activities since the previous CAPE-OPEN Annual Meeting, so from October 2014 till September 2015.
S. BLAGOV reminded first everyone of the charter given to the Thermo SIG by CO-LaN Management Board. Its defined tasks are “Develop, maintain and promote Thermodynamic and Physical Properties interface specifications”. The membership in the Thermo SIG is made of Andrew LINTERN (HTRI), Jasper van BATEN (AmsterCHEM), Murugesh PALANISAMY, Paul ZHOU and Xiaozheng-Sara WANG (all from Honeywell Process Solutions), Rafael LUGO (IFPEN), Richard SZCZEPANSLI (Infochem Computer Services), Sergej BLAGOV (BASF) and Suphat WATANASIRI (Aspentech).
The work described has been conducted between S. BLAGOV, J. van BATEN and Michel PONS (CO-LaN’s CTO). Efforts have been concentrated on advancing the Chemical Reaction Package interface specification as version 1.1. Its main concepts were presented at the CAPE-OPEN 2012 Annual Meeting. Work is coinducted in weekly conference calls. And even with this focused group and such regular meetings, the finalization of the Chemical Reaction Package interface specification is not there yet.
S. BLAGOV re-stated the motivations behind the re-design of the Chemical Reaction Package interface specification. Issues such as the fact that reaction basis is not clearly defined, that the units of measure used are not SI-based, that several concepts are not well defined were a factor in the re-design. There is also the point that the original Chemical Reaction Package interface specification was developed at a time where version 1.0 of Thermodynamic and Physical Properties interface specification was the only version available while there is a large overlap between reactions and version 1.1 of the Thermodynamic and Physical Properties interface specification, including compound definition and material context.
Issues with the proposal made at the CAPE-OPEN 2012 Annual Meeting are known: for example no reactive phase equilibrium calculator defined. Further work was indeed necessary with the objectives to issue a design as general as possible, showing compactness and flexibility. Where do we stand in October 2015?
Four main concepts were dealt with: Chemical Reaction Server, Reactive Phase Equilibrium, Compound Slate and Custom Data Storage on Material Object.
Chemical Reaction Server
The concept was already presented at the CAPE-OPEN 2013 Annual Meeting. A Chemical Reaction Server may be either a Property Package or a Reaction Package.Three levels of configuration of a Chemical Reaction Server have been explored: through some kind of private configuration accessed through a call to ICapeUtilities::Edit, through its association to a Material Template or through its association with a Unit Operation. During the period in reference, the proposal was enriched with the reorganization of reactions into a hierarchy. The purpose was to facilitate the analysis of a set of reactions provided by a Chemical Reaction Package so that complex reaction systems could be handled.
Reactive Phase Equilibrium
When a Reactive Phase Equilibrium is taking place, overall composition may change. It is necessary that the Unit Operation to be made aware of such a change. This has been explicited in the relevant Use Cases.
The presence of multiple Compound Slates is recognized through the definition of Material Object Delegates that are sharing state information (pressure, temperature, phase fractions) among the Material Object and its Delegates.
If one considers the sequence of events taking place when true composition is internal to the Property Pakage, one sees that true composition is calculated as part of phase equilibrium, that phase equilibrium is often followed by property calculation and that property calculation often requires true composition. Means that re-calculation of true composition may be needed quite soon after previous calculation and this step can be ratther CPU intensive. Means that it would be convenient if true composition was cached, but where? Caching on the Property Package is inconvenient because the Property Package has no advanced knowledge of the life-span of each Material Object and because the Property Package has no a-priori knowledge about the number of Material Objects it needs to serve. It appears then that storage should be arranged on the Material Object.
Custom Data on Material Object
Such storage is specific to the Process Modelling Component (can be a Property Package or another PMC in the long run) so the Material Object cannot access it. A number of rules have been defined to ensure that data stored can be put to use easily and efficiently. This has led the Thermo SIG to develop a separate document describing this new interface, document which has not been released yet outside the Thermo SIG since it may still be improved while progressing the Chemical Reaction Package interface specification.