gPROMS overview – modeling language and facilities

Powerful, clear and concise language. gPROMS language reads like "mathematics expressed in English" rather than FORTRAN. And of course, because it is not necessary to include any numerical sotion techniques in your model (that is taken care of automatically by gPROMS), all you see are the equations describing the actual physics and chemistry of your process.

This clarity means that models are easily maintainable and auditable.

Distributed systems modelling. gPROMS was the first advanced process modelling platform with distributed system handling.

Variables can be distributed in a number of dimensions, which may represent spatial dimensions (for example, axial or radial concentration distribution of concentration along a fixed bed reactor) or, for example particle size or molecular weight distribution.

Distributions can be set up and named arbitrarily – for example, "AXIAL" and "RADIAL" for space dimensions; "MWD", for molecular weight distribution of a polymer, or "PSD", for describing a crystal particle size distribution.

Steady-state and dynamic modelling. gPROMS's Integro-Partial Differential Algebraic Equation (IPDAE) formulation provides complete modelling power for steady-state or dynamic modelling – gPROMS makes no distinction.

Dynamic models can easily be solved for steady-state simply by setting the appropriate model specifications – there is no need to iterate to a steady-state.

Full array handling. gPROMS handles arrays of up to a practically unlimited number of dimensions, consistently and robustly.

The concept extends all throught the gPROMS language: it is possible – for example – to have an array of units or ports within a unit. Zero-length arrays are also possible, to allow – for example – the construction of models where reaction may occur, but is not always present.

Powerful discontinuity handling. Numerous mechanisms for handling process discontinuities, including CASE statements, make it very easy to model conditional behaviour. Discontinuities are robustly and efficiently handled by gPROMS's numerical solvers.

Ability to model complex operating procedures. gPROMS's hierarchical task language means that it is easy to describe operating procedures, including start-up and shutdown and complex batch operating policy.

Once procedures are implemented within gPROMS's task language, dynamic optimisation can be used to determine the optimal operation – for example, the minimum start-up time achievable within equipment and operating constraints.

Ability to model experiments. gPROMS includes an experiment modellng language. This allows experimental data to be represented correctly to gPROMS's parameter estimation routines.

It also provides information for gPROMS's model-based experiment design facilitie's whic can be used to design experiments that maximise experimental information content.

Hierarchical (object-oriented) modelling structure. Flowsheets can contain flowsheets, which can contain flowsheets … and so on, ad infinitum. This provides complete flexibility of modelling, and makes models easy to maintain and re-use.

gPROMS has comprehensive facilities for propagating parameter and other information correctly through the hierarchy.

Easy description of optimisation problems. gPROMS's dynamic optimisation capabilities allow easy description of an arbitrary objective function, with interior-point and end-point constraints and many other features.

As a consequence, it is very easy to add significant value by optimising a design or its operation once you have been through the effort of building a robust underlying model.

Enumerated domains: ordered sets. You can use text descriptors as array indices in gPROMS, making it easy to refer to mass_flow('methane') or evaporation('volatiles') for example.

This makes models easy to follow, easy to maintain and smaller in size, thereby reducing solution times.

Powerful initialisation language. A traditional criticism of equation-oriented models is that, while they run much faster once initialised, it is difficult to obtain an initial solution.

gPROMS's state-of-the-art initialisation language captures modellers' experience in a structured way to eliminate this problem.

Easy calls to external software such as physical properties routines or MS Excel®.

External functions are simply called from within the equation; the actual resolution of the call (for example, a fugacity call to a physical property package) can be resolved at runtime.

This means that models can be written completely generically, without having to know which actual external package will be present at solution time.