[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]/includes/bbcode.php on line 112: 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 2017-07-28T15:59:05+00:00 http://cape-open-forum.org/feed.php?f=36 2017-07-28T15:59:05+00:00 2017-07-28T15:59:05+00:00 http://cape-open-forum.org/viewtopic.php?t=561&p=1877#p1877 <![CDATA[COBIA: CAPE-OPEN Object Model • July 26, 2017 conference call]]>
The call was dedicated to the review of the proposal of a Common interface specification for reporting. While not specific to COBIA, the proposal is taking advantage of COBIA to be shaped, defined, prototyped and tested.

Currently the only Process Modelling Component on which a reporting interface is defined is the Unit Operation (ICapeUnitReport). Indeed Unit Operations may need to provide information to the end-user that cannot be just made available through parameters, or even if this can be made available through output parameters, the meaning of these parameters being limited to the PMC, there is a need to report on these in a more elaborate way, which leads to a report. The "may need" is important here and the specific reporting interface for Unit Operation is non mandatory since a number of Unit Operations may not need to provide any report.

It may be noted that nothing prevents another type of Process Modelling Component to implement the ICapeUnitReport interface which is part of the Unit Operation interface specification. But its name seems to make it specific to Unit Operations and Process Modelling Environments have not been developed to look at such an interface on other types of PMCs that Unit Operations.

Within the development of the Flowsheet Monitoring interface specification, it appeared necessary to provide for reporting by such a PMC. Rather than defining such a reporting interface as specific to Flowsheet Monitoring, it seemed more reasonable to look for a common interface specification providing reporting capabilities.

It could be envisioned that such a reporting capability is of use also to PMCs like numerical solvers in order to report on their convergence path for instance.

Another issue seemed necessary to address. With the ICapeUnitReport interface, only plain text reports were considered at first. Looking back to when this interface was designed, it is not surprising. Other formats of reports could come handy. The Errata and Clarifications document issued on the Unit Operation interface specification proposed a work-around to let HTML-based reports be handled. Using NamedValues within SimulationContext, a PME may advertise that it supports HTML-type reports and the Unit Operation may catch this information and accordingly issue its reports in such a format. Having a generic reporting common interface enables us to modify the workflow, letting the PMC advertise to the PME in which formats reports may be issued and then the PME may request this report in this format. Apart from plain text and HTML, it is envisioned that additional formats supporting images could be considered.

So far reports are provided as a whole by a PMC and embedded by the PME in their entirety within the PME report. Another enhancement could be to define a report using XML and a common document object model between PMCs and PME. That way, the PME could choose to extract parts of a PMC report for inclusion in its own report. Not sure that will be easy to achieve since it relies on a common understanding of what a PMC issues within a report. Still could be worth the try.

Note that at this stage, such an interface is a proposal and there is no rush to adopt it. Especially COM-based PMCs and PMEs will still be able to use the ICapeUnitReport interface since COBIA and COMBIA will tackled the interpretation of calls to ICapeUnitReport or its implementation as the new reporting interface.

Your feedback on this proposal is welcome.

Statistics: Posted by colancto — 28 July 2017, 15:59


]]>
2017-07-14T06:56:03+00:00 2017-07-14T06:56:03+00:00 http://cape-open-forum.org/viewtopic.php?t=558&p=1873#p1873 <![CDATA[COBIA: CAPE-OPEN Object Model • July 13, 2017 conference call]]>
Starting from comments provided by Michael HALLORAN from the Interoperability Special Interest Group of CO-LaN, the motivations for the solution proposed were discussed and developed.

From the start the CAPE-OPEN standard did not develop its own persistence mechanism. Take a look at the document describing persistence and you will find that it relies solely on COM persistence. Since COBIA is out there to replace COM in whatever it is used for CAPE-OPEN, COBIA needs to develop its own persistence strategy. CAPE-OPEN imposes that any PMC implements at least one of the following COM persistence interfaces: IPersistStream or IPersistStreamInit. But any PMC may also implement other COM persistence interfaces and these may match (or not) the persistence strategy applied by a given PME. So a PME typically tries first its preferred persistence strategy by asking a PMC if it supports it, then falls back on either IPersistStream or IPersistStreamInit if its preferred persistence interface is not there. That leads to some complexity on both sides. Since COBIA is meant to simplify the implementation of CAPE-OPEN, it appeared a bad choice for COBIA to just reproduce the same persistence arrangement as with COM. Better go for a single persistence mechanism. But this is obviously debatable.

It is worth pointing out that the single choice made for COBIA in terms of persistence is not supposed to impact existing COM PMEs and PMCs. COMBIA is there to make interoperabilty work in terms of persistence. A COM PME will be able to persist a COBIA PMC since the COM persistence interface, either IPersistStream or IPersistStreamInit, sought after by the PME on the COBIA PMC, will be present in COMBIA and capable to translate into the COBIA persistence mechanism. So a COM PME won't need to be modified regarding persistence. Same for the other way round.

Next comes the persistence technology chosen by COBIA. COBIA is developing a persistence mechanism which will lead to human-readable persisted data. It seems the proper way to ensure that over time persisted data is still accessible. So a COBIA PMC will provide to a COBIA PME its object data in a serialized form. The COBIA PME will then execute its flowsheet persistence in any way it thinks fit. But at least COBIA won't prevent the whole flowsheet persistence to be in a human-readable form.

You are welcome to provide feedback on the above general motivations. More details will be provided later on.

Statistics: Posted by colancto — 14 July 2017, 06:56


]]>
2017-06-29T06:48:46+00:00 2017-06-29T06:48:46+00:00 http://cape-open-forum.org/viewtopic.php?t=554&p=1867#p1867 <![CDATA[COBIA: CAPE-OPEN Object Model • June 29, 2017 conference call]]> The discussion topic was the threading model to be chosen for COBIA. Should COBIA allow for a Process Modelling Component (PMC) to be called from a different thread that the one it was created in? Is there a business case for this requirement or would it be "sufficient" to organize for duplicating a PMC in a different thread? Same applies to objects such as a Material Object.
Opinions are mixed on these matters and their implications somewhat unclear. Would such requirements involve merely defining the contract passed between components or require code development in COBIA middleware? One difficulty is that using multiple threads in process simulation software does not seem yet widespread but could be spreading. If you have an opinion on these matters, you are welcome to contribute to the analysis.

Statistics: Posted by colancto — 29 June 2017, 06:48


]]>
2017-04-12T21:23:31+00:00 2017-04-12T21:23:31+00:00 http://cape-open-forum.org/viewtopic.php?t=531&p=1791#p1791 <![CDATA[COBIA: CAPE-OPEN Object Model • April 12, 2017 conference call]]>
On the agenda was to finalize appendix 1 of the COBIA Phase II contract that CO-LaN is entering with AmsterCHEM. A decision was reached regarding the software tool to be used as IDL parser generator.

Next we discussed how to address quad precision through CAPE-OPEN interfaces in COBIA. Nowadays quad precision is seldom used in process simulation software, at least to our knowledge. There have been here and there usage within a specific component but no export out of the component of values in quad precision. So there is no urgency to provide for quad precision through CAPE-OPEN interfaces. Still what matters is to give to COBIA an architecture that will let address quad precision in some future. Methods & Tools SIG provided its analysis of the possible solutions to CO-LaN Management Board for consideration.

Last some progress was made on a document developed within M&T SIG and meant to describe the changes induced by COBIA in the CAPE-OPEN specifications. VARIANTs are replaced by a CapeValue type and its equivalent for arrays. Seems necessary to look some more in consequences for thermodynamic methods such as GetSinglePhaseProp. Thermo SIG will address that as soon as possible.

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


]]>
2017-03-23T09:49:18+00:00 2017-03-23T09:49:18+00:00 http://cape-open-forum.org/viewtopic.php?t=521&p=1767#p1767 <![CDATA[COBIA: CAPE-OPEN Object Model • March 22, 2017 conference call]]> COBIA Phase II will deliver tools to developers in order to help them develop CAPE-OPEN PMEs and PMCs based on COBIA. This phase calls for a COBIA IDL to be developed and this development introduces a number of changes to the CAPE-OPEN specifications (while retaining the capability to interoperate between COM-based and COBIA-based software). The changes will be valdated by each SIG that controls the specific part of the CAPE-OPEN standard covered by these changes. In order to guide SIGs in their upcoming review, the Methods&Tools SIG is developing a document summarizing and rationalizing the changes. On March 22, 2017 he document was further progressed and its completion is expected by the end of March 2017.
The document covers general COBIA IDL aspects, choice of data types (reduced number compared to current standard leading to COM-based implementations), elimination of VARIANT in specification, persistence design, new CAPE-OPEN Parameter interface design (mostly to get rid of VARIANT), etc... COBIA development gives CO-LaN the opportunity to correct some flaws in CAPE-OPEN going from typos to exception handling (at least in one case).
The document being prepared may ultimately be publicly released but this has not been decided yet. Remember that COBIA is open sourced.

Statistics: Posted by colancto — 23 March 2017, 09:49


]]>
2017-03-17T13:16:17+00:00 2017-03-17T13:16:17+00:00 http://cape-open-forum.org/viewtopic.php?t=519&p=1761#p1761 <![CDATA[COBIA: CAPE-OPEN Object Model • Phase I: steps involved]]> Statistics: Posted by colancto — 17 March 2017, 13:16


]]>