Environmental Engineering Reference
In-Depth Information
' book and work through it—
it's a very slow and demoralising way to learn. A user manual is a necessity, but as
a reference guide, not a tutorial. The best way to learn is to get hold of a simple
model that someone else has written in the language that is similar to the one that
you want to write (e.g. the one in the Appendix to this chapter). You could ask
colleagues or even write off to the authors of the paper you have been using. People
are usually happy to share their source code. Go through the model and try to
understand what each step means, and in particular, find the equations at the heart
of the code. Change them and see what effect it has. Substitute their equations for
others (e.g. for the logistic equation). The difficult bits that you absolutely need to
If possible, don't just buy a 'teach yourself C
Box 5.1
Tips for successful programming.
Model-building is a slow and laborious process that involves great attention to
detail. Ensuring that you have a model that is doing what you think it is doing is
the longest part of this—but it is vital in order to ensure that there are no nasty
surprises later when you come to use the model predictively.
●
Use easily distinguishable, short meaningful names for your variables,
ideally linked to the notation used in building your conceptual model. This
makes the code more readable and so reduces errors.
●
Indent your loops (e.g. for time or for multiple simulations), one indent
per loop.
●
Comment everywhere—notes to yourself and others about what the code is
doing.
●
Modularise the programme, so you have variable definitions in one file, sub-
programmes (units) in another, and only the bare bones of input and output
in another. If your code is one long document, it is much harder to debug.
●
Declare all your variables up front and NOT inside the code. This is impor-
tant for spreadsheet models as well. It is virtually impossible to change vari-
ables for sensitivity analyses without causing errors unless you have just one
place in which the variable is changed.
●
Debug the model carefully and deliberately, starting inside each function in
turn and then moving out. There will be mistakes, so aim to detect them.
●
In debugging runs, start with the deterministic model, and use extremes for
each variable, as this is where bugs often occur. What happens when a vari-
able (such as population size or travel cost) is zero? Does the model blow up?
●
At each stage, predict to yourself what the result of a particular set of inputs
will be—particularly using extreme values, and doing it a function at a time
then joining them together. Run the model and see if the prediction is borne
out. If it isn't, why not?
●
Never let it rest if you can't explain the output—always keep digging until
you can.
