This edition first published 2017 © 2017 by John Wiley & Sons, Ltd
Registered Office
John Wiley & Sons, Ltd, The Atrium, Southern Gate, Chichester, West Sussex, PO19 8SQ, UK
Editorial Offices
9600 Garsington Road, Oxford, OX4 2DQ, UK
The Atrium, Southern Gate, Chichester, West Sussex, PO19 8SQ, UK
111 River Street, Hoboken, NJ 07030‐5774, USA
For details of our global editorial offices, for customer services and for information about how to apply for permission to reuse the copyright material in this book please see our website at www.wiley.com/wiley‐blackwell.
The right of the author to be identified as the author of this work has been asserted in accordance with the UK Copyright, Designs and Patents Act 1988.
All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording or otherwise, except as permitted by the UK Copyright, Designs and Patents Act 1988, without the prior permission of the publisher.
Designations used by companies to distinguish their products are often claimed as trademarks. All brand names and product names used in this book are trade names, service marks, trademarks or registered trademarks of their respective owners. The publisher is not associated with any product or vendor mentioned in this book.
Limit of Liability/Disclaimer of Warranty: While the publisher and author(s) have used their best efforts in preparing this book, they make no representations or warranties with respect to the accuracy or completeness of the contents of this book and specifically disclaim any implied warranties of merchantability or fitness for a particular purpose. It is sold on the understanding that the publisher is not engaged in rendering professional services and neither the publisher nor the author shall be liable for damages arising herefrom. If professional advice or other expert assistance is required, the services of a competent professional should be sought.
Library of Congress Cataloging‐in‐Publication Data
Names: Fairley, Jerry P., author.
Title: Models and modeling : an introduction for earth and environmental scientists / Jerry P. Fairley.
Description: Chichester, UK ; Hoboken, NJ : John Wiley & Sons, 2016. | Includes bibliographical references and index.
Identifiers: LCCN 2016024807 (print) | LCCN 2016033087 (ebook) | ISBN 9781119130369 (pbk.) | ISBN 9781119130383 (pdf) | ISBN 9781119130376 (epub)
Subjects: LCSH: Earth sciences–Mathematical models. | Environmental sciences–Mathematical models.
Classification: LCC QE33.2.M3 F35 2016 (print) | LCC QE33.2.M3 (ebook) | DDC 550.1/5118–dc23
LC record available at https://lccn.loc.gov/2016024807
A catalogue record for this book is available from the British Library.
Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be available in electronic books.
Cover image: iStockphoto/Alexander Shirokov
To my father, for teaching me to do math one step at a time.
This book is accompanied by a companion website:
www.wiley.com/go/Fairley/Models
This website includes:
Before serious discussion on any topic can take place, it is usually necessary to define one’s terms. In the present instance, we need to ask the following question: “what, exactly, do we mean when we speak of a ‘model’?” A reasonable definition of the term might be a simplified or idealized representation of reality. Although this is a pretty broad definition, it is perhaps the only one that really embraces everything we refer to as “a model.”
In order to better understand what is, and what is not, a model, we can examine some possible examples. Which of the following would be considered models?
Of course, by our definition all of these things would qualify as models. Students will sometimes argue that “an atom” is a physical object and, therefore, not a model. However, everything we know about atoms comes from observing their effects, and our understanding and depiction of atoms has changed and evolved over time. In fact, our current understanding of atoms and subatomic particles is so far outside our everyday experience that our descriptions are entirely probabilistic. As a result, I maintain that any discussion of “atoms” is necessarily a discussion of models—simplifications and idealizations of things that are beyond our direct knowledge.
In this book, we will primarily concentrate on a subset of models known as mathematical models. A mathematical model is a kind of model that is formulated in terms of mathematical concepts such as constants, variables, functions, derivatives, and so on. The nominal goal of a mathematical model is to give quantitative indications of the behavior of some aspect of a system.
Note that I said we would primarily be concentrating on mathematical models. In fact, the word “primarily” glosses over an important fact about the development of mathematical models: every mathematical model is the quantification of an underlying conceptual model; that is, a mathematical model is the quantification of our idea of how a system works. This is a very important, but often overlooked, aspect of model development. The fact is that model development requires many decisions to be made about which aspects of the system are important, and which aspects may be neglected. If the decisions are poor, a poor model will result. If the decisions are good, a good model may result (no guarantee). In any case, before a mathematical model can be developed, it is first necessary to define a conceptual model, or conceptual understanding of the system. The usefulness of the quantitative model, and the reliability of its representation of the system, will be wholly dependent on this conceptual understanding.
Another aspect of models that is deserving of discussion is the uses to which models may be put. A sample of these might be the following:
Of these, the use of models as propaganda is probably the most common application for models (e.g., think about the usefulness of fashion models and model cars in selling products). It is tempting to think that “scientific” (i.e., mathematical) models are exempt from issues of partisanship, but this is far from the truth. Because every model is a quantification of an individual’s conceptual understanding, all models are developed from a partisan point of view; that is, every model contains bias! Therefore, the first step in evaluating any model is to understand the motivations and biases of the developers.
Another topic it would be appropriate to touch on is model fallibility. It is not uncommon to hear statements similar to “it must be true, because the model says so,” and models are commonly depicted in popular culture as unfailing guides to the future. In reality, the knowledgeable modeler understands that a model embodies our conceptual understanding of some system, and is therefore incomplete and prone to error. Furthermore, there are an infinite number of alternative models that could be devised to represent any given system. Since it is impossible to test all the alternatives for a superior model, a model can never be shown to be the “true” representation of a system.
It is also easy to make the mistake of thinking that a model is reliable because it has been “validated” or “verified.” In my opinion, the idea of “model validation” is misleading at best; it implies that, because a model has produced good results in the past, future predictions may be taken uncritically. In fact, every new prediction or new situation to which a model is applied will take a model into scenarios outside of the conditions for which it was calibrated and tested. Under these circumstances, the modeler must always be alert to the possibility that new processes, changes in parameters, or insufficiencies of the underlying conceptual model will cause the model to fail.
Instead of using the terms “validated” or “verified,” I prefer to think in terms of confidence building. If a model performs well when tested against observations, we gain confidence in the model’s output, and each additional test increases our confidence. We retain our confidence as long as the model continues to perform reliably; however, we never lose sight of the fact that, at some time in the future, the model parameterization or underlying conceptualization may be insufficient for the task at hand, and the model may fail. Keep in mind that, although a model can never be proven to be “right,” it only takes one counterexample to prove it wrong.
Usually, models are created for some useful purpose—to understand some phenomenon, plan some test, or make some prediction—and I am a believer in the idea that models should be useful. However, I would be less than honest if I didn’t say that one of the reasons for developing models was the pleasure to be had in their development. I believe this is as good a reason to develop a model as any, and perhaps better than many others. As you work through the models presented in the following chapters, I hope that a little of the enjoyment and gratification that comes from working with models will shine through.
Regardless of whether the subject to be modeled is a groundwater flow system, the growth of a bacterial colony, the flight of a projectile shot from a cannon, or any other system, the construction of a model is not a simple step‐by‐step procedure. Because the modeler must make decisions about which processes should be included in the model and which will be neglected, what domain will be used, and so on, the development of a model is as much art as science. Notwithstanding the creative aspects of model development, there are some simple but important rules that should be followed. In this section, we will examine three basic rules for model development, briefly discuss some important aspects of model formulation, and make some suggestions for evaluating a model’s performance. These rules and suggestions will form the basis for all of the examples of model development in the following chapters.
How to develop a model of a physical system, when to believe and when not to believe the model output, and how to determine whether the model predictions have any relevance to real life are common and central questions that must be answered by the would‐be modeler every time a new situation is encountered. Most commonly, modelers are shown how to use a software package (or asked to read the documentation for a software package), and then assumed to be sufficiently competent to produce reliable predictions of system behavior. Even a moment’s reflection will show that this is a nonsensical way to go about learning the craft of modeling, and this attitude has been largely responsible for the proliferation of bad models and the subsequent lack of confidence in modeling (and modelers).
Ideally, a modeler would gain experience and a deep understanding of the process of model development while working as an “apprentice” under a skilled modeler. This desirable state of affairs is seldom met with in the real world, however. The purpose of this book is to provide some guidance for those aspiring modelers who do not have the advantage of serving such an apprenticeship. Although not a substitute for the teaching and advice of an experienced modeler, it is to be hoped that the rules and examples in this and the following sections will at least keep the novice modeler from falling into some of the more obvious pitfalls associated with the mathematical modeling of physical systems.
It is probable that, over time, many hundreds of “rules” have been made up regarding the construction, evaluation, and application of mathematical models. Most of these purported rules would be better classified as “suggestions,” “considerations,” or even, in some cases, as “superstitions.” Over many years of making and using models, however, I have become convinced that the following three cardinal rules should be followed at all times in the development of a mathematical model:
In my experience, all three of these rules are routinely overlooked by modelers, and many poor and inappropriate models have resulted. We will briefly consider each of these rules here, but, more importantly, they are bound into the fiber of every model developed in the following chapters.
It is common for a modeler to start a modeling investigation with the objective of “making a model of the aquifer” or with a similarly vague idea of what is to be accomplished. I cannot state strongly enough that a modeler must know exactly what s/he is trying to accomplish before ever putting pen to paper (or typing an input parameter). The more precisely the objectives of the model are known, the more likely the investigation will be successful. Make a habit of writing down the objective of your model, and be ready and willing to reduce your objective to a single sentence. The objective “to model the wells in the Grande Ronde Aquifer” is a very poor statement of purpose; a better (although still insufficient) objective is “to determine the influence of pumping well MW‐4 on nearby wells.” Better yet (and possibly sufficient to begin an investigation) is “to estimate the change in head in wells MW‐1 and MW‐3 that results from a 24‐hour constant rate pump test in well MW‐4.” The examples in the following chapters always include a statement of that which is to be found; hopefully, after working through the examples, the reader will have a clear idea of how to formulate model objectives. Although the temptation to “just get modeling” and “show some results” may be strong, you will always be better off if you first make certain you understand exactly what it is you want to achieve, and formulate a plan to reach that goal.
Hydrogeologists and environmental scientists are often working in data‐poor environments. There is usually little to be gained from building a three‐dimensional (3D), coupled saturated–unsaturated zone model with heterogeneous property sets when the only data to constrain the model come from a single aquifer test. Often in these situations a simple analytical model will give results that are as reliable as (or more reliable than) a complex numerical simulation. Furthermore, complex numerical simulations are often misleading, since it is tempting to think that, because they are complicated, they are realistic. What non‐modelers (and many modelers) are unaware of is the fact that any computer model is solving the same equations that the modeler can write down with a pencil and paper. If there are few data to support the added complexity in terms of spatially varying properties, time‐dependent recharge or boundary conditions, and so on, then the complicated numerical simulation may in fact be a worse representation of the system than a greatly simplified analytical model.
It should be said that many clients, regulatory agencies, and other downstream users of model output will push for complex numerical simulations in spite of the paucity of data to support such simulations. Although economic, political, or regulatory pressures may force a modeler to undertake the development of 3D simulations when only 1D simulations are justified, or a transient model when a steady‐state model would do, the modeler should at all times be aware of the limitations of the models s/he is working with. By following Rule 3 (Section 1.2.3), the savvy modeler will be able to develop the more complex model demanded by the client while still maintaining her or his integrity and a high standard of modeling ethics.
When faced with a complex and difficult real‐life situation, it is tempting to start out by developing a model that includes the most important processes. For example, if the goal is to understand the impact of a pumping well on other nearby wells, a novice modeler might want to build a model that includes variations in the rate of pumping, recharge from rainfall or snowmelt, the influence of changing water levels in a nearby lake, and other similar items that are clearly needed for a realistic representation of the system. The problem is that there is no way, in such a complex conceptualization, for the modeler to determine if the model output makes sense or not. Your first attempt at modeling a system should always be the simplest possible representation. Rather than modeling a 3D transient system, begin by modeling a 1D or 2D steady‐state system with no source terms or other complexities. Although this may not be a realistic representation of the system, at least the modeler will know if the results are reasonable. Next, the modeler may add a spatially and temporally constant source term; again, evaluate the results. Do they make sense? Can you convince yourself the output is reasonable? If so, add another complexity, reevaluate, and so on, until the final product is one that you both understand and believe in. Never go on to the next step until you have complete confidence in, and an intimate understanding of, the current step—as well as all the steps that lead to the current step.
Particularly with regard to Rule 3 (Section 1.2.3), one may rightly ask the question: “how do I know my model is giving reasonable results?” There is no easy answer to this question; in part, knowing a model is giving reasonable results is the product of experience with models. There are, however, some simple suggestions that can help to uncover problems with a model; these are described in the following text.
The quickest way to begin an examination of model behavior is to check the behavior of a model in the limits. What is the model behavior at time ? What about as ? If you set a parameter to 0 or check the limit as it goes to , is the result what you would expect? These kinds of tests are most readily carried out with analytical models, but, with some ingenuity, they can usually be applied even to complex numerical simulations.
Even very complex numerical simulations are based on a few well‐known equations such as the Laplace equation, Poisson’s equation, and the transient diffusion equation. Each of these equations implies particular behaviors, and you should check to make certain your model is behaving in a fashion that accords with your understanding of the underlying governing equations. (We will examine the characteristic behaviors of the most common equations in the following chapters.) Check for maxima and minima, look at the curvature of the predicted model surface, and examine any discontinuities in the output. Are these features present (if you expect them) or not (if you don’t expect them), and are they in the appropriate places? It is a good sign if your expectations, based on your understanding of the characteristics of the governing equations, are realized. If the behavior you observe in your model output is different than your expectations, you need to understand why these differences arise before moving forward.
Whenever possible, you should nondimensionalize your model (nondimensionalization is described in Appendix A, and illustrated throughout this text). Note that, although you will rarely be able to nondimensionalize a commercial simulation package, the model is based on mathematical equations that can always be nondimensionalized. Nondimensionalization carries with it a number of benefits; in particular the following:
As was stated in Section 1.1, following the rules and suggestions laid out in this chapter won’t guarantee success, nor will it make you a modeler (only time and experience will do that). Hopefully, however, the ideas presented here will help you avoid some of the most common traps that inexperienced modelers tend to fall into. In the following chapters, I will develop a number of models; as you follow these developments, watch for the application of these basic principles. Ask yourself how you could apply these principles to your own problems. As with any creative endeavor, there are rules and guidelines that can be applied, but the ultimate responsibility for the final product belongs with the artist.