Chemical Engineering MagazineChementator Briefs
Sulfur control Preferential Oxidation Catalysis — a new catalytic solution…
Chemical Engineering MagazineBusiness News
Plant Watch Perstorp will construct new plant for sodium formate…

Comment PDF Processing & Handling

Improving Mathematical Model Development and Implementation

By Christophe Grosjean, Anita Rea, Patrick M. Piccione |

This article provides practical guidance for engineers and highlights the importance of combining mathematical skills, domain expertise and proper communications

The role of mathematical models in chemical engineering keeps increasing, to the point that some engineers become specialized “modelers.” To combine mathematical skills, domain expertise, and usage conditions more effectively, all forms of communication and the exchange of information between modelers and their customers must be given proper attention. Some guidelines and recommendations are discussed below.


What are models?

Models are representations of reality — conceptual, mathematical or a combination thereof. They are flexible, simplified versions of complex real systems for which there is a desire to better understand and predict how the systems work or what types of outputs they can produce.

Models are ubiquitous in scientific endeavors, and, over the years, process modeling of physico-chemical systems has become a valuable tool for the engineer. Mathematical models built from first principles, or using pre-existing modules, have the ability to save time and material, and also improve quality, efficiency and safety during process and product design, troubleshooting or optimization studies. The ability to work with models that also interact iteratively with experimental capabilities and efforts can help to optimize overall resources.

The required complexity and accuracy of a model is generally governed by its desired purpose, although a flexible design allows users to address simple queries upfront with the option of extending the efforts to more complex interrogation later.

Model development

As shown in Figure 1, the modeling process can be broken down into several steps that are essential for successful value delivery. All steps need direct involvement from both the problem owner and the modeler:

  1. Defining the questions to be answered
  2. Conceptualizing the process into (the correct) phenomena
  3. Model building, that is, translating the phenomena and its parameters to mathematical expressions and validating assumptions and predictions
  4. Model use

As an aspirational goal, most chemical engineers should be able to perform an element of model design and could theoretically complete the cycle shown in Figure 1A themselves. However, by necessity, mathematical models are often developed by specialists. Such designated “modelers” apply mathematics to translate the system under study, using core engineering principles, to its underlying equations. The majority of the “problem owners,” on the other hand, help to relate the model to the process at hand and the practical operating parameters they know will impact the model output.

These complementary, yet seemingly opposed approaches stem from a healthy differentiation of scope, remit and job objectives. Ideally clear interactions are required to ensure that the purpose (and hence resulting value proposition) of the model is not lost on the end owner, and the model itself is well-designed and fit for purpose (that is, Figure 1C is a preferable operating model over Figure 1B).

Echoing a recent call for improving communications throughout the chemical engineering community, this article draws attention to the crucial role communication has on model development and its many uses [1].



Assuming the underlying chemical engineering problem or challenge has been carefully defined by its owner, a first step in the development cycle is to identify the key phenomena that will lead to using the appropriate equations to describe the process. In the case of a model that relates to evaporative drying, for example, the main chemical engineering phenomena considered would be heat and mass transfer (Figure 2).

FIGURE 2. Evaporative drying is a classic engineering example of concomitant heat and mass transfer

The conceptualization step, and the next (model building), will ensure that a sharable support (document) for knowledge retention is created by the very process of model development.


Model building

Following conceptualization, the identified key phenomena can be translated in different mathematical ways. For instance, the transport of water out of solid materials during drying can be described using either diffusion or capillary movement (or both) [Equations (1) and (2)].


Drying and diffusion theory:




Drying time using the capillary theory:




w = Total moisture, kg

t = Time, s

DL = Diffusion coefficient (liquid phase), m2/s

l = Thickness, m

w0 = Initial moisture, kg

weq = Equilibrium moisture, kg

tf,cap = Drying time based on the capillary theory, s

Qs = Density of the dry solid, kg/m3

hfg = Latent heat of vaporization, J/kg

h = Heat transfer coefficient, W/m2K

Tabs = Absolute air temperature, K

T’S = Evaporative surface temperature, K


The most appropriate description will depend largely on the nature of the material and the amount of water to be removed. The decision will be supported and validated by either purposefully designed experiments or historical data.

Critically though, the appropriate description depends on the end use of the model.

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

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).

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

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 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).

FIGURE 5. For a given set of symptoms, several diagnostic tools are conceivable. However, the end use alone can direct the development of the tool

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 development of a diagnostic tool.

However, it is the eventual use of the tool that will determine its design. The expected use could be a simple one-off answer to support triage (Case 1 in Figures 3 and 5), in which case a diagnostic based on temperature (for instance, using a thermometer) might be sufficient.

In a more extreme case, if a new pathogen is suspected, DNA sequencing could be envisaged to determine the cause of the sickness (Case 3). In this instance, the diagnostic tool can be used to both gain insight and make decisions.

An intermediate case is that of fast preliminary assessments, for which a new type of field microscope might be sufficient (Case 2). The medical analogy presented here provides a simple illustration of tool differentiation (in this case, model development) based on final usage to ensure appropriate design.

All modeling tools are unique and their usages vary from one project to the next. Nonetheless, only with effective, targeted communication between the user and the modeler can value be delivered. Aspirationally, with modern software, modeling will become a more accessible activity so there will not be a distinction between modelers and problem owners — rather, all users will be able to do some model development. In the meantime, you must think carefully about how to foster the most effective communication among all parties the next time you integrate modeling into your workflow.



1. Brennan, D., Speaking out, The Chemical Engineer (TCE; IChemE), February 2015, p. 44.


Christophe Grosjean is the technology and innovation lead for formulation engineering at Syngenta AG (Breitenloh 5, 4333 Münchwilen, Switzerland. Phone: +41 62 868 5686; Email: christophe.grosjean@syngenta.com). He holds a chemical engineering degree from IUT Le Montet (Nancy, France), and a Ph.D. in physical organic chemistry from Durham University. After further postdoctoral studies at Durham, he joined LyraChem Ltd, a start-up company established from a collaboration between Newcastle and Durham universities’ chemical engineering and chemistry departments, respectively. During that time, he was responsible for the process modeing, experimental studies, and reporting of business projects. Grosjean joined Syngenta in 2013, and has worked on a number of process modeling projects, supporting the seeds and active ingredients parts of the business.


Anita Rea is process studies manager at Syngenta’s International Research Center (Bracknell, Berkshire RG42 6EY, U.K. Phone: +44 1344 41 4102; Email: anita.rea@syngenta.com). She holds a Ph.D. in Biophysics from the University of Notthingham, and was a postdoctoral researcher at the MRC Laboratory of Molecular Biology (LMB) in Cambridge, U.K. In her current role, Rea leads a cross-disciplinary department of engineers, chemists and physical scientists in the application of fundamental science to the development, manufacture and formulation of agrochemical active ingredients.




Patrick M. Piccione is the head of formulation and process sciences at F. Hoffmann-La Roche (Grenzacherstrasse 124, 4070 Basel, Switzerland. Phone: +41 61 687 7510; Email: patrick.piccione@roche.com). He spent seven years in materials development at Arkema, followed by nine years at Syngenta, leading process engineering science. At Syngenta, Piccione also led a division-wide mathematics and data-science strategy, which prominently featured models together with their development and dissemination. He holds B.S. degrees in chemistry and chemical engineering from MIT, as well as an M.S. in chemical engineering practice, and a Ph.D. in chemical engineering from the California Institute of Technology. He has co-authored more than 30 journal and proceedings articles on various topics. He is a Chartered Engineer and Fellow of the IChemE, and is currently serving on the Executive Board of the European Federation of Chemical Engineering.

Related Content

Chemical Engineering publishes FREE eletters that bring our original content to our readers in an easily accessible email format about once a week.
Subscribe Now
Minimizing Explosion Risk Where Other Solutions Cannot
Minimizing Corrosion with Fast, Robust Gas Analysis
Lower Measurement Point Costs with Automatic pH Sensor Cleaning
Reduce the Risk of Corrosion in Fertilizer Production
3 Reasons to Automate Sensor Cleaning

View More

Live chat by BoldChat