[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/feed.php on line 173: Cannot modify header information - headers already sent by (output started at [ROOT]/includes/functions.php:3823)
[phpBB Debug] PHP Warning: in file [ROOT]/feed.php on line 174: Cannot modify header information - headers already sent by (output started at [ROOT]/includes/functions.php:3823)
CAPE-OPEN Discussions about use and implementation of the CAPE-OPEN standard 2018-06-12T08:00:41+00:00 http://www.cape-open-forum.org/feed.php?f=41 2018-06-12T08:00:41+00:00 2018-06-12T08:00:41+00:00 http://www.cape-open-forum.org/viewtopic.php?t=617&p=2098#p2098 <![CDATA[Thermo SIG • June 11, 2018 conference call]]>
Assuming that the Chemical Reaction Package holds a value for the heat of reaction at given conditions, the Chemical Reaction Package interrogates the Property Package so that the corrective term, necessary to represent any gap between that heat of reaction (maybe obtained from experimental data) and the heat of reaction that could be derived from heats of formation of individual compounds as present in the Property Package, is properly computed. It is this sequence of steps that has been numerically assessed before attempting to outline the process in the document describing the interface specification for Chemical Reactions.

Statistics: Posted by colancto — 12 June 2018, 08:00

]]> 2018-06-05T12:19:13+00:00 2018-06-05T12:19:13+00:00 http://www.cape-open-forum.org/viewtopic.php?t=614&p=2092#p2092 <![CDATA[Thermo SIG • June 5, 2018 conference call]]> In order to assess what communication is needed between the software components involved, and hence any need for additional properties or methods, an example started by was expanded in order to figure out the sequence of actions taking place. Not yet with a complete grasp of the many possible cases.

Statistics: Posted by colancto — 05 June 2018, 12:19

]]> 2018-05-30T12:22:44+00:00 2018-05-30T12:22:44+00:00 http://www.cape-open-forum.org/viewtopic.php?t=611&p=2089#p2089 <![CDATA[Thermo SIG • May 29, 2018 conference call]]> The is revising the Custom Data interface specification which has been developed as a side project of the rewriting of the . During that rewriting, it appeared that letting a Property Package or a Chemical Reaction Package store intermediate results on a Material Object could be beneficial in terms of performance, especially when a Property Package is operating on a true composition and the PME on an apparent composition.
The current revision of the Custom Data interface specification introduces the concepts of a Custom Data Source and of a Custom Data Container. Obviously a Custom Data Source may be a Property Package or a Chemical Reaction Package. A Custom Data Container is a secondary CAPE-OPEN object on a Material Object. The Material Object has no way to write/read specific data from the Custom Data Container. Since Custom Data is private to a Custom Data Source, only the Custom Data Source who asked for that Custom Data Container to be created,is capable to access it in write or read. However it is the Material Object which creates and deletes the Custom Data Container. These concepts of Custom Data Source and Custom Data Container are new to this version of the Custom Data interface specification and are meant to clarify the interactions taking place around Custom Data.
is still expecting to release the Custom Data interface specification for review later this year.

Statistics: Posted by colancto — 30 May 2018, 12:22

]]> 2017-08-15T18:23:23+00:00 2017-08-15T18:23:23+00:00 http://www.cape-open-forum.org/viewtopic.php?t=562&p=1878#p1878 <![CDATA[Thermo SIG • August 8, 2017 conference call]]>
The Thermo SIG has been pushing for Thermo 1.0 deprecation for the past few years. The issue was raised back in 2014 during the CAPE-OPEN Annual Meeting held in Mörfelden, Germany. Such a deprecation seems needed when considering the benefits brought by Thermo 1.1. Still a path forward needs to be offered to those who have invested solely in Thermo 1.0.

Views on continuing support and implementation of Thermo 1.0 are welcome.

Statistics: Posted by colancto — 15 August 2017, 18:23

]]> 2017-07-18T15:20:42+00:00 2017-07-18T15:20:42+00:00 http://www.cape-open-forum.org/viewtopic.php?t=560&p=1876#p1876 <![CDATA[Thermo SIG • July 18, 2017 conference call]]>
On the agenda was to figure out the pros and cons of handling the plurality of Compound Slates with or without Delegate Material Objects. It seems to boil down to accepting automatic conversions between compound slates or not accepting such an automatic procedure.
Compound Slates provide the different representations of a mixture: the basic example being the difference between an apparent compound approach and a true compound approach. As permitted by CAPE-OPEN, there are a number of software components involved around different Compound Slates. The Material Object, which is owned by the Process Modelling Environment, is populated in terms of composition, phase split with respect to a specific Compound Slate. Plus it carries temperature and pressure of the mixture. Who is populating the Material Object? Among the possibilities, there is a Property Package when calculating the phase and presumably reactive equilibrium at specified conditions. The Property Package may carry its calculations using a different Compound Slate than the one used by the Material Object. Typically the Property Package may prefer to carry calculations using a true compound approach while the Material Object will store information using an apparent compound approach. The Property Package will have to convert the apparent compound representation as stored on the Material Object into a true compound approach to be manipulated within the Property Package. When the calculation within the Property Package is finished, the Property Package needs to store back the results on the Material Object, presumably using an apparent compound approach, so with another conversion involved.
Defining Delegate Material Objects, which behave as Material Objects but differ from the original Material Object by the Compound Slate used to represent the mixture, while sharing the same state, is a way to keep the different representations of a mixture in parallel and synchronized. This consistency is automatically ensured by the PME even if the operations needed to keep that consistency rely on the Property Package. IS it necessary to introduce such a concept which is very close to a Material Object apart from small differences?
The different scenarii discussed during the meeting did not permit to reach a conclusive position.

Statistics: Posted by colancto — 18 July 2017, 15:20

]]> 2017-06-27T14:26:04+00:00 2017-06-27T14:26:04+00:00 http://www.cape-open-forum.org/viewtopic.php?t=552&p=1865#p1865 <![CDATA[Thermo SIG • June 27, 2017 conference call]]> A case was made for providing a mechanism to request from a Chemical Reaction Package Manager the creation of a blank Chemical Reaction Packages. For sure such a Chemical Reaction Package is of no immediate usage and needs to be configured before being exercized in any type of calculations. It is seen as an issue that such a mechanism is not specified for Property Package Managers and this absence is not providing a suitable behavior from all Property Package Managers. An end-user could decide to create a Chemical Reaction Package from scratch, relying on the configuration user interface provided within a Chemical Reaction Package to carry this task, from within the process modelling environment the Chemical Reaction Package is rather than doing such a task outside the PME.
Such a mechanism could be added to the methods carried by the ICapeChemicalReactionPackageManager interface, along with the two methods already defined for this interface, one to get the list of Chemical Reaction Packages handled by the Chemical Reaction Package Manager and one to return a Chemical Reaction Package designated to the Chemical Reaction Package Manager through its name. The same mechanism could be implemented also as a separate interface that could be carried both by a Property Package Manager and by a Chemical Reaction Package Manager.
It has not been decided yet what makes for a better design.
Being able to create a blank Chemical Reaction Package comes also in support of what we called de-persistability. Indeed the latest errata and clarifications published regarding the Thermo and Physical Properties interface specification in version 1.1, addresses a point there: "In case Property Packages can be persisted, the situation is somewhat more complex. The Property Package may have been created at a different computer, or the list of available property packages may have changed since the property package was first created. In this case, GetPropertyPackage returns an uninitialized Property Package, that keeps track of the name that was specified. In case the Property Package had been persisted, a call to Load will follow, and the Property Package receives its configuration data. In case Load is not called, the Property Package still need to receive its configuration data during Initialize. An invalid name passed to GetPropertyPackage leads to an error in Initialize.So passing an invalid name to GetPropertyPackage may lead to an error immediately for Property Package Managers of which the Property Packages cannot be persisted, or may lead to an error during Intialize if the Property Package if persistence is supported but the Property Package was not loaded from persistence.
In either case, the PME has the responsibility to expose to the user any textual error message provided by the Property Package."
What we aim to avoid is the above sequence that carries a number of possible pitfalls.

Statistics: Posted by colancto — 27 June 2017, 14:26

]]> 2017-05-02T12:04:29+00:00 2017-05-02T12:04:29+00:00 http://www.cape-open-forum.org/viewtopic.php?t=542&p=1825#p1825 <![CDATA[Thermo SIG • May 2, 2017 conference call]]> An existing section within the overall introduction was split and re-distributed within the "Design" sections of each part. Subsequent steps in the document development were listed, prioritized and assigned. After ensuring that the files developed in Microsoft Visual Studio are kept embedded in the Word document for consistency, any reference remaining about hierarchy of reactions will be searched and deleted by Jasper, in accordance with the previous decision made about removing this hierarchy from the design. From the reading made by Mark and Bjorn, it appears that the explanations provided in the text about Delegate Material Objects as well as contextual compound slate, need to be made clearer. Mark and Bjoern have taken up this assignment.

Statistics: Posted by colancto — 02 May 2017, 12:04

]]> 2017-04-12T21:33:09+00:00 2017-04-12T21:33:09+00:00 http://www.cape-open-forum.org/viewtopic.php?t=532&p=1792#p1792 <![CDATA[Thermo SIG • April 11, 2017 conference call]]>
We further progress the interface specification document on Chemical Reaction Packages. Specifically we revised the section on Chemical Reactions, getting rid of a number of paragraphs referring to the hierarchy of reactions we have decided to get rid of for the sake of simplicity and also the difficulties encountered with making use of that hierarchy to automatically provide for choices / checks by clients of a Reaction Package. Rather than dealing with exclusive sets of reactions within a single Chemical Reaction Server, we are now feeling that allowing for separate Chemical Reaction Packages for ealing with exclusive sets is easier to handle from a developer point of view.

We improved the way two Use Cases involving a Reactor as Actor were redacted. What seems particularly necessary in Use Case 009 was to state clearly that a Reactor may rely on the static information of any Chemical Reaction as being constant, till a new validation of the Reactor is performed. This is particularly true of the reaction stoechiometry, of available but also of whatever descrives a reaction.

Statistics: Posted by colancto — 12 April 2017, 21:33

]]> 2017-03-28T13:30:32+00:00 2017-03-28T13:30:32+00:00 http://www.cape-open-forum.org/viewtopic.php?t=522&p=1771#p1771 <![CDATA[Thermo SIG • March 28, 2017 conference call]]>
The list of attributes for information on Compound Slates (Compound Slates are different representations of a mixture in terms of Compounds), was revised once more with a discussion on the necessity to propose two descriptions of a Compound Slate; a short one and a longer one. In the end, we retained only one description, meant to help the end-user determines between several Compound Slates (names of Compound Slates may be not enough to decide which to choose). Relying on an external source to supply information on a given Compound Slate was rejected for the moment. It would have been too involved within such a specialized interface. So it appears that the description of the two methods carried by ICapeThermoCompoundSlateCollection interface is now finalized.

Next we discussed the proposal made by Mar STIJNMAN to suppress the hierarchy within reactions. Such a feature is preently in the proposed design. Such a hierarchy has been introduced a while ago to help reaction package providers to hide their proprietary information as well as to let the end-user organize his/her choice of the reactions relevant to the current context. It also supports the use of one single Property Package carrying internally a Reaction Package. Decision has been made to suppress the hierarchy. The design will still let a reaction package provider expose a pseudo-overall reaction instead of the detailed scheme.

Version 0.87 of the interface specification document on Reactions has been released to the Thermo SIG. Next conference call is scheduled for April 4 with deleting parts related to the hierarchy of reactions in the document.

Statistics: Posted by colancto — 28 March 2017, 13:30

]]> 2017-03-21T21:54:33+00:00 2017-03-21T21:54:33+00:00 http://www.cape-open-forum.org/viewtopic.php?t=520&p=1764#p1764 <![CDATA[Thermo SIG • March 21, 2017 conference call]]> Nevertheless, at the previous conference call on March 14, an additional Use Case was considered necessary and introduced. It describes how the list of Compound Slates supported by a Compound Server is made available to a Unit Operation.
On March 21, the wording describing this new Use Case was slightly revised. A new item was also introduced in the glossary of the Reaction Package interface specification document. It pertains to the Default Compound Slate. Further more the description of the GetCompoundSlateCollection method was slightly revised before moving on to the description of the GetCompoundSmateInfo method which gives access to a number of attributes of any given Compound Slate. Tje design chosen leaves the door open to additional attributes while the specification lists a number of mandatory and optional attributes such as type (true or apparent), reactive or not, etc...

Statistics: Posted by colancto — 21 March 2017, 21:54

]]>