LIBPF® Model User API manual


Model developers use the full, low-level LIBPF® C++ API to develop process models. Once a process model is complete and tested, it can be deployed to model users as a calculation kernel or remotely-accessible service supporting a predefined set of model types.

Programmatic access to the models via scripts or automation is possible using the same C++ LIBPF® low-level API used during development.

But the low-level API is too complex for the model user role, therefore a high-level Model User API is provided, as a subset of the full C++ API, accessible via:

Intended audience

System integrator and client developers who want to develop solutions based on the modeling of industrial continuous processes with the LIBPF® enabling technology.


This document is a starting point for the LIBPF® Model User API, a simple, high level API to manage and use process models who have been previously prepared and deployed by model developers.



The Model User API involves the following objects:


Cases are top-level instances of model types. They are complex objects, and have the following properties:


Variables are contained in models and can be:

Variables have the following properties:

Additionally Quantities can be one or of both of:

  1. inputs: user-supplied values

  2. results: values calculated by LIBPF®

Naming constraints

Model tags must be unique among siblings, i.e. within the direct descendants of a model.

Nothing bars duplicate tags at different locations in the hierarchy like in A:A:A:A or A:(B (A, B)). Therefore tags can not be used to uniquely identify objects and sub-objects in a tree.

Full tags are unique in each tree, but nothing bars creating different trees containing with equally fulltagged models.

Variable tags are unique among each of the different variable groups (Strings, Integers are Quantities) of a model: we can have T as a Quantity, and as an Integer and as a String in the same model.

Models and Variables can be arranged in multi-dimensional arrays:

Multi-dimensional arrays are in general indexed with 0-based integers using the square bracket operators [-] and [-,-], but for collections indexed by the components (such as composition vectors or coefficient matrices) the components names can be used as keys.

The model tag must have the first character of alphabetical type. The following characters can be alphanumeric or space or ,-_{}<>. Thus .:[] are excluded.

The model description must have the first character of alphabetical type. The subsequent characters can be alphanumeric or space or .,:-_{}<>[].



Instantiating and using a Case

Cases can be instantiated via the Kernel createCase method by supplying:

The model developer can set up model types such that their construction process can be steered by passing certain String and / or Integer options. This feature is used for example to configure multi-stage unit operations (passing an integer nStage to set the number of stages), to set-up feed stream compositions based on pre-sets (i.e. setting the “feedType” option to “MSW”, “cow manure” etc.) or to define process conditions (i.e. settings the “processType” option to “high-temperature”, “low-temperature” etc.).

The available model types and their configurability options are accessible via the Kernel API so that each LIBPF® application / service is self-documenting. These information are made available via the listTypes and listEnumerators methods.

Once a Case has been instantiated, the Kernel createCase method returns a Handle object that can be used to access the Case instance at any time.

Any future access to this Case instance must be performed by instantiating a Model User API Case object, passing the Case instance Handle to it.

The Model User API Case object allows the following operations on a Case instance: