System Design

Data and Methods

Introduction

The next task is to think about what will be needed to make models, to run numerical simulations, and to appraise or interpret the results, in later steps of the SAF. The contents of the task concern decisions about whether existing models can be used or new models developed, what software should be used, and what data will be needed. This task overlaps with those described in the next step, 'System Formulation'. However, experience has shown that it's best to begin data gathering as early as possible.

Identify software, methods and formats

Your choice of modeling tools is crucial.

The box at the end of this page may help your choice. If possible, adapt existing models and use familiar software. Making a simulation model from scratch is time-consuming.

Economic dimension and methods

You may also need to revisit the economic aspects of the Virtual System and to think about methods for economic assessment of the results of simulation modelling. Consult the report on the economic dimension of coastal systems by Mongruel et al., 2011 (pdf).

Begin to aquire data

Some of the generic types of data that you need to think about getting are shown in this diagram.

diagram showing data needs for system modeling

Start by querying public data bases (such as those of meteorological information). After this, consult other sources, including the scientific literature and your stakeholders. If needed data can't be found, can you simulate them with an accessory model (e.g. to calculate sunshine as a function of latitude and year-day), or adapt information from a similar coastal zone? Only if all else fails, should you consider the expensive and time-consuming process of measuring what you need.

That's all we have to say, here, about this subtask. More detailed information concerning 'data' is presented in the level 2 instructions for 'System Formula




BOX: the choice of software and the use of modelers

At the start of the SPICOSA project we had thought that conceptual modelling was (merely) a step on the way to the making of simulation models during 'System Formulation'. We further thought that the subject specialists who learned to use the ExtendSim software would be able to create a library of validated 'model blocks' - for example, containing algorithms for simulating phytoplankton growth decision making in water supply - which could be drawn on by other modellers, so that an Issue-related Virtual System model could be assembled quickly. In effect, the software was chosen to support 'collective rationality' in model-building.

There was such rationality in model building, and it was aided by the use of a common software tool, but, we learned, it mainly involved two things that we had not expected: the use of conceptual models to bring the disciplines together with each other and the Reference Group, and the swopping of modeling experience between skilled and trainee modelers. The task of drawing up a complete library of validated and user-friendly blocks proved beyond the resources available to the project, although example blocks are available from the SPICOSA model library. (You will need the ExtendSim software, and familiarity with Extend 'library files' to view them, and also will require to be registered with the site.) If you want to explore ExtendSim, the suppliers ( www.extendsim.com) provide a demonstration version of the software, and the manuals by Maes (2009a) and Maes (2009b) introduce its use in the context of coastal zone systems.

This is what we learnt from the SPICOSA project, and now recommend:

  • think about the modellers as well as the software and the model; if your SAF application is stand-alone (i.e. you don't need to swop model code with other groups), use software with which your modelers are already familiar;
  • you need someone with generic skills in systems theory and conceptual modelling as well as generic modellers who are (if possible - they take a long time to train) already skilled in mathematics, programming, and running and testing models;
  • the strategic software choice - between programming languages and ikon-based modelling software - is best dictated by existing skills and by cost issues concerning licenses;
  • ikon-based models are easier for non-modellers to understand - to some extend they explicitly represent the conceptual model in the simulation model;
  • the chosen software should include a library of routines for numerical integration, handling data-sets, graphing output and comparing it with observations;
  • try to avoid reinventing wheels: once the Virtual System has been conceptualized, review the relevant discipline-based literatures for appropriate mathematical formulation of each process that you want to include in the simulation model, and seek code libraries containing well-tested algorithmic implementations of these formulations.

Next step