Comparing modelling frameworks e A workshop approachlikbez.com/AV/PUBS/Argent_etal.pdfto compare three frameworks e the Spatial Modelling Environment (SME), Tarsier and the Integrated

www.elsevier.com/locate/envsoft

Environmental Modelling & Software 21 (2006) 895e910

Comparing modelling frameworks e A workshop approach

R.M. Argent a,b,*, A. Voinov c, T. Maxwell d, S.M. Cuddy b,e, J.M. Rahman b,e,S. Seaton b,e, R.A. Vertessy b,e, R.D. Braddock f

a Department of Civil and Environmental Engineering, The University of Melbourne, VIC 3010, Australiab Cooperative Research Centre for Catchment Hydrology, Australia

c Gund Institute for Ecological Economics, University of Vermont, USAd Geo-Spatial Technologies, Inc., USA

e CSIRO Land and Water, Canberra, Australiaf Griffith University, Brisbane, Australia

Received 31 August 2004; received in revised form 5 May 2005; accepted 10 May 2005

Available online 26 July 2005

Abstract

Of concern to the environmental modelling community is the proliferation of individual, and individualistic, models and the time

associated with common model development tasks such as data transformation, coding of models, and visualisation. One way ofaddressing this problem is the adoption of modelling frameworks. These frameworks, or environments, support modular modeldevelopment through provision of libraries of core environmental modelling modules, as well as reusable tools for data

manipulation, analysis and visualisation. Such frameworks have a range of features and requirements related to the architecture,protocols and methods of operation, and it is difficult to compare the modelling workload and performance of alternativeframeworks without using them to undertake identical, or similar modelling tasks. This paper describes the outcomes of a workshop

to compare three frameworks e the Spatial Modelling Environment (SME), Tarsier and the Integrated Component ModellingSystem (ICMS). A simple environmental problem linking hillslope flow and soil erosion processes with a receiving water store wasdesigned and then implemented in the three frameworks. It was found that the SME and Tarsier contained many components wellsuited to handling complex spatial and temporal models, with ICMS being an integrated framework tailored for smaller scale

problems. Of the three tested frameworks, the SME proved superior in supporting problem description, Tarsier provided moreflexibility in linking and validating the model components, and ICMS served as an effective prototyping tool. The test problem, andassociated data and parameters, are described in detail to allow others to undertake this test.

Crown Copyright � 2005 Published by Elsevier Ltd. All rights reserved.

Keywords: Model integration; Integrated modelling; Module-based; Component-based; Tarsier; Spatial Modeling Environment; Interactive

Component Modelling System

Software availability

Program title: SME (Spatial Modelling Environment)Developer: Thomas MaxwellContact address: Source Forge at http://www.source-

forge.net/smodenv

* Corresponding author.

E-mail address: [email protected] (R.M. Argent).

1364-8152/$ - see front matter Crown Copyright � 2005 Published by Els

doi:10.1016/j.envsoft.2005.05.004

Year first available: 1997Hardware required: UNIX workstation, Linux PC,

Mac OS XSoftware required: CCC compiler; optional extensions e

TCL/Tk, HDF, MPI, PostgresProgram language: CCC, JavaProgram size: w1 MB source archive; binary size

depends on platformAvailability and cost: open source

evier Ltd. All rights reserved.

http://www.sourceforge.net/smodenv

http://www.sourceforge.net/smodenv

mailto:[email protected]

http://www.elsevier.com/locate/envsoft

896 R.M. Argent et al. / Environmental Modelling & Software 21 (2006) 895e910

Program title: TarsierInitial developer: Fred WatsonCurrent developers: Fred Watson, Joel Rahman, Shane

SeatonContact address: [email protected] first available: 2001Hardware required: Intel x86-based PCsSoftware required: OS Windows (2000, NT and above)Program language: Borland CCC BuilderProgram size: Total source: 241 K linesAvailability: Available for research useCost: Not applicableProgram title: Interactive Component Modelling System

(formerly Integrated Catchment ManagementSystem)

Developer: CSIRO Land and Water; CooperativeResearch Centre for Catchment Hydrology

Contact details: Available at http://www.cbr.clw.csiro.au/icms/

Year first available: 1998Hardware required: Minimum Pentium I, 32 bit

Windows, 64 MB RAMProgram language: System constructed with Delphi;

component models written in MickL, a C-likesub-language

Program size: w15 MB (with plug-ins)Availability: Apply on-line at http://www.cbr.clw.csiro.

au/icms/Cost: Nil.

1. Introduction

Modelling is a common activity in many branchesof science and engineering, and the use of computersimulations in environmental teaching, research andmanagement is widespread. There exists a spectrum ofmodelling approaches that are used to address environ-mental problems, often divided on the basis of level ofdetail and the treatment of time, space or entities, andclassified as discrete/continuous, coarse/fine, dynamic/static, lumped/distributed, deterministic/stochastic, ordescriptive/mechanistic (e.g. Chorley and Haggett, 1967;Shannon, 1975; Novotny, 1986; Peart and Curry, 1998;Wastney et al., 1999). Across this broad spectrum manyareas of environmental modelling use common con-cepts, problem structures and tools, arising froma simulation discipline developed during the 1960s and1970s (e.g. Shannon, 1975) and often presented in morediscipline, problem or software specific ways in recenttimes (e.g. Peart and Curry, 1998; Wastney et al.,1999).

Despite the existence of the common discipline ofsimulation modelling, individualistic modelling styles areapparent in many research institutions where models are

developed, and from where models are extended to fulfileducational and management roles. Even within just partof the modelling spectrum such individualism includesselection of time and space scales, levels of detail inmodelling, methods of collating, analysing and pre-processing data, expression or description of problemsaddressed using modelling, choice of language andcomputing environments, approaches to output visual-isation and analysis, and the use of packaged applicationsfor any or all of these issues. Individuals and researchgroups in specific disciplines, such as ecology andhydrology, often work in particular ways, focussing onparticular parts of the modelling spectrum, and model-ling arising from one group can often be readilyrecognised by others. This is understandable as themodelling approach within a group becomes reinforcedas commonly used methods are passed from teacher tostudent, and is of particular prevalence in research groupswhere they are passed on as part of the advisory process.

Thus the environmental modelling community con-tains many groups addressing similar problem situationsusing a range of conceptual, construction and codingmethods. Examination of the proceedings of environ-mental modelling and simulation conferences (e.g.McDonald and McAleer, 1997; Ghassemi et al., 2001;Rizzoli and Jakeman, 2002) reveals repetition andreinvention of basic techniques across modellers andmodelling groups. Although thought is often given toadopting the tools or methods of other research groups,the demands of time and learning curves mitigate againstthis. Indeed, an attitude of adaptation rather adoptionis common and understandable e as researchers we liketo know exactly what is going on inside a modellingapplication, and so often prefer to work with modellingsystems we know intimately than alternative systems thatmay offer superior features.

This individualistic approach to model developmentleads to a proliferation of coded models which oftenhave little in common, except possibly basic data setsand system representation, and which are difficult tocompare with any accuracy or confidence. These modelsare also difficult to integrate when dealing with complexproblems that require the combination of multiplesystem sub-models.

Trends in software engineering and commercialsoftware development over the last 10e15 years havepromoted a modular style of software development,based often upon object-oriented concepts (Rumbaughet al., 1991), whereby individual model parts, or modules,are designed to encapsulate single concepts, promotingflexible use and supporting module reuse (Clements,1995; Zeigler, 1995; Maxwell, 1999). More recently, aspeople trained in modern software engineering methodshave entered the environmental science disciplines, therehave been attempts to develop standardised approachesto modelling in the environmental problem domain.

http://www.cbr.clw.csiro.au/icms/




897R.M. Argent et al. / Environmental Modelling & Software 21 (2006) 895e910

Within sections of the modelling spectrum dealing withdiscrete time and discrete entities many problemsand modelling tools are amenable to approaches basedupon object theory, and are readily handled usingappropriate software engineering design and develop-ment methods.

These new approaches have resulted in developmentof the concept of environmental modelling frameworkswhich bring together suites or libraries of modules, andwhich have architectures designed to fit well with thebasic and natural features of environmental problemsituations (e.g. Muhanna, 1994; Guariso et al., 1996;Bennett, 1997; Reed et al., 1999). When using frame-works in a given part of the modelling spectrum, theintentions include standardisation of features such asdata manipulation and analysis, exchanges betweenmodels and data sets, structure and coding of modules,and visualisation of model outputs. It should be notedthat the term frameworks is sometimes used to refer onlyto the underlying classes and libraries, with environmentsbeing the systems that use these software frameworks tosupport module development, model construction, andexecution. In this paper we use the term frameworks ina broad sense to include the underlying software andarchitecture as well as the module and model system.

A range of environmental modelling frameworks existand have been under development for some time, in-cluding theModularModelling System (MMS) (Leavesleyet al., 1996), the Dynamic Integration ArchitectureSystem (DIAS) (Sydelko et al., 1999), the InteractiveComponent Modelling System (ICMS) (Rizzoli et al.,1998; Reed et al., 1999), Tarsier (Watson et al., 1998), theSpatial Modelling Environment (SME) and associatedmodule specification formalism (Maxwell, 1999; Voinovet al., 1999, 2004; Costanza and Voinov, 2003), TIME(Rahman et al., 2003, 2004), the Object ModellingSystem (OMS) (David et al., 2002) and the EuropeanOpen Modelling Interface and Environment (OpenMI)initiative, taking place under the 5th European Frame-work Program project HarmonIT (Gijsbers et al., 2002).

These frameworks provide an avenue for easiermodelling of classes of environmental problems, andpromise to relieve the modelling practitioner of a major-ity of the simpler and more repetitive coding tasks as wellas the repetitive modelling tasks associated with man-agement of input data and visualisation and analysisof output. Eventually these frameworks will free themodelling community so that they can focus more fullyon the system being modelled and the model structure,allowing core development, interpretation and manage-ment requirements to be addressed more fully.

A problem for potential users of modelling frame-works lies in gaining an understanding of the methodsof operation, the modelling styles supported and theadvantages, disadvantages, features and functions ofalternative systems. Written examples of application,

and even construction and operation, provide consider-able relevant information, but fall short of providing theexperience of actual use that can assist a user in theselection of a particular system, or provide a greaterunderstanding of the most appropriate system to use ina given problem situation. Also, application examplesrarely, if ever, report on development in more than onesystem, and comparison of such systems.

One way to gain experience of multiple frameworks isto sit down with users of various systems in a workshopenvironment and attempt to construct a given model ineither one’s own, or preferably, each others, systems.This process was used with three modelling frameworks,namely Tarsier (Watson et al., 1998; Watson andRahman, 2004), the Spatial Modelling Environment(SME) (Maxwell, 1999; Voinov et al., 1999) and theInteractive Component Modelling System (ICMS)(Letcher et al., 2000).

The workshop was held at the University ofMaryland, ChesapeakeEnvironmental Sciences (UMCES)unit at Solomons, MD, in 2001. The workshop wasattended by modellers, environmental scientists, anddevelopers and expert users of the three frameworks. Allwere aware of the drawbacks of traditional ‘monolithic’modelling methods and were interested in exploringalternative approaches through the use of modellingframeworks in addressing spatio-temporal modellingproblems, such as commonly occur in areas that includecatchment (watershed) management, ecological systems,and fisheries research.

The objectives of the workshop were to devisea simple environmental problem and to developa simulation application, referred to as the ‘Solomons’model, of this problem in each of the three frameworks.

Issues that were the subject of enquiry included:

� Basic operation of each framework, including pro-gramming languages and platforms;� Alternative approaches to common functions, suchas module management, data handling and visuali-sation;� The extent to which common functions wereautomated or integrated into the operation of theframework, and the methods used for this;� The basic set of environmental modelling toolsprovided with the framework, and� The different types of modelling supported by theframework.

The aims of this paper are to report on thisexperiment, with particular objectives of comparingthe three frameworks in their application to a particularenvironmental problem. A description of the problemand provision of associated parameter and data sets(Appendix A) are also intended to provide a candidateproblem in a possible test suite for other environmental


modelling frameworks. We have also created a website(http://giee.uvm.edu/AV/Frameworks/) that describesthe modelled system and offers the associated data setsfor download. It is open for other model developers whomay wish to test their models and frameworks as part ofongoing framework comparisons.

2. The candidate problem

In developing a problem for application within thethree frameworks the intentions were to create a problemthat was not uncommon in natural resources manage-ment, which was simple enough to allow production ofa modelled solution in a two-day workshop, and whichillustrated the potential of the frameworks for applica-tion to similar, but more complex, problems in a rangeof natural resources fields. Using common equations,parameters and data focussed attention on the model-ling and visualisation capacities of the frameworks andremoved any variability arising from common modellingactivities such as pre-processing of the input data.

The Solomons model encompassed rainfall, runoff,erosion and sediment transport in a small catchment witha water storage dam at the catchment outlet. The selectedcatchment area was a small portion of the Hunting Creekcatchment, in Maryland, USA. The area is primarilyfarmland with gentle relief and low, rolling hills. Slopesare typically in the range 1e5% in the resolution chosen.A real catchment was selected to provide a focus for theactivity, to simplify data gathering, to provide a meansby which a rough compliance could be achieved betweenthe catchment slope, rainfall and soils, and so that thedevelopment had an air of reality about it.

A 16 ! 16 cell digital elevation model (DEM) wasobtained, with a cell edge length of 200 m, giving a totalarea of 10.24 km2. The elevations of a small number ofthe cells in the DEM were manipulated to ensure thata steepest-descent drainage method would force all cellsto drain to the catchment outlet. Appendix A gives theelevation data grid.

The drainage direction for the catchment area wasgenerally south, with two main streams being formed.The catchment outlet was positioned in the southern-most row (row 16) at coordinates (11, 16), and a damcovering the cell, which does not exist in the realcatchment, was considered to be positioned here for thepurposes of the exercise. The coordinate nomenclatureused here is (x-horizontal, y-vertical) rather than the(row, column) nomenclature often used with matricesand rasters.

Four soil types were identified on a cell basis for thecatchment, with the soils being clay, sandy-clay, sand,and a non-porous dam liner in (11,16). A grid of the soiltypes for the catchment is given in Appendix A. Eachsoil had associated with it an infiltration rate, that was

used in a daily dynamic soil moisture balance, anda sediment source variable.

The dam positioned at the catchment was consideredto catch sediment and also to fill and spill as waterflowed in and out, and climatic forcing varied, over time.

Daily net precipitation, given by the differencebetween precipitation and evaporation, was used asthe only climate input to the model. Fig. 1 shows a singleyear sequence of net precipitation, in millimetre. Only 1year of data was used, with repetition of this time seriesbeing possible if longer term model results were sought.Net precipitation was used to remove the problem ofdifferent frameworks implementing different schemes forhandling the combination of precipitation and evapo-ration. Precipitation was considered to be liquid, withno snow storage or melting.

The daily time-step of the input data set defined themodel time-step and imposed a discrete treatment oftime in the Solomons model, while raster spatial datadetermined a grid-based approach to spatial processes.

3. The three modelling frameworks

The three modelling frameworks were the InteractiveComponent Modelling System (ICMS), the SpatialModelling Environment (SME) and Tarsier.

3.1. ICMS

The ICMS (formerly the Integrated CatchmentManagement System) was initially developed in theLand and Water Division of Australia’s CommonwealthScientific and Industrial Research Organisation in themid 1990s. The operational concept was based upon theOpen Modelling Engine (OME) (Rizzoli et al., 1998;Reed et al., 1999), wherein linking and informationpassing is possible between different domain objects(modules), different data instances, and also betweendomain objects and data instances. The OME hasa strong class-based structure which is reflected in thedesign and operation of the ICMS. Considerable effortwas expended in development of ICMS to supportmodellers in all steps of development, from class creationand coding (using a C-like sub-language called MickL),object instantiation, data association with objects, link-ing of objects, data passing between objects, spatial andtemporal data analysis and handling and runtimeoperation. The ICMS was developed using BorlandDelphi� and operates on 32-bit Windows� operatingsystems.

The complexities of model classes, objects and datainstances are handled in a relatively straightforwardmanner within the ICMS, using tree-structures tovisualise available classes, objects existing in a model,and data attached to objects. Visualisation of model

http://giee.uvm.edu/AV/Frameworks/


Fig. 1. One year daily net precipitation series.

structure is provided by linked object icons ona modelling ‘canvas’ (Fig. 2).

Model classes can be exported into libraries, fromwhich they can be imported to form the basis ofa new model. Available libraries include rainfall-runoff,pollutant generation and routing modules. Once basicclasses are established, models can be readily con-structed by instantiating objects on the canvas, attach-ing data and linking objects. Visualisation objects, suchas charts and tables, can be attached to data outputfrom relevant objects. ICMS models are stored ina single *.ICM files, with the desktop layout for a model(e.g. Fig. 2) stored in a separate *.DSK file. The *.DSKfile is not needed when opening an existing model, but isuseful if specific visualisation tools have been selectedand attached to model objects.

Beyond the basic model representation and runtimeoperation, a more user-friendly ICMS ‘view’ can beconstructed that provides an external graphical user

Fig. 2. The ICMS canvas showing linked objects representing

components of a catchment load model.

interface (GUI) allowing simpler manipulation of modelparameters through features such as slider bars and datainput boxes.

3.2. The SME

Development of the SME started in 1992 in responseto requirements for a framework that would allowspatial implementations of models in a user-friendlyinterface such as Stella�. The origins of the SMEapproach lie in the Coastal Ecosystem Landscape SpatialSimulation (CELSS) model (Costanza et al., 1990),where the idea of a process-based simulation modelreplicated over a grid of cells was first tested. Further on,the first prototype of SME, the Spatial ModellingProgram (SMP) was developed to model the Evergladesecosystem (Fitz et al., 1996). From this grew thePatuxent Landscape Model (PLM) application (Voinovet al., 1999), which was the first full-scale landscapemodel based on the final object-oriented implementationof the SME, incorporating an open modular architec-ture. The new SME functionality, which allowed in-tegration of several independently developed Stellamodelsor tailored CCC programs, led to the LHEM (Library ofHydro-Ecological Modules) concept (Voinov et al., 2004).

The basic formulation of the SME uses Stella todevelop and test a localized system model for operationwithin one cell of the spatial model (Fig. 3). Localdynamics may be defined in terms of several Stellamodels, which are then integrated. The Stella modelformulation is translated and loaded into the SME,which puts the local model into the spatial context,offering the input/output capabilities needed to handlespatial data. This helps visualize the process and leadsto faster development times. In the current formulationof the SME, Stella runs on Windows and MacOS


Fig. 3. Cell operation visualisation using Stella as part of the SME.

operating systems, while the SME runs under MacOS X,Solaris and Linux.

3.3. Tarsier

Tarsier is an environmental modelling frameworkconstructed primarily on data sharing and messagepassing principles using the ‘observer pattern’ ofsoftware engineering design (Gamma et al., 1995).Within Tarsier all data types are identified as classes,and the kernel of the Tarsier framework manages theobjects formed by instances of these classes. Onlya single copy of any item or set of data is loaded atany given time, with pointers to the data provided to anyobject using those data.

Under the observer pattern, the objects (e.g. dataobjects) that are being pointed to are identified as usees,while the objects doing the pointing are users. In thebroader context of an environmental modelling frame-work, output visualisation tools generally act as users,and data objects, as usees. Core modules, such ashydrological or ecological routines, can be both usersand usees, as input to one module can have a pointer tooutput from another module (Fig. 4).

Message passing is used for linking between modules,so that all users of a given usee can be notified whensome change to the usee takes place. An advantage ofthis approach is relatively rapid execution times formodels of moderate to high complexity running withdiscrete time-steps, although this is influenced by thestructure of the model and the numbers of inter-connected users and usees.

In practice Tarsier operates as a modelling shell(named Tarsino) that supports rapid construction ofmodels using existing modules in the form of DLLs. Newmodules are written in Borland CCC, and are typicallycreated using Borland CCC Builder. A significant rangeof modules is currently available covering data and data

viewers, 2D and 3D visualisation, topographic and otheranalyses, and basicmanipulation tools (such as optimisersand raster manipulation). Applications using Tarsierhave included a range of hydrology tools, climate andeconomic models, plant growth, cellular automaton anda number of examples of animal migration behaviour.

Thus there were available three modelling frame-works that shared a general basic set of relevantfunctions, such as raster-based spatial operation anddiscrete time-stepping, but which exhibited a consider-able range of features and operating requirements.

4. Solomons model development

A daily, dynamic cell-based surface water balance anderosion model was implemented in each framework. Thesurface water was calculated based on the daily net

Fig. 4. Conceptual user and usee structure operating within Tarsier.

DLLs are loaded to become Usees, Usees and UserForms. These are

registered and become available for use by a model (after Watson and

Rahman, 2004).


precipitation and soil moisture storage, with daily runoffbeing the routed accumulation of excess moisture abovea given maximum storage value. In addition, each cell re-tained a balance of sediment depth accumulated througherosion and deposition processes, starting from an initialuniform sediment depth of 500 mm for each cell. Thus,the state variables at time, t, in each cell in themodel were:

� CellWater(t) Z water level (mm), (hereafter, Cell-Water)� SedimentDepth(t) Z accumulated sediment (mm),(hereafter, SedimentDepth)

Accumulated sediment is not added to the elevation,but is held available for transport with the water. Anyrouted surface water above a threshold value carriesa proportional amount of sediment to the downstreamcell. The water level and sediment amount in the dam attime, t, were also retained as state variables, taking thevalues of CellWater and SedimentDepth for cell (11,16),with calculation in these cells accounting for the damcharacteristics. The above variable names (CellWaterand SedimentDepth) were intended for explicit use ineach model to facilitate comparison of coded algorithmsand results.

The basic model used continuity of mass applied tothe movement of water and sediment through the cells,evaluated in discrete time-steps of 1 day. Within eachcell the modelled processes were infiltration, inflow andoutflow of water to/from other cells, sediment erosionand deposition. A system diagram for each cell is shownin Fig. 5.

Each of the components of in-cell soil moisture,drainage from cell to cell, and sediment movement anddeposition were modelled as explained in the following.

5. Solomons model components

The system model is described in terms of four sub-system components, each with associated algorithms

Fig. 5. A system diagram of cell water balance and sediment transport

process.

and parameters. The sub-systems are elevation anddrainage, the water balance module, sediment transport,and the behaviour of the dam.

5.1. Elevation and drainage

To provide consistency amongst frameworks, and toovercome problems of different routing schemes, a singleD-8 routing model was applied to develop the drainagepattern, or ‘‘link map’’, for this catchment (AppendixA). The cell drainage data in Appendix A uses a clock-wise directional annotation scheme, where ‘‘2’’ repre-sents flow to the north-east, ‘‘3’’ to the east, around to‘‘9’’ for northerly flow. A drainage direction of ‘‘1’’ isused for cells that act as sinks.

An ordered list of cells was generated to provide thephysical linking of the cells in the link map. This list(Appendix A) ordered cells from number 1 to 256, whereprocessing the runoff and sediment routing calculationsin the given order (1e256) ensures that all cellsdelivering sediment and water to a ‘‘target’’ cell areprocessed before the target cell. The intent was to usethis routing pattern as input in all frameworks. How-ever it quickly became clear that the SME was not ableto take advantage of this routing because the SMEsequencing does not allow a mix of vertical (cell)dynamics with horizontal (spatial) fluxing. SME as-sumes calculation of all vertical fluxes in all cells beforerunning the spatial algorithms for horizontal fluxing. Inthe SME it is possible to change the order in whichvertical processes are performed, or the sequence ofvarious horizontal routines (say, groundwater transport,versus surface water runoff), but it is not possible toalternate vertical fluxes with horizontal fluxes.

5.2. Water balance module

For a time-step of 1 day, the water balance for eachcell is calculated by first updating current CellWater forthe effects of inflow, infiltration and net precipitation, by

CellWaterZCellWaterCRinðtÞ � ICPnetðtÞ ð1Þ

where

Rin(t) Z runoff received from all upstream cellsdelivering directly to this cell, at time t.I Z infiltration of water into the soil in this cell. Thisis set as a constant for a given soil type, withinfiltration rates of 0, 1, 20, 100 mm/day for the damliner, clay, sandy-clay, and sand, respectively.Pnet(t) Z net precipitation at time t, into this cell.

;


Outflow from the cell, Rout(t), is then calculated bya piecewise linear relationship between upper and lowersoil water limits and the threshold runoff that occurs atthe upper limit, given by:

where

WLO Z low water threshold, set to a value of 2 (mm);WHI Z high water threshold, set to a value of10 (mm);RT Z runoff threshold (mm), set to 6, equal to theamount of runoff from the soil when CellWaterreaches WHI.

The relationship in 2 has a low threshold, WLO,below which runoff is not generated. Above this liesa zone, WLO ! CellWater ! WHI, where the runoff,considered to be a sub-surface fraction, increaseslinearly to the runoff threshold, at CellWater Z WHI.Above this value all water in excess runs off in additionto the sub-surface runoff.

This form of relationship was selected to providestructure in the water runoff relationship. The values ofthe coefficients are based on experience in modellingcatchments, and on the dimensions and cell size used inthe example catchment.

Finally, CellWater is updated using:

CellWaterðtC1ÞZCellWater�RoutðtÞ ð3Þ

RoutðtÞ

8<:

0ðCellWater�WLOÞðWHI�RTÞ=ðWHI�WLOÞðCellWater�RTÞ

Dam OutflowZ

�0:05)DamWater DamWater!1:05)DamHeightDamWater�DamHeight DamWaterO1:05)DamHeight

ð5Þ

5.3. Sediment transport

Sediment transport is modelled in a similar way towater flow, although the sediment depth in a cell has nolower limit, so erosion is always possible. Sedimentdepth in a cell is increased due to incoming sedimentfrom upstream and decreased with cell erosion. For anycell, incoming sediment is first added to the cell’ssediment, then outgoing sediment, Sout is given by:

SoutZ

8<:0 RoutðtÞ!SLO

STðRoutðtÞ�SLOÞ=ðSHI�SLOÞ SLO!RoutðtÞ!SHI

ST RoutðtÞOSHI

ð4Þ

where

SLO Z low sediment threshold, set to a value of 2 mm;SHI Z highsediment threshold, set toavalueof20 mm;

ST Z sediment threshold, set to 10 mm.

Similarly to CellWater, the units for sediment depthare millimetre. This approach is convenient for mixedwater and sediment calculations, where it is possible toconsider water as having a percent of sediment content,similar to the concept of soil moisture percent in soils.Model complexity could have been increased by addinga maximum total eroded depth (e.g. depth to bedrock)at which point the available erodible soil in the celldrops to either zero or the amount of soil deposited inthe cell from upstream. For the sake of simplicity andexpediency, this was not done.

5.4. Dam calculations

For purposes of model interest, a dam is defined to lieat the catchment outlet, and is identified as the dominantland use, and soil type, in the catchment outlet cell. Thedam cell has inflow from the catchment and a controlledoutflow over the dam wall, which operates only whenthe water storage is full. The water level in the dam(DamWater) is calculated by accumulation of incomingflows and removal of outflow, as for other cells, except inthis case the dam outflow is calculated by:

CellWater%WLO

WLO!CellWater!WHI

CellWaterRWHI

ð2Þ

where DamHeight Z the height of the dam wall(4000 mm).

When the dam is not overflowing, the 5% reductionin water level each time-step is used to providea diminishing outflow, to simulate an environmentalor other flow release requirement.

The depth of sediment in the dam was calculated bysimple accumulation of incoming sediment, with damoutflow deemed to carry no sediment. Normally, theeffect of sediment entering the dam would be to reducethe capacity of the dam, and therefore the volume ofwater that the dam can hold before overflowing. In theinterest of simplicity this effect was not included in themodel.


5.5. Operational setup and output recording

To test the results obtained by each implementationof the model a uniform set of parameters and initialvalues were set, and the following were recorded:

� The days on which the dam filled and overtopped� The soil depth in the dam at the end of the year.

The initial parameters were:

� CellWater value of 1 mm for all cells except the damcell. The dam was defined to have an initial waterdepth of 2000 mm.� SedimentDepth value of 500 mm for all cells.

With these initial values and the model parametersgiven in previous sections it was found that an accept-able and interesting response was obtained, with thedam overflowing four times during the year, and damsediment depth increasing by over 100 mm. Havingdefined the problem, attention turned to implementationof the Solomons model within the available frameworks.

6. Implementation of the Solomons model

Implementation was undertaken in parallel withina workshop environment, with groups working in 2e5 hblocks of time, and with occasional pauses to exchangeinformation on particular implementation problems orissues requiring clarification. A number of problems inimplementation arose during the workshop due partly toongoing definition of the example problem describedhere. The experience and understanding of the basicconceptual approach amongst the contributing scientistsand modellers meant that such development could takeplace extremely rapidly, and also that the necessary datawere on hand.

The workshop started with development of thegeneral and specific details of the model e essentiallya model design. One of the early potential problemsarose around definition of the cell drainage and flowrouting routines. By starting with a DEM there werea range of alternative cell drainage and flow routingroutines that could be used, and these were discussed atsome length. In the end, a pragmatic way around this wasto define a cell drainage directionmap e in this case a D-8map where each cell contains a value that represents thedirection to the target cell.

A second problem arose over the options for use ofprecipitation and evaporation data, and was solvedthrough provision of the net precipitation data. Theother problems that arose were related to the formula-tion of the equations and the selection of parameter andinitial values. These were generally undertaken using

a combination of previous examples and experience, andtrial and error with the example application.

The results to the operational questions were that thedam overtopped four times during the year, on daysnumber 298, 312, 341 and 343, and that the damsediment increased from an initial value of 500 mm to627.6 mm at the end of the year. The resulting timeseries are given in Fig. 6. These results were produced inall implementations of the Solomons model.

6.1. ICMS implementation

Within ICMS the Solomons model was implementedas a single ‘‘model’’ e i.e. the entire code was containedwithin one class, and instantiated as one catchmentobject. The model class contained a looped routine thatevaluated the cell water balance, sediment balance andsediment and flow routing.

The routines in order in the ICMS code moduleoperate as follows:

� Obtain the input matrix dimensions and set initialraster variables;� In a loop over all cells, in order:

+ Determine I for the current cell, add Pnet(t),calculate the water balance, then determineoutflow from the cell;

Fig. 6. Time series results of dam water level and dam sediment.


+ If calculation for the dam cell, alter the outflowso that there will be no erosion from the cell;

+ Calculate the sediment depth and transport forthis cell;

+ Route flow and sediment to the target cell;+ If this cell is the dam cell, adjust water level

according to dam rules.

Implementation of the dam operation as describedabove was not completed at the workshop due to timeconstraints and discussion of the details and interpreta-tion of the operation. This aspect was added later duringthe testing undertaken in reporting this work.

ICMS has a native time handling capability thatautomatically supports operation of any routine thattakes temporally dynamic data, and runs the model overpart or all of the period of the available data. For theSolomonsmodel, the use of time series data as the input tothe ‘NetRainfall’ data instance resulted in a temporallydynamic model covering daily operation over the 1 yearperiod set to be from1January 2001 to 31December 2001.

Total model development time within the workshopwas not recorded as there were breaks for discussion,exchange of ideas and data preparation. With pre-prepared data and a clear definition of the algorithms,such as given in this paper, the total development timecomes down to the time to code the program and attachthe data sets to the relevant data instances, a processtaking less than 3 h for someone familiar with ICMS.

An ICMS desktop was established with three chartsand two dynamic rasters, representing input net rainfall,dam water level, accumulated dam sediment depth,sediment depth in each cell, and water level in each cell,respectively (Fig. 7).

With these windows all visible on screen, model runtime was approximately 50 s on a Mobile Pentium III,850 MHz with 512 MB of RAM. With all windowsminimised, run time was 42 s, while with all visualisationwindows closed, the run time was 28 s. Having chartwindows closed during run time does not create a greatpenalty, as data is persistent and charts can be viewedafter a run. For dynamic raster data, closing windowsimposes the penalty of not seeing the dynamic visual-isation of processes operating across the catchment.

6.2. Tarsier implementation

The basic form for saving and operation of modelswithin Tarsier is a DLL that the Tarsier modelling shell,Tarsino, can load and run. These DLLs are built usingBorland CCC Builder, including a suite of Tarsiermodules that form the modelling framework. Themodel was coded into a single DLL, containing boththe core code and the declarations for using variousTarsier controls. The core code consists of routinesfor initialisation, execution and time-stepping, messagehandling, the model algorithms, and usee, data andcontrol registration. Similarly to the ICMS development,

Fig. 7. Graphical user interface view controls for ICMS, showing rasters and time series.


this module was completed after the workshop, and totaldevelopment time with clearly described algorithms anda small amount of data formatting (e.g. adding raster filedata headers) is estimated to be 4e5 h for someoneexperienced with Tarsier and the operation of thecompiler.

The GUI contained usee controls for all input andoutput rasters (Fig. 8). Data were loaded using the Opencontrol button on each usee control. Rasters and timeseries are basic data types for Tarsier, so no extra codewas needed to handle these inputs. Tarsier has an inputprocess for drainage based on a link map that uses anumbering system different to that given in Appendix A,so the correct values for Tarsier were implemented.Initial values for sediment, cell water and dam cell waterwere declared as variables and applied to cells as needed.

During execution messages are sent by all usees(mostly data, in this case) to users (visualisation routinesin this case). Despite this, runtime was quite short, beingapproximately 8 s on a 850 MHz Mobile Pentium IIIwith 512 MB of RAM.

6.3. Implementation in the SME

Models in the SME are commonly implemented usingStella to form a local single cell model, or possiblya small multi-cell model. For the Solomons model theStella implementation of the local ‘‘vertical’’ dynamicsis somewhat artificial, since there are very few localprocesses to formalize e most of the processes areintimately connected to spatial dynamics. The Stellamodel for the Solomons model is shown in Fig. 3. Thereare two state variables: ‘‘Cell_Water’’, which is locallymodified by the precipitation (a bi-flow in this case), and‘‘Sediment_Depth’’, which has no local dynamics, and is

only used to define the ‘‘S_out’’ variable. The power ofthe marriage to Stella can be appreciated when themodel is much more complex and requires a detaileddescription of local dynamics.

To run the model spatially two configuration filesare used to set up correspondence between the localvariables defined in Stella and their spatial analogues.This is done by referring the variables (such as SoilMap,LinkMap) to the appropriate files that contain dataabout these maps. The configuration files also define thefunction from the UserCode that is to be applied tomove water horizontally. For this application a functioncalled SWater1 provided the routines for moving waterand sediment.

There is some limited functionality in the SME fornearest neighbourhood connections in Stella terms.However this functionality is not suitable for theSolomons model, since water is moved to the outletrather than to a nearest neighbour during a time-step.

The SME takes the Stella equations from a file, andtranslates them into XMML (Extensible ModularModelling Language) and then to CCC. The convertedcode consisted of about 800 lines of CCC code. Likeany machine generated code, the CCC code is not veryuseful for debugging or modification. While certainchanges may be made to the XML code in XMML, it ismuch easier to incorporate all the changes in Stella, andthen archive Stella modules rather than the translatedcode. The CCC code is compiled using the gcc compilerto create an executable module.

A rough version of the model was assembled duringthe workshop, and then, similarly to ICMS and Tarsier,the model was completed after the workshop.

It is estimated that someone proficient in buildingStella models could construct the single cell model in less

Fig. 8. Graphical user interface controls for setting parameters and attaching data in Tarsier.


than 60 min. Familiarity with the SME, which canbe attained in approximately one week, would allowconstruction of the complete Solomons model, includingminor data formatting changes, in less than a few hours,provided that an appropriate module for surface waterrouting was available in the LHEM (Voinov et al., 2004).If no such module is available, fairly sophisticated CCCprogramming would be required to create the neededfunctionality. This would require at least 2e3 h froma person familiar with the SME UserCode concepts andwith knowledge of CCC.

The complete model was initially run as an applica-tion linked to the Java viewserver on a Sun SolarisUltra-5 station. The application was also run ona Macintosh Powerbook G4 under Mac OS X with512 MGB RAM, taking 32 s for the 1 year run.

7. Comparison of modelling frameworks

In setting out to compare three frameworks withreasonably different development and operating para-digms, the following features were assessed:

� Conceptual easee howhard for people to understandhow the system works, and how to make things workin the system, including the different approaches usedfor common functions, such as module management,data handling and visualisation.� Ease of development and basic operation of eachframework e including programming languages andsteps in model construction.� Support for model development e write/run sequen-ces, conversion and compilation, and running andcomparing results.� Run time features e graphs, rasters time manage-ment, go/pause/stop, dynamic visualization, suchas the extent to which common functions wereautomated or integrated into the operation of theframework, and the methods used for this.� The basic set of environmental modelling toolsprovided with the framework, and the differenttypes of modelling supported by existing featuresand libraries in the framework.

Note that most of these features are qualitative andassessment is dependent on the knowledge and experi-ence of the perceiver. Within the workshop, we wereable to compare impressions while during the post-workshop period we have manually and electronicallyexchanged further ideas and conclusions.

7.1. Conceptual ease

The SME offers a range of conceptual ease. Visual,iconic creation of ‘vertical’ local models using Stella is

convenient and conceptually straightforward, but thelanguage conversion and compilation processes and theintegration of the local model into the spatial dimen-sion add complexity. Data handling in the SME wassomewhat complex with several ASCII configurationand data files to keep track of without the benefit ofwizards, a database or some other management system.ICMS is easy to comprehend, with a straightforwardclass and object conceptual structure. The operationalconcepts are also simple, although there can be difficultywith operation of the temporal modelling aspects. ICMSalso has an elegant system for data handling, with datainstances readily viewed in a relevant form such asgraph, raster view, or table. Tarsier falls somewherebetween the other frameworks in terms of complexity,with a fairly complex control structure and registeringrequirements for users and usees, and relatively straight-forward viewing and handling of data instances.

7.2. Ease of development

Tarsier has reasonably complex requirements formodel development, including knowledge of BorlandCCC Builder and associated compilation foibles, andthe internal control and messaging structure of Tarsier.Compilation can be slow and unreliable, which adds tothe difficulties of model development. The SME is lesscomplex than Tarsier, with straightforward local modeldevelopment in Stella, andwith the ease of development inthe SME being dependent somewhat on the functionalityavailable in the LHEM. If no suitable routing or spatialfluxing scheme is available for use in the SME, then somerelatively sophisticated programming is required to createone. Pre-existing spatial code is readily visualised. ICMSprovides ready support for model development throughan internal compiler that allows rapid editing, compila-tion and running.Model creation is limited slightly by useof a specific language (MickL), although as a C derivativethe basic syntax is straightforward.

7.3. Support for development

ICMS provides tightly integrated support for de-velopment, including single button click compilationand execution, a clear visual iconic scheme for creatingmodels, and flexible visualisation tools. In the SME theability to test and develop the local model on a singlecell was quick and convenient for developers, althoughthis convenience was rapidly lost if combined local(vertical) and spatial (horizontal) development wasrequired. The Java interface, used at the time of theworkshop, is somewhat unreliable and rarely used. Incommand-line mode translation, compilation, andmodel runs were quite unattractive, though the view-server worked well to produce spatial animations.The computational power of the SME, and the ease of


formalization of sophisticated models, showed promisefor more complex projects. One of the advantages of theSME is the flexibility of the spatial methods e althougha raster grid was used in this example, the system couldhave been implemented with a triangular irregularnetwork, a regular hexagon array or other spatialarrangements. However, these arrangements are cur-rently not supported by visualisation tools, and have notundergone extensive testing. For Tarsier, the require-ment for developing the model code outside of theruntime environment was a drawback, particularly whendeveloping and testing algorithms from scratch. Tarsinosupport for loading and unloading DLLs provides someadvantages for examining the operation of differentmodels, as does the wide array of visualisation andmanagement tools for model components, parametersand data during model operation.

7.4. Run time features

It is difficult to compare the performance of theframeworks based on a single simple model. In general,though, Tarsier provided rapid model execution andattractive integration of data handling and visualisation,along with good support for run and pause in executionand support for a wide variety of common tasks withstandard tools via DLLs. ICMS runtimes were generallythe longest, particularly with visualisation running. Themodel operation and identification and selection of runtime periods are elegant and the available visualisationtools were good and flexible, covering common envi-ronmental modelling requirements. Data import wizardsprovided significant convenience in model operation.The SME runs compiled code and is therefore generallyquite fast. Changing the configuration file does not inmost cases require recompilation, which is especiallyconvenient for calibration. The output is piped into theviewserver, which is slower, but can be used independentof the simulation, allowing examination and comparisonof previous model run results.

7.5. Basic tools

All three frameworks contain a range of basic tools tosupport the common requirements for spatio-temporalenvironmental modelling. Tarsier contains a significantset of common functions, including statistics, terrainanalysis, 2D and 3D visualisation, and model calibra-tors. The ICMS package has a small tutorial set and fewinbuilt tools, covering basic spatial and temporalmodelling. The SME had very few packaged modulesat the time of the workshop, but more have beenproduced in the LHEM.

These frameworks have undergone various degreesof development since the workshop, with additionalfeatures and enhancements, many of which have

addressed issues identified above. In the time since theworkshop there have been a range of changes to the threeframeworks, in line with the nature of maturing systems.

Some of the underlying data handling mechanisms ofICMS have been improved, resulting in a considerableimprovement in computing performance. A host of otherminor and moderate alterations have also occurred,including MickL language functionality, compiler oper-ation, data importing and exporting, and visualisationtools. The system has been renamed the InteractiveComponent Modelling System to reflect both the visualand conceptual component-based nature of modellingwithin ICMS and also the potential for applicationsoutside of the catchment management area. In addition,a suite of basic hydrological modelling tools, such asrainfall-runoff, routing and pollutant generation, havebeen added to the ICMS libraries.

Development of Tarsier has also continued over thepast few years, although the framework kernel hasremained largely unchanged. During preparation of thispaper the Tarsier version of the Solomons model (namedChimp) was reloaded into Tarsier to test compatibility.Small changes were required for the model to operate,taking less than 10 min for an experienced Tarsierdeveloper. The Tarsier library of modules has also beenexpanded, with over 50 modules now available (Watsonand Rahman, 2004).

Development of the SME is currently underway toallow Internet access to the framework installed ona central server. There is a Java web portal available andnew functionality has been added. GRID technologyprovides the necessary computing power, so that userscan access SME functionality with a web browser,making it platform independent. There is a Mac OS Xversion of SME, which allows model developmentwithout need to switch from one platform to anotherwhen running Stella.

8. Conclusions

The intentions of this paper were to report on thefindings of a workshop undertaken for comparingmodel-ling frameworks, to describe the test data suite, and toprovide information on the frameworks. The second ofthese is perhaps the easiest, and the descriptions, dataand results provided here should enable readers to repeatthe test.

The workshop findings and the framework descrip-tions are more difficult to report, as they have beentempered by time, and subsequent development of theframeworks and tools reduce the relevance of some ofthe findings. However, the passing of time has alsoprovided the opportunity to reflect on the operation ofthe workshop and the advantages and disadvantages ofsuch an activity. Overall, there is still a strong positive


response amongst the authors towards the workshop.We may not have achieved what we set out to do (i.e. getthe same model running in each of the frameworks) butthe exchange of ideas and the exposure to the internalworkings of each others systems provided sharedinterest and inspiration.

Choice of a framework for developing environmentalmodels is an unclear process, which is hard to influence,and which is driven by many factors not necessarilyrelated to the particular advantages and disadvantages ofthe software packages. A comparison exercise, such asthat reported here, is a goodway to figure out the featuresand strengths of various frameworks. The method wouldbe improved if the comparison could also be performedby a group of users, independent of the frameworkdevelopers. However it is difficult to assemble sucha group, therefore we cannot entirely exclude biases in thecomparison that we have performed.

There are a number of underlying issues in theapplication of modelling frameworks that have not beentouched on here, such as of cross-framework compati-bility of modules. Generally there is almost no capacity

for sharing modules between frameworks, althoughthe XMML description of models used in the SMEis intended to allow this. Multi-framework modularmodelling may change as more modelling frameworksare developed and common standards for data andmodule sharing are developed and adopted.

The capacity shown in the workshop for groups ofresearchers to come together, understand each other andundertake comparative model development provideshope for a future where we supply our research findingsand knowledge in a modular form that can be sharedand used across a range of modelling frameworks.

Acknowledgements

The authors acknowledge the support and input offellowworkshop participants SergueiKrivov,FerdinandoVilla, Larry Band and Christina Tague.

The Australian participants acknowledge the supportof the Department of Industry, Science and Resourcesthrough Technology Diffusion Program grant No. 596.

Soil Type (11=sandy clay; 31=clay;29=sand;1=dam liner) 11 11 11 11 11 11 11 11 11 11 11 11 11 11 31 31 11 11 11 11 11 11 11 11 11 11 11 11 11 31 31 31 11 11 11 11 11 11 11 11 11 11 11 11 11 31 31 31 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 29 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 29 29 29 29 29 29 29 11 11 11 11 11 11 29 29 11 11 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 1 29 29 29 29 29

Elevation167,165,152,133,134,129,139,149,148,146,139,134,142,151,156,158144,151,156,146,132,126,132,138,141,141,136,134,145,150,150,151150,141,139,135,131,125,128,124,124,132,130,133,146,145,146,154158,151,153,146,136,128,124,123,122,124,129,133,140,140,149,154158,160,160,153,148,141,139,128,124,121,124,130,132,141,143,140155,157,157,156,152,149,140,132,129,127,120,119,130,135,134,138152,153,154,150,144,140,134,134,134,133,129,128,118,128,134,141149,150,153,151,149,147,141,138,139,141,138,130,117,128,129,137148,150,154,158,157,151,141,137,141,135,129,127,116,127,134,144147,150,151,155,157,150,141,134,134,131,126,115,127,140,144,148152,146,150,154,152,149,144,140,131,127,114,125,139,148,151,152157,145,142,143,145,146,143,143,133,123,113,134,142,147,149,150152,146,144,140,140,138,131,130,125,123,112,134,140,144,145,146155,153,150,144,139,141,140,137,133,125,111,133,136,137,140,141158,155,152,147,148,148,146,141,135,131,110,125,131,136,138,137159,155,151,149,151,149,144,140,136,131,109,121,126,133,134,135

Appendix A. Test data and parameters for Solomons model


Drainage Map (1=sink; 2=NE, 3=E, 4=SE,.... 9=N) 5 6 3 4 4 5 6 6 6 4 3 5 7 7 6 6 4 4 2 4 4 5 4 5 6 6 5 6 6 8 6 6 3 3 3 3 3 4 4 4 5 6 6 6 7 6 6 7 2 2 2 2 2 3 3 3 4 5 6 6 6 6 7 5 2 9 2 2 2 2 2 2 3 4 4 5 6 6 5 6 5 6 4 4 4 4 2 2 2 3 3 4 5 6 6 7 5 6 3 3 3 3 2 2 2 2 2 4 5 6 7 6 5 6 2 2 2 2 9 8 2 2 4 4 5 6 6 7 5 6 8 2 2 2 4 5 4 4 4 5 6 7 7 8 4 5 6 6 4 2 3 4 4 4 5 6 7 8 8 8 4 4 5 6 6 2 2 3 4 4 5 6 8 8 8 8 3 3 4 5 4 4 4 4 3 4 5 6 8 8 6 6 2 2 3 4 3 3 3 3 2 4 5 6 6 6 6 6 2 2 2 3 2 2 2 2 2 4 5 6 6 6 6 5 2 2 2 2 9 8 2 2 2 4 5 6 6 6 6 6 2 3 2 9 8 3 3 2 2 3 5 7 7 7 7 7

26 136 27 137 138 139 234 236 238 231 189 28 207 190 29 30 31 32 33 34 35 36 37 140 232 240 141 219 208 38 39 142 40 41 42 43 44 45 46 227 143 144 242 244 145 47 191 48 146 49 50 147 192 209 220 51 52 148 149 53 246 210 54 55 193 150 56 57 151 152 153 58 59 60 61 62 248 63 154 64 211 65 66 67 68 69 155 70 71 72 73 156 249 194 157 74 221 75 76 77 78 79 195 212 80 158 159 250 160 161 162 81 82 228 163 83 84 164 85 86 222 165 251 166 167 87 88 89 90 168 233 169 91 92 93 94 95 247 252 96 97 98 99 100 101 170 196 235 102 239 241 243 245 197 253 103 104 171 172 105 106 173 198 174 237 107 108 175 176 223 254 177 199 200 178 109 110 179 111 201 112 113 114 115 213 180 255 214 215 202 116 181 117 118 182 119 120 121 183 203 122 123 256 229 224 216 204 124

Cell Calculation Order 1 2 3 125 4 5 6 7 8 9 10 205 184 11 12 13 126 14 15 16 185 127 128 129 17 18 130 217 19 131 132 20 21 186 206 218 225 230 22 187 133 23 226 134 24 188 135 25

Net Precipitation Time Series 4.6,-6.4,-6.4,-6.4,-6.4,-6.4,-6.2,-6.4,-6.4,-6.4,-6.4,-1.3,-5.8,33.1,-6.4,-6.4,-6.4,-6.4,-5.6,-6.3,8.8,-6.1,-6.4,-6.4,-6.4,-6.4,-6.4,51.0,45.5,9.8,-5.5,-3.9,-4.6,-0.4,-5.0,-5.5,-5.2,-5.5,-1.1,-4.3,-3.0,-5.5,-5.5,-5.5,-5.5,-5.5,-5.5,-4.4,-5.5,-5.5,3.5,-4.8,26.9,14.2,2.9,-0.7,42.7,-5.5,-3.5,-2.6,-5.0,-5.0,-5.0,-5.0,3.0,-5.0,2.4,-5.0,-5.0,5.5,-5.0,-5.0,-5.0,27.0,-5.0,-5.0,-4.3,-5.0,-5.0,19.3,18.5,-3.9,-5.0,-5.0,-5.0,-5.0,-5.0,-4.7,32.8,-3.7,-3.7,-3.7,-3.7,-3.7,-3.7,-3.7,-3.7,0.0,-3.7,-3.1,-3.7,-3.7,-3.7,0.9,-3.7,4.2,-2.6,-2.1,2.0,12.8,4.2,-0.8,-3.6,-3.7,-3.7,-3.7,-3.7,-3.7,-3.7,-2.5,-2.5,-2.5,-2.5,-2.5,-2.5,-2.5,-2.5,-2.5,-2.5,-2.5,-2.5,-2.5,-2.5,-2.2,-2.5,-2.5,0.6,-2.5,-2.5,-2.5,-2.5,-2.5,-2.5,-2.5,-2.5,-2.5,-2.5,-2.5,-2.5,0.1,2.2,-2.2,-2.2,-2.2,-2.2,-2.2,-2.2,-2.2,-2.2,-0.6,-2.0,-2.2,-2.2,-2.2,-2.2,-2.2,-2.2,-2.2,-2.2,-2.2,-2.2,-2.2,10.2,-2.2,-2.2,-2.2,-2.2,-2.2,-2.2,-2.2,-2.2,-2.2,-2.2,-2.2,-2.2,-2.2,-2.2,-1.6,5.5,-1.3,-2.2,-2.2,-2.2,-2.2,-2.2,-2.2,-2.2,-2.2,1.0,1.4,-2.2,-2.2,-2.2,-2.2,-2.2,-2.2,-2.2,-2.2,-2.2,-2.2,-2.2,-2.8,-2.8,-2.8,-2.8,-2.8,-2.8,-2.8,-2.8,-2.8,2.9,-2.8,-0.7,-2.3,-2.8,-2.8,-2.8,-2.8,-2.8,-2.8,-2.8,-2.8,-2.8,-2.7,1.3,-2.8,-2.8,-2.8,-2.8,-2.8,-2.8,-2.8,-3.8,-3.8,-3.8,-3.8,-3.8,-3.8,-3.8,-3.8,-3.8,-1.6,-3.8,-3.8,-3.8,-3.8,-3.8,4.2,-3.8,-3.8,-3.8,-3.8,-3.8,2.3,2.8,-3.8,-0.9,-3.8,-1.8,12.5,-3.5,-3.8,-4.9,-4.9,-4.9,-4.9,-4.9,-4.9,-4.9,-4.9,-4.9,-4.9,-4.9,8.3,12.5,-4.9,-4.9,-4.9,-4.9,-4.9,-4.9,-4.9,7.5,-4.9,3.5,40.7,-1.1,67.8,-4.9,-4.9,-4.9,15.3,-4.9,-5.9,-5.9,-5.9,-4.4,-4.7,-5.9,8.7,-5.6,65.7,-5.6,-5.9,-2.9,-4.7,-5.9,0.9,0.5,-5.9,0.0,-0.6,-5.9,8.1,-5.9,6.4,-3.5,-5.9,-5.9,8.7,-5.9,-5.9,-4.8,-3.0,-5.6,-5.4,7.2,15.5,-6.5,53.1,107.5,31.7,82.9,-6.4,-6.6,-6.6,-6.6,-6.6,-5.7,-5.3,-6.6,-6.6,-6.6,-5.9,-4.6,16.3,51.4,-6.4,-5.9,-6.3,6.7,28.4,14.0,-6.3,-6.0


References

Bennett, D.A., 1997. A framework for the integration of geographical

information systems and modelbase management. International

Journal of Geographical Information Science 11 (4), 337e357.

Chorley, R.J., Haggett, P., 1967. Models in Geography. Methuen,

London.

Clements, P.C., 1995. From subroutines to subsystems: component

based software development. American Programmer 8 (11), 8.

Costanza, R., Sklar, F.H., White, M.L., 1990. Modeling coastal

landscape dynamics. Bioscience 40 (2), 91e107.

Costanza, R., Voinov, A., 2003. Spatially Explicit Landscape

Simulation Modeling. Springer-Verlag, New York.

David, O., Markstrom, S.L., Rojas, K.W., Ahuja, L.R.,

Schneider, I.W., 2002. The object modeling system. In:

Ahuja, L.R., Ma, L., Howell, T.A. (Eds.), Agricultural System

Models in Field Research and Technology Transfer. Lewis

Publishers, CRC Press, Boca Raton, pp. 317e331.

Fitz, H.C., DeBellevue, E.B., Costanza, R., Boumans, R., Maxwell, T.,

Wainger, L., Sklar, F.H., 1996. Development of a general

ecosystem model for a range of scales and ecosystems. Ecological

Modelling 88 (1e3), 263e295.

Gamma, E., Helm, R., Johnson, R., Vlissides, J., 1995. Design

Patterns: Elements of Reusable Object-Oriented Software. Addison-

Wesley, Reading, MA.

Ghassemi, F., White, D., Cuddy, S., Nakanishi, T., 2001. MODSIM

2001 International Congress on Modelling and Simulation:

Canberra. Modelling and Simulation Society of Australia and

New Zealand Inc.

Gijsbers, P.J.A., Moore, R.V., Tindall, C.I., 2002. HarmonIT: towards

OMI, an open modelling interface and environment to harmonise

European developments in water related simulation software.

Hydroinformatics 2002. Fifth International Conference on Hydro-

informatics: Cardiff, UK. IAHR, 7 pp.

Guariso, G., Hitz, M., Werthner, H., 1996. An integrated simulation

and optimization modelling environment for decision support.

Decision Support Systems 16, 103e117.

Leavesley, G.H., Markstrom, S.L., Brewer, M.S., Viger, R.J., 1996.

The modular modeling system (MMS) e the physical process

modeling component of a database-centred decision support

system for water and power management. Water, Air and Soil

Pollution 90 (1e2), 303e311.

Letcher, R.A., Cuddy, S.M., Reed, M., 2000. An integrated catchment

management system: a socioeconomic approach to water allocation

in the Namoi, Hydro 2000. In: Proceedings of 26th National and

Third International Hydrology and Water Resources Symposium:

Perth. The Institution of Engineers, Australia, pp. 953e958.

Maxwell, T., 1999. A paris-model approach to modular simulation.

Environmental Modelling & Software 14 (6), 511e517.

McDonald, A.D., McAleer, M., 1997. In: Proceedings of the

MODSIM 97 International Congress on Modelling and Simula-

tion. The Modelling and Simulation Society of Australia, Hobart,

Australia.

Muhanna, W.A., 1994. SYMMS: a model management system that

supports model reuse, sharing and integration. European Journal

of Operational Research 72, 214e243.

Novotny, V., 1986. A review of hydrologic and water quality models

used for simulation of agricultural pollution. In: Giorgini, A.,

Zingales, F. (Eds.), Agricultural Nonpoint Source Pollution:

Model Selection and Application: Developments in Environmental

Modelling. Elsevier, Amsterdam.

Peart, R.M., Curry, R.B., 1998. Agricultural Systems Modeling and

Simulation. Marcel Dekker, New York.

Rahman, J.M., Seaton, S.P., Cuddy, S.M., 2004. Making frameworks

more useable: using model introspection and metadata to develop

model processing tools. Environmental Modelling & Software

19 (3), 275e284.

Rahman, J.M., Seaton, S.P., Perraud, J.-M., Hotham, H.,

Verrelli, D.I., Coleman, J.R., 2003. It’s TIME for a new

environmental modelling framework. In: Post, D.A. (Ed.),

MODSIM 2003 International Congress on Modelling and Simu-

lation: Townsville. Modelling and Simulation Society of Australia

and New Zealand Inc., pp. 1727e1732.

Reed, M., Cuddy, S.M., Rizzoli, A.E., 1999. A framework for

modelling multiple resource management issues e an open

modelling approach. Environmental Modelling & Software 14 (6),

503e509.

Rizzoli, A.E., Davis, J.R., Abel, D.J., 1998. Model and data

integration and re-use in environmental decision support systems.

Decision Support Systems 24, 127e144.

Rizzoli, A.E., Jakeman, A.J., 2002. IEMSs 2002. Integrated assessment

and decision support. In: Proceedings of the First Biennial Meeting

on the International Environmental Modelling and Software

Society: Lugano. International Environmental Modelling and

Software Society.

Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., Lorensen, W.,

1991. Object-Oriented Modeling and Design. Prentice-Hall.

Shannon, R.E., 1975. Systems Simulation: The Art and Science.

Prentice-Hall, Englewood Cliffs, NJ.

Sydelko, P.J., Majerus, K.A., Dolph, J.E., Taxon, T.N., 1999.

A dynamic object-oriented architecture approach to ecosystem

modeling and simulation, American Society of Photogrammetry

and Remote Sensing Annual Conference: Portland, OR, USA,

pp. 410e421.

Voinov, A., Fitz, C., Boumans, R., Costanza, R., 2004. Modular

ecosystem modeling. Environmental Modelling & Software 19 (3),

285e304.

Voinov, A.A., Costanza, R., Wainger, L.A., Boumans, R.M.J.,

Villa, F., Maxwell, T., Voinov, H., 1999. Patuxent landscape

model: integrated ecological economic modeling of a watershed.

Environmental Modelling & Software 14, 473e491.

Wastney, M.E., Patterson, B.H., Linares, O.A., Greif, P.C.,

Boston, R.C., 1999. Investigating biological systems usingmodeling.

Strategies and Software. Academic Press, San Diego.

Watson, F.G.R., Rahman, J.M., 2004. Tarsier: a practical software

framework for model development, testing and deployment.

Environmental Modelling & Software 19 (3), 245e260.

Watson, F.G.R., Vertessy, R.A., Grayson, R.B., Pierce, L.L., 1998.

Towards parsimony in large scale hydrological modelling eAustralian and Californian experience with the Macaque model.

EOS, Transactions 79 (45), F260eF261.

Zeigler, B.P., 1995. Object Oriented Simulation with Hierarchical

Modular Models, Zeigler.

Documents

Comparing modelling frameworks e A workshop approachlikbez.com/AV/PUBS/Argent_etal.pdfto compare three frameworks e the Spatial Modelling Environment (SME), Tarsier and the Integrated