The User-added subroutine capabilities of PRO/II enable third-party developers and end-users to develop their own simulation programs and interface them with PRO/II. Unit operations, thermodynamic methods, ahd reaction simulators are some of the many types of user-added subroutines supported by PRO/II.
Currently, the user-added unit operation interfaces in PRO/II are undergoing a significant upgrade. The intent is to make this new interface the preferred method of model integration for third-party development partners of Simsci and end-users alike. Work began in PRO/II version 6.0, but it still is not complete. These enhancements are being developed in parallel to the existing user-added subroutines. That means the existing user-added subroutines will not be replaced, and will continue to function well into the future.
Here is a brief overview of the new interface architecture that is being developed.
New DLL interfaces. User-added unit operation models can be developed independently, outside PRO/II. This eliminates the need to rebuild or recompile any PRO/II libraries. When building the model initially as a stand-alone application, the user-model developer should modularize the data initialization (access) and data persistence (storage). Then, to interface with PRO/II, all that is needed is to replace those modules with the appropriate PRO/II user-added interfaces. No modifications should be needed in the calculation code. The new interfaces are encapsulated in their own DLL. The user project merely links against the export library of the PRO/II interface DLL to access the interfaces. (Of course, the code that actually uses the interfaces needs to be written.) So far, all the new interfaces are written in Fortran 90.
Existing UAS naming conventions are removed. New user-added unit operations support names up to 32 characters. The user of a new unit operation makes PRO/II aware of the new unit by registering the model in the P2UASReg.ini file. This is a one-line plain-text process.
Data storage is unbounded. The concepts of IPAR, RPAR, SUPPLE and HEAT data are deprecated. Instead, the model developer defines, assigns identifiers, and attaches units of measure to data entities of his own choosing.
All floating-point data are REAL(8); i.e., double precision. Each floating-point data entity may be either a scalar or a single-dimension array of any extent.
Each integer data entity must be a scalar. Each integer supports a 32 character identifier.
Text data is supported. Each text entity is a scalar string. The maximum number of characters allowed in each text entity is declared in the "INI" file. A 32 character identifier is supported by each text entity.
Units of Measure may be associated with each floating-point data entity. All UOM classes provided by PRO/II are supported by the new data structure. Additionally, the user may declare the specific unit of measure used to transmit data between the user model and PRO/II. For example, a developer may declare a float array of 10 values named TOUT. This could be assigned the UOM class of TEMP (temperature) and the unit of R (Rankine). During input and report processing, PRO/II handles TOUT as an array of temperatures. When TOUT is passed from PRO/II to the user model, PRO/II passes the values as Rankine temperatures. Upon returning TOUT from the user model to PRO/II, PRO/II expects the values to be returned as Rankine temperatures.
All data mapping, naming, and UOM assignments are accomplished in a configuration file (i.e., an "INI" file). The developer of the model writes this INI file using a simple plain-text template supplied by SIMSCI. One unique "INI" file may be created for each model.
Floating-point data entities may be made available to the Generalized Spec/ Vary/ Define system of PRO/II by mapping them as PARameter entries in the INI file. Floats not available to the Generalized Spec subsystem are mapped to DBL storage. In version 8.2, only scalar floats may be mapped as PARameters.
The new UAUOP supports multi-sided unit operations. For example, a typical heat exchange would be considered to have 2 sides (one hot, the other cold; or shell and tube, etc.) A distillation column with 5 side strippers might be considered to have 6 sides. Each side supports a 32 character identifier and any number of feeds and products. Each side also supports one thermodynamic method set. So far, reactor models containing up to 37 sides have been developed with no problems.
A new "context flag" informs the user-model of the operations PRO/II expects it to perform. This is an enhancement over the ISOLV flag in the older user-added subroutines. Contexts include input processing, data cross-checking, flowsheet calculations, output-pass calculations (after flowsheet convergence), and report generation. This allows the model developer to preemptively perform these functions instead of depending upon PRO/II.
A new "AutoGui" has been ported into PRO/II from Romeo. This allows model developers to create custom graphic input interfaces by writing XML configuration files that define the layout and content of multiple-paned input windows. It allows using the more contemporary "tabbed-pane" metaphor. This is a vast improvement over the former "Custom Data Entry Window".
The new data interface routines use text-driven arguments. The user model accesses and stores data by using the data identifiers (that the model developer defined) in the INI file. The new interface routines access and store data for components, streams, and the unit operation itself.
Pseudo Products in Modular UAUOP
Starting PRO/II v10.1 Modular UAUOP supports pseudo products. Similar to existing pseudo products of other unit operations, Modular UAUOP’s pseudo products also shown as dotted lines in the flowsheet and not included in the overall plant material balance calculations.
To configure a pseudo product there is an option in the ini file’s [Sides] section. See “Modular UAUOP - Defining A New UAUOP INI File” for more information.
Sample UAUOP with Pseudo Products (UaUOP_EX_2) available with PRO/II V10.1, see Ex2Uop.ini and ExUop2_2013.sln for more information.
Stepwise procedure to add new UAUOP
Registering a new UAUOP with PRO/II
Hints for defining new ini for the new UAUOP
New Interface functions for managing Component, Stream, and unit op data