Chemical Engineering June 2019 - 56

Modeler
Relative
amount of
time spent
interacting
with the model
Iterative process
One-off
specific
answer
Final model uses
FIGURE 3. The end use of the model will dictate the relative amount of time both the modeler and the
problem owner will spend with the model
Critically though, the appropriate
description depends on the end use
of the model.
Model use
The relative levels of interaction of
the problem owner and the specialist
modeler with the model is highly
dependent on its final use and anticipated
results (Figure 3). Recognizing
this will ensure that maximum utility
can be gained.
Figure 3 distinguishes among three
likely outputs of modeling work, on a
continuum of usage conditions. First
is a case where the desired output is
a single answer to a specific question
(Case 1), such as an estimation
of a physical property for a chemical
process. For this case, interactions
between the model and the
owner may be very limited, with the
modeler generating the information.
In order to ensure successful value
delivery, the two parties must jointly
develop the following:
* A clear definition of the problem
and objectives in the wider context
of the full project
* A statement of the model's limitations
with respect to applicability
and prediction uncertainty
The latter is common to all modeling
work but is especially relevant to this
example, as the owner has no plan
to return to the modeler for additional
work. Should he or she do so,
the relationship between the modeler
and the owner moves toward a more
iterative process scenario (Case 2).
Such a situation requires significantly
more effort on the communication
front. Let us consider an
example where the problem owner
requires modeling of chemical yields
for a process at different conditions
(Figure 4).
A mechanistic model can be built,
based upon the correct identification
of the governing phenomena
within a specific process envelope.
Such a model is based on a causal,
first-principles description of these
phenomena. The owner can then
apply the model to predict outputs
under different conditions within the
pre-defined model operating range
only. The inherent challenge here is
Model
handover
Problem owner
to have the problem owner provide
the right input to the modeler, since
model revisions outside the original
envelope are out of scope. This requires
both an understanding of the
limitations of the model, and an appreciation
of the fact that poor input
data will generate poor results.
The final case is one in which the
aim of the modeling exercise is to
create a flexible tool that will be delivered
to the owner for recurring use
(Figure 3, Case 3). This type of activity
is perhaps the most challenging,
because it presents the greatest risk
of misunderstanding between modeler,
owner and even the model.
Consider the example of a plant
process unit where the owner is
the site manager. The site manager
wants to improve scheduling around
that unit operation by simulating the
impact of a wide range of operating
parameters. In this instance, there is
a large potential for one of two possible
pitfalls:
* Incorrect model development (for
instance,
over-simplification
or
over-complication) due to insufficient
understanding of the process
and its drivers by the specialist
modeler
* Incorrect use, and therefore value
delivery, due to incomplete understanding
of areas of applicability
Useful systematic practices that can
help to circumvent these issues include
project kick-offs and peer
reviews, together with formal technology-transfer
packages, and a
follow-up on tool use (in terms of not
just the science but the implementation
support that is needed).
and
Conditions
and
and
and
FIGURE 4. The ability of a model to predict the outcome of a specific reaction for a variety of reactants is
largely dependent on the input quality of the problem owner, who needs to foresee applications beyond
its original request from the onset
56
Delineating usage conditions
The discussion above on model
uses is necessarily quite abstract,
but highlights the need to be clear
on condition of use. The use of a
metaphor can be useful in such a
situation. Figure 5 uses an analogy
based on medicine to facilitate communication
between the modeler
and the end user.
Here the model is compared to a
diagnostic tool. In a first instance, the
objectives are defined based on context
- that is, the patient is sick and
there is a need to determine what has
caused the sickness. This leads to
ongoing discussions that define the
requirements, and the later developCHEMICAL
ENGINEERING WWW.CHEMENGONLINE.COM
JUNE 2019

http://WWW.CHEMENGONLINE.COM

Chemical Engineering June 2019

Table of Contents for the Digital Edition of Chemical Engineering June 2019