June 27, 2017 conference call

[colancto]

The Thermo SIG held a conference call on June 27, 2017 to progress the interface specification on Chemical Reaction Packages. Jasper van BATEN (AmsterCHEM), Mark STIJNMAN (Shell Global Solutions), Bjorn MARIBO-MOGENSEN (Hafnium Labs) attended the conference call along with me.
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.