EMS_2000_15_313-330

Environmental Modelling & Software 15 (2000) 313–330www.elsevier.com/locate/envsoft

Daisy: an open soil-crop-atmosphere system model

Per Abrahamsen, Søren Hansen*

The Royal Veterinary and Agricultural University, Department of Agricultural Sciences, Laboratory for Agrohydrology and Bioclimatology,Agrovej 10, Dk-2630 Taastrup, Denmark

Received 22 March 1999; accepted 15 January 2000

Abstract

Daisy is a well tested dynamic model for simulation of water and nitrogen dynamics and crop growth in agro-ecosystems. Themodel aims at simulating water balance, nitrogen balance and losses, development in soil organic matter and crop growth andproduction in crop rotations under alternate management strategies. The software, which recently was rewritten, has been carefullydesigned to facilitate interaction with other models, either by replacing individual Daisy processes or by using Daisy as a part ofa larger system, thus making Daisy an open software system. 2000 Elsevier Science Ltd. All rights reserved.

Keywords:Agricultural modelling; Soil water dynamics; Nitrogen dynamics; Open software system; Distributed modelling; Implementation ofalternative models

Software availabilityProgram title: Daisy — A soil/crop/atmosphere modelDevelopers: Søren Hansen and Per AbrahamsenContact address: Søren Hansen, The Royal Veterinary

and Agricultural University, Department ofAgricultural Sciences, Laboratory for Agrohyd-rology and Bioclimatology, Agrovej 10, 2630,Tastrup, Denmark

Tel.: +45-35-28-33-83Fax: +45-35-28-33-84E-mail: [email protected]: http://www.dina.kvk.dk/|daisy/First available: 1999Hardware required: To run the binary, a PC with at least

32 MB ram. To compile: Any modern computerwith at least 64 MB ram.

Software required: To run the binary: A win32 platformsuch as Win95, Win98, or WinNT; To compile:Any OS with GCC 2.95 or later, or a win32platform with Borland C++ 5.0.

Programming language: C++Availability: Source, binaries and documentation can be

* Corresponding author. Tel.:+45-35-28-33-83; fax:+45-35-28-33-84.

E-mail addresses: [email protected] (P. Abrahamsen),[email protected] (S. Hansen).

1364-8152/00/$ - see front matter 2000 Elsevier Science Ltd. All rights reserved.PII: S1364-8152 (00)00003-7

downloaded at no charge from the specifiedURL.

1. Introduction

The loss of nitrogen into aquifers and surface watersin humid regions is an inevitable consequence of inten-sive agriculture. In large parts of Europe, for instance,the input to agricultural systems and the subsequentlosses are so large that they constitute a threat to boththe quality of surface and ground waters (EEA, 1995).In most agricultural systems the main loss of nitrogenis due to leaching of nitrate from the fields. The fact thatlaboratory and field measurements necessary for assess-ment of nitrogen leaching from agricultural fields areexpensive has prompted the development of agroecosys-tem models capable of simulating the nitrogen dynamicsin agricultural soils and in particular simulating theleaching. In Denmark this led to the development of theDaisy model (Hansen et al., 1990; Hansen et al., 1991a).This model has since then been used extensively (e.g.,Blicher-Mathiesen et al. 1990, 1991; Hansen et al.1991b, 1992; Hansen and Svendsen, 1994; Hansen andSvendsen, 1995a,b,c; Jensen and Østerga˚rd, 1993;Jensen et al. 1992, 1996; Jensen et al., 1994a,b; Magid

314 P. Abrahamsen, S. Hansen / Environmental Modelling & Software 15 (2000) 313–330

and Kølster, 1995; Mueller et al., 1996; Petersen et al.,1995; Styczen and Storm, 1993a,b). The model appli-cations comprise both scientific studies and managementrelated studies aimed at decision support. In addition, themodel has been validated in a number of major compara-tive tests (Diekkru¨ger et al., 1995; Hansen et al., 1991a,c;Jensen et al., 1997; Smith et al., 1997; Svendsen et al.,1995; Vereecken et al., 1991; de Willigen, 1991). Hence,Daisy can be considered a well tested model.

Daisy is a 1-dimensional agroecosystem model that,in brief, simulates crop production and crop yield, andwater and nitrogen dynamics in agricultural soil based oninformation on management practices and weather data(daily values), Fig. 1. If the model is applied to areaswith shallow groundwater, information on the positionof the groundwater table is also required. The model canbe viewed as an ensemble of processes, and in order toapply the model, the process-models must be initializedand parameterized, Fig. 1.

Recently, the Daisy model has been reimplemented.The new model software offers extensions as comparedwith the original FORTRAN implementation, e.g., thesimulation of multiple soil columns and inter-croppingsystems. The latter feature is very useful in simulatingorganic farm rotations. More important, the newimplementation has developed the model into an opensoftware system that supports an easy exchange of pro-cess-model descriptions. In a scientific study this featurefacilitates easy testing of alternative process descrip-tions, and in a management oriented study, the processdescription could be chosen on the basis of the requiredaccuracy, the available data or available resources interms of computer-time. Furthermore, the design allowsfor an easy implementation of new processes, e.g.,adding the simulation of the fate of other agrochemicals

Fig. 1. Schematic overview of the Daisy model system.

than the nitrogen species that were considered by theoriginal FORTRAN implementation. In addition, thenew implementation supports the linkage of Daisy withother model systems. Styczen and Storm (1993a,b)linked Daisy with a fully distributed catchment model,MIKE SHE (Abbott et al., 1986a,b) in order to simulategroundwater quality within a hydrological catchment.However, in order to do this they had to run the twocomponents of the combined model system MIKESHE/Daisy iteratively. Such a procedure is sub-optimal.With the new implementation it is feasible to link Daisyto other models at code level. Daisy can now functionas a component in a modelling system like MIKE SHE.The latter linkage is only feasible because the new Daisymodel software can work in a distributed way, i.e. workwith multiple soil columns.

An analysis of the original FORTRAN code revealedthat the revision required, in order to develop the modelinto a flexible and versatile software tool, would be mostextensive. Hence it was decided to redesign and rewritethe code. The basic building blocks of the new code arethe process-models.

The emphasis of this paper is on the design of the newDaisy implementation, which is described in Section 3,discussed on an application level in Section 4, and finallyexemplified in Section 5. However, first we present themain processes in the Daisy model in the next section.

2. Model description

A model is always a simplified representation of a realsystem and as such it is based on simplifying assump-tions. A basic assumption in Daisy is that the modelledsystem can be represented by a one dimensional model.This is a common assumption in this kind of agroecosys-tem models, e.g., LEACHM, (Wagenet and Hutson,1989), SOILN (Johnsson et al., 1987), Opus (Smith,1992), and WAVE (Vanclooster et al., 1995). Daisysimulates the parts of the water, carbon and nitrogencycles that are related to agricultural soil systems. Inaddition, the soil thermal regime is simulated. An overalldescription of the model is given in the following. Forfurther details is referred to Hansen et al. (1990, 1991a).

2.1. Water balance

The adopted schematization of the water dynamics inagricultural soils is illustrated in Fig. 2.The boxes rep-resent storage of water, and the arrows represent flow ofwater or water vapour. Precipitation and irrigation rep-resent driving variables or boundary conditions. Anotherdriving variable or boundary condition, which is onlygiven implicitly in the figure, is the potential evapotran-spiration which forms both the driving force and theupper limit in the evaporation/transpiration processes. In

315P. Abrahamsen, S. Hansen / Environmental Modelling & Software 15 (2000) 313–330

Fig. 2. Schematic presentation of the agrohydrological component ofthe Daisy model.

the evapotranspiration calculations, evaporation fromfree water surfaces has priority over transpiration andsoil evaporation.

2.1.1. Snow accumulation and meltingThe distribution of precipitation between rain and

snow is mimicked by a function of the air temperature.If snow is present, the snow model is activated, Fig. 3.It is noted that the snow model considers both liquid andfrozen water in the snowpack. Water is lost from thesnowpack as evaporation or sublimation and as perco-lation when the retention capacity of the snowpack isexceeded. Evaporation has priority over sublimation.The freezing-melting within the snowpack depends onair temperature, global radiation, ground heat flux(simulated by the soil temperature model), and albedoand depth of the snowpack. The last two are internalsnowpack variables.

Fig. 3. Schematic presentation of the snowpack model in Daisy.

2.1.2. Interception by canopyInterception of water in the crop canopy is mimicked

by a simple capacity model. The interception capacitydepends on the leaf area of the canopy. Through-falloccurs when the interception capacity is exceeded.

2.1.3. Infiltration and pondingPonding only occurs when water is allocated to the

soil surface at a rate higher than the maximum infil-tration rate. The latter being determined by the con-ditions within the soil itself.

2.1.4. Soil evaporationSoil evaporation only takes place if the demand by

potential evapotranspiration is not fulfilled by evapor-ation from free water surfaces. The part of the potentialevapotranspiration that is not used by these evaporativeprocesses is split between the crop and the soil by afunction of leaf area. The soil’s ability to deliver wateris simulated by a potential exfiltration rate, which isdetermined by the conditions within the soil itself. Thesoil evaporation is now defined by the minimum ofthe two.

2.1.5. Soil water dynamicsThe soil water dynamics constitutes one of the most

important parts of the model. Simulation of movementof water within the soil is based on potential theory andis based on a numeric solution to Richard’s equation.Richard’s equation is a second order partial differentialequation and as such it requires knowledge of twoboundary conditions. The upper boundary is determinedby the infiltration rate (the rate at which water is allo-cated to the soil surface), soil evaporation rate, or ifponding occurs, a known potential at the soil surface.The lower boundary is defined by a known potential ifthe position of the groundwater table has been externallydefined. In this case capillary rise can occur. Anotherpossible boundary condition is free drainage. In this casethe percolation is determined by the conditions withinthe soil itself.

2.1.6. TranspirationTranspiration is determined by root uptake of water.

Storage of water within the plants is neglected, hencetranspiration equates the soil water uptake by roots. Thepreviously calculated part of the potential evapotranspir-ation that is allocated to the crop forms the upper limitfor transpiration. The water uptake by roots depends onthe rooting depth and the root density distribution in con-nection with the soil water status within the rootingdepth. The uptake is modelled by the single root concept,which is applied within each of the numeric layers thatthe solution to Richard’s equation works with. In thesingle root concept water is assumed to move radiallytowards the root surface where it is taken up at the same


rate it arrives at the surface. The flow of water is thendetermined by the conditions in the soil and the con-ditions at the root surface. The latter being regulated bythe plant. It is a basic assumption that the plant only isable to lower the potential at the root until the potentialthat corresponds to the permanent wilting point, hencethis condition sets the limit for the uptake. Furthermore,it is assumed that a single root exploits the soil aroundit corresponding to the volume within a cylinder with aradius corresponding to half the average distancebetween roots. Another basic assumption in thisapproach is that the developed potential distance profilethat develops around an absorbing root can be approxi-mated by the corresponding steady state profile. Hencethe dynamics of the uptake is approximated by a seriesof steady-states. The total uptake which corresponds tothe transpiration is obtained by integrating the wholerooting zone.

2.2. Carbon and nitrogen cycling

The adopted schematization of the considered carboncycle related to agricultural soils is illustrated in Fig. 4.The boxes represent storage and the arrows representflows. Carbon input to the system is through the processof photosynthesis and through amendment of organicfertilizers. Carbon is lost to the atmosphere through res-piratory processes in the plant and the soil microbes.

2.2.1. Crop growthPhotosynthesis and plant respiration is simulated by a

crop model. Important features of the crop model are theability to simulate the temporal variation in leaf areaindex (LAI), rooting depth, root density, dry matter pro-duction, and crop nitrogen demand and content becausethis information is required by other parts of the model.The crop model included in the original version of Daisymimics the canopy photosynthesis as a function of LAI,global radiation, air temperature and any water and/ornitrogen stress. Water stress occurs when the wateruptake by the roots is less than the potential transpi-

Fig. 4. Schematic presentation of the Carbon cycle componentincluded in Daisy.

ration. Nitrogen stress occurs when the nitrogen concen-tration in the plants gets below a certain threshold. Theproduced assimilates are then partitioned between theconsidered plant compartments, and growth and mainte-nance respiration takes place resulting in net productionof the considered compartment. The considered plantcompartments are shoot, root and for root crops alsostorage organs. The assimilate partitioning is governedby a development stage representing the phenologicaldevelopment of the crop. The development rate is simu-lated by a function of temperature. The LAI is simulatedas a function of shoot dry matter and development stage.Root penetration is governed by the plant, soil tempera-ture and restrictions in the soil. Root density is governedby rooting depth and accumulated root dry matter. Atharvest, the shoot dry matter is partitioned between theeconomically interesting part, e.g., grain, and the econ-omically less interesting part, e.g., straw, and fractionsof these are then removed as yield. The leftovers or resi-dues, including root material, can then be transferred tothe soil organic matter.

As the original crop model does not allow for thesimulation of the competition between plant species, theoriginal model has been further developed in order tocope with the inter-cropping situation. The new develop-ment is based on the principles of SUCROS (Simple andUniversal CROp growth Simulator, van Keulen et al.,1982). The new crop model is more detailed than theold one and simulates dry matter in leaf, stem, storageorgan, and root explicitly.

2.2.2. Organic matter turnoverThe soil organic matter model considers three distinc-

tive types of organic matter, viz. newly added organicmatter (AOM), living soil microbial biomass (SMB), andnative nonliving soil organic matter (SOM). For eachnew amendment of organic matter a supplemental AOMis formed. The turnover of these pools is simulated bysubdividing each of them into two subpools and applyingfirst order degradation to the individual subpools. Fur-thermore, it is assumed that carbon in form of CO2 islost from the system due to growth and maintenance res-piration of SMB. The carbon flow between the individ-ual pools is illustrated in Fig. 5. The first order degra-dation rates and the maintenance respiration rates aremodified according to soil temperature and soil waterexpressed in terms of the soil water pressure potential.Furthermore, the degradation rates may be modifiedaccording to nitrogen stress. As illustrated in Fig. 5, theturnover of organic soil nitrogen is closely linked to theturnover of organic carbon.

The adopted schematization of the considered nitro-gen cycle related to agricultural soils is illustrated in Fig.6. Organic nitrogen enters the system in organic fertiliz-ers, and also by plant or SMB uptake of inorganic nitro-gen, viz. ammonium and nitrate. SMB uptake of mineral


Fig. 5. Schematic presentation of the soil organic matter turnovermodel included in Daisy (AOM=added organic matter, SMB=soilmicrobial biomass, SOM=native soil organic matter). Organic input issubdivided in structural, metabolic and recalcitrant organic matter.

Fig. 6. Schematic presentation of the Nitrogen cycle componentincluded in Daisy.

nitrogen is often termed immobilization. Organic nitro-gen is lost from the system due to harvest of organicplant material or due to ammonification (mobilization).Organic nitrogen comprises two pools, viz. organicnitrogen in the crop and in the soil.

As stated above, the organic soil nitrogen is subdiv-ided into a number of subpools of organic matter eachcharacterized by a fixed C:N ratio. Whether mobilization(ammonification) or immobilization takes place isdetermined by the carbon turnover and the correspond-ing C:N ratios of the considered organic matter pools(Fig. 5). If immobilization takes place and insufficientmineral nitrogen is available, then nitrogen stress occursand the turnover is hampered.

2.2.3. Nitrogen uptakePlant uptake of mineral nitrogen is determined either

by the plants’ nitrogen demand or the availability ofmineral nitrogen in the soil. The former is simulated onthe basis of a potential nitrogen content in the plant,which is determined on the basis of the accumulated drymatter production and the development stage of theplant, and the actual nitrogen content of the plant. Thelatter is determined on the basis of the actual content ofmineral nitrogen in the soil and the transport from thebulk soil to the root surfaces. Two mechanisms areassumed to be active in this transport, viz. mass-flowwith the transpiration stream and diffusion to the rootsurface. The basic assumptions in these calculations cor-respond to the assumptions made for the calculation ofthe water uptake (transpiration stream).

2.2.4. Mineral nitrogen balanceThe ammonium sources are deposition, fertilization

and ammonification, and the sinks are plant uptake,immobilization, nitrification and leaching (Fig. 6). Fornitrate, the sources are deposition, fertilization, and nitri-fication, and the sinks are plant uptake, immobilization,denitrification and leaching. Deposition comprises bothdry and wet depositions. Leaching is a result of numericsolutions to the convection-dispersion equation forammonium and nitrate, respectively. These equationsalso keep track of how ammonium and nitrate are dis-tributed within the considered soil profile. Like Rich-ard’s equation, the convection–dispersion equation is asecond order partial differential equation and a solutionrequires knowledge of two boundary conditions. In thiscase, the upper boundary condition is always a flux con-dition and the lower boundary condition is a zero-gradi-ent condition.

2.3. Soil temperature

The thermal regime of the soil is simulated by anumeric solution to the heat flow equation, taking bothtransfer of heat by convection and conduction intoaccount.

3. Daisy software design

In this section, the main abstractions used in the Daisysoftware are described. Section 3.1 gives a summary ofthe sequence of events in the program during a simul-ation run. Section 3.2 gives a static description of themain components of the simulation and their relation-ships. Finally, Section 3.3 describes what a componentin Daisy is and the ability of the component from a pro-grammer’s perspective.


3.1. The main software components

At a sufficient high level of abstraction, all programsare the same: they translate input into output. (Fig. 7.The figure should be read from left to right).

Running Daisy involves two phases. The first is pars-ing the input. This is done by a parser component, whichis conceptually completely separate from the mainsimulation component. The second phase is the simul-ation itself. The simulation model contains the physicalstate and processes in a number ofcolumncomponents(described in Section 3.2), some driving variables in themanager, weather, andtime components, and a separatelog component whose purpose is to write selected partsof the state to files for later inspection. These compo-nents are described further below. The wordcomponenthas a specific meaning in Daisy, as described in Section3.2 and 3.3.

3.1.1. ParserThe parser translates text according to an external

abstract syntaxinto an internalparse tree. That the syn-tax isabstractmeans that it describes the expected inputon a fairly high abstraction level. E.g., the component“Denitrification” has a member “alpha” of type “num-ber”. Theconcrete syntaxis implemented in the parseritself.

3.1.1.1. Concrete syntax The separate implementationof the abstract and concrete syntax has several advan-tages. One of these is that the concrete syntax can bereplaced by a new parser. That is, the default parsermight recognize the text

(alpha 0.1)

in the context of a definition of the “Denitrification”object as setting the “alpha” member to 0.1. If one wouldlike a less lisp-like (less parentheses) look, anotherparser might accept a C-like concrete syntax, such as

alpha50.1;

and could be implemented without changing the rest ofthe system. In fact, because the parser is a component(see Section 3.3) both parsers can be available in the

Fig. 7. Running a Daisy Simulation.

system simultaneously, in this way some files can useone syntax and other files the other syntax.

3.1.1.2. Abstract syntax The ability to change theparser is of little practical value, since it is easier for auser to only have to learn a single syntax. Much moreuseful is the separation of the abstract syntax from theparser itself. This means the abstract syntax can bechanged or expanded (i.e. adding new parameters) with-out touching the parser. In Daisy, this has been taken astep further. The implementation of each model in Daisyis responsible for providing its own abstract syntax. Thismeans that changes in a model do not affect the codeoutside the file that implements the model itself. Thisis a key feature enabling the flexible component designdescribed in Section 3.3.

3.1.1.3. Attribute lists The output of the parser is anabstract parse tree, implemented in Daisy as anattributelist. An attribute list is an unordered set of (name, value)pairs. Thename is a string, “alpha” in the exampleabove. Thevalue in that example is the floating-pointnumber 0.1. The value could also be an integer, a date, astring or any of the other types useful for parameterizingmodels in Daisy. One type warrants special mention.Fig. 7 shows thattime is the only component in thesimulation likely to be described by a simple type. Eachof the other components requires its own set of para-meters. This is solved by allowing the value itself to bean attribute list. This attribute list should then have theelements required by the abstract syntax provided by thecomponent to the parser.

Thus, the parser ensures that each component gets theinitialization parameters in the form of an attribute list,that the component itself has requested in the form ofan abstract syntax.

3.1.2. Driving variablesThe weathermodel and themanagermodel can be

viewed as external to the physical modelling of the soilcrop system.

3.1.2.1. Weather The weather model must provide anumber of meteorologic data used by the physicalmodel, for example air temperature and precipitation.Usually, these are read from a file containing daily aver-age numbers. These numbers are then distributedthrough the day using astronomical data derived fromthe time of the year and the longitude.

There are also a number of alternate weather modelswhich can be used. One weather model can read a filewith hourly values, other models can create “artificialweather” or even “no weather” (all numbers areconstant). These models are obviously unrealistic, butcan be useful for testing components of the simulationunder simplistic assumptions.


3.1.2.2. Manager The manager is an instance of acomponent type called action. The build-in actions canbe divided into two categories, the primitive actions suchas plowing or harvesting, and the composite actions pro-viding programming language primitives such as“progn”, which combines a number of actions, and “if”,which makes an action depend on a givencondition.

Condition is another component type, used whenspecifying actions and specifying logs. Again, there aretwo categories of conditions, primitives which test thestate of the simulation such as “at”, which is true at aspecific point in time, and logic conditions such as “and”which combines other conditions.

When combined, these actions and conditions can cre-ate a specification for the manager, as shown in Section4.1.1. It is also possible to implement other models forthe manager as special “action” types. The GUI(Graphical User Interface) front-end (see Section 4.2.2)uses this.

3.1.3. LogsThe output is defined by a list of log components.

There are currently two kinds of log components.The table log writes a user specified list of state vari-

ables to a user-specified file in user-specified intervals.The state variables can be averaged or accumulated overthe interval or the complete simulation at the users pref-erence. The format is tabulator separated columns.

The checkpointwrites all state variables to a userspecified file at a user specified point of time, in the sameformat in which the parser expects them to be wheninitializing the simulation. This can be used to “hot-start” the simulation at that point in a later run.

Other kinds of logs can be implemented, for examplea log that displays a state variable dynamically while thesimulation runs.

3.2. The column component

The Daisy model itself includes specialized models ofthe specific processes in the simulation. Each of thesespecialized models may themselves contain even morespecialized models, etc. The software is organizedaround these models within models, each model beinga replaceablecomponent, as described in Section 3.3.

Fig. 7 introduced the top level components of thesimulation. In Fig. 8 we look into the major componentof the simulation, that is thecolumn.

Daisy is basically a one dimensional model, asdescribed in Section 1. Each column object represents avertical line in a field from the bioclimate in top to thegroundwater at the bottom. The components in Fig. 8are organized from top to bottom to match the worldthey model. Each “box” in the figure represents onereplaceable component. Many of the components containsubcomponents, but only the subcomponents of thebioclimate are shown.

Fig. 8. Components of a Column.

In the following, we will discuss the organisation ofthe components from top to bottom, their subcom-ponents, and the implementations which can be chosenfor each subcomponent.

3.2.1. BioclimateThe main responsibility of the bioclimate component

is to distribute the meteorological input it receives fromthe weather model based on the various crops and thesoil. The main inputs are precipitation, potential evapo-transpiration, air temperature and global radiation. Theprecipitation is distributed on various storages, such asthe canopy, the snowpack (which is a separatecomponent), and the soil surface (also a separatecomponent). The potential evapotranspiration is distrib-uted among these storages, (Section 2.1). The globalradiation is distributed among the crops according to therelative distribution of their canopy. A crop with a highcanopy will shadow a crop with a low canopy. Forinstance, a spring barley might intercept almost all theradiation thus shadowing the undersown grass and pre-venting it from developing fully until harvest of the bar-ley.

3.2.1.1. Crops The standard crop model is by far themost complex model in Daisy, but its interaction withthe rest of the model is less complex. Basically, it hasto tell the bioclimate the vertical distribution of its can-opy, and in return the crop receives a potential transpi-ration and radiation from the bioclimate. The crop modelcan use these to determine how much water and nitrogento extract from the soil.


3.2.2. SoilThe main soil component serves two purposes:

O The region between the surface and the groundwateris divided into a number of numerical layers for com-putational purposes. These layers are defined by thesoil component, as indicated by the horizontal linesin Fig. 8.

O The soil’s physical properties, such as the clay contentand the hydraulic conductivity are defined on a speci-fied list of horizon components, each representing aseparate type of soil.

Each numerical layer has an associated horizon, uniquelydefining the physical properties of that layer.

3.2.2.1. Water and heat The soil water componentkeeps track of water storage and transport. The transportpart is delegated to a separateuz (unsaturated zone)component, which has several implementations tochoose from. The most complex model provides anumerical solution to Richard’s equation. A simpler andmuch faster model simulates water transport as asequence of linked reservoirs. Another modelimplements no water transport at all, and is used whenthe water transport is provided by an external modelthrough the C API (see Section 4.4).

The soil heat component keeps track of the tempera-ture in each soil layer by means of soil thermal propertiesand implements a heat flow.

3.2.2.2. Ammonium and nitrate The soil content ofammonium and nitrate is tracked by two separatecomponents. They both allow the user to specify a trans-portation model by selecting a nested component. Theimplemented transport models available are convectiondispersion, convection alone (faster), or no transport(fastest!). Selecting no transport is quite useful forammonium, since sorption often makes ammoniumtransport negligible. Under normal conditions, almost allleaching is in the form of nitrate.

The adsorptionmodel is also a separate componentwhich can be chosen from a number of different models,such as Langmuir, Freundlich, linear, all resulting in dif-ferent trade-offs between accuracy and speed. There isa “no adsorption” for determination of nitrate.

Plans are made to simulate other chemicals in the soil,such as pesticides, by specifying the transport andadsorption model for each chemical.

3.2.2.3. Nitrification and denitrification The nitrifi-cation and denitrification components allow the user tospecify how to model these two processes. From asoftware design point of view, these two components aredistinguished from the other components in Fig. 8 bynot requiring any state, they are pure processes.

3.2.2.4. Organic matter and mineralization Theorganic matter component contains several subcom-ponents, in the form of “pools”, Fig. 5. The SOM poolscontain the basic storage of organic matter. The AOMpools contain recently added organic matter. The SMBpools contain the living biomass of the organic matter.Each pool has a separate C/N ratio, a separate utilizationuse efficiency, and a separate turnover factor. Mineraliz-ation (or immobilization) happens when the biomassabsorbs substrate from one pool, converting some partof it into another pool, and the rest into energy (CO2-respiration).

3.2.3. Surface and ground waterThe surface and groundwater components provide the

boundary conditions for all the transport processes.There is only one surface model implemented, but treedifferent groundwater models. First, the groundwater canbe well below the part of the soil we simulate, allowingfor a free drainage assumption. Secondly, thegroundwater can be at an assumed fixed level. Thirdly,the groundwater level can be read from a file.

3.3. The component abstraction

In Daisy, available components are implementedusing variations of a design pattern (Gamma et al., 1994)invented for that purpose. A design pattern is a reusableprogramming technique. This section describes thecomponentdesign pattern. The component design patternis implemented in C++ programming language, anddepends on concepts (such as static constructors) specificto that language. The basic structure of the pattern andindication of which C++ constructs are used forimplementing it are described below.

There are two variations of the component pattern.The first isfixed components,which implements a singlemodel, and the second islibrary componentsthat allowsthe user to choose from a library of implementations. Ingeneral, the library components are more flexible, sincenew models can be added simply by adding an objectfile containing an implementation of the model, and theuser can choose among the available models in the inputfiles. But they have a small overhead in both time andprogram complexity, therefore, fixed components areused when a need for alternative models has not beenanticipated or experienced.

3.3.1. Content of a componentAs is illustrated in Fig. 9, library components and

fixed components have many elements in common.

3.3.1.1. Fixed components In order to create fixedcomponents, the programmer must specify:

O Interface. The interface of the component is a list of


Fig. 9. Library and Fixed Components.

names and types of functions and data visible to therest of the system. It is located in a separate file (aC++ header file) and combined into aclass (a C++abstraction that makes it possible to treat a collectionof related data and functions as a single unit). Othermodules must include this header file in order to com-municate with the component.

O Implementation. The functions are implemented in aseparate file, a C++ source file.

O Syntax and Values. Each fixed component must spec-ify which parameters it accepts, their type, and thusspecify default values for these parameters.

O Constructor. The component should be able to con-struct itself given an attribute list. This is done by afunction (a C++ constructor) that takes an attributelist as its argument.

O Logger. The component must be able to log its state toa Log component. This is done by a function (namedoutput) which takes the Log as an argument. Thefunction is recursive, i.e. it will call the output func-tion of any subcomponent.

3.3.1.2. Library components A library componentconsists of two parts. One is the interface, which isdefined in a separate file, just like for fixed components.However, in this case the functions are marked asvir-tual, which is a C++ language feature that allows mul-tiple implementations of the function to co-exist.

The other part is theLibrary, a mapping (implementedas a C++ class) from aname, into a syntax, somedefaultvalues, and aconstructoras described for fixed compo-nents. Each name in the map corresponds to a specificmodel. A special language technical problem is the con-structor. Each library component has its own interfaceclass, and the constructors must return objects of thatclass. This means that a single, common library classalone is not enough to provide the full mapping. How-ever, C++ provides a mechanism calledtemplates, whichenables construction of algorithms that work on manytypes. A template named ‘Librarian’ is used for complet-

ing the mapping. It takes the interface class as a tem-plate argument.

The ‘Library’ abstraction has another function. Itallows the user to give names to specific parameteriza-tions of the models. This functionality is provided by afunction that takes the name of an existing model andan attribute list as arguments, and creates a new pseudo-model with the same syntax and constructor, but thedefault values are overwritten by those provided in theattribute list. Once added to the library, the new para-meterization is indistinguishable from a build-in model.

3.3.1.3. Model implementations Each model isimplemented entirely in a separate file (a C++ sourcefile). The only way to reach the implementation isthrough the interface of the library component. Thismeans that a model cannot use or provide informationthat was not anticipated in the design of the component.It can, however, provide more information to the userthrough the logger.

Basically two tasks must be done in order to makethe model available to the rest of the system. The modelitself must be implemented, and the rest of the systemmust be informed that it exists. The first task involveswriting implementations of all the functions specified inthe component interface. In C++ terms, this means cre-ating a derived class which implements all the pure vir-tual functions in the interface class.

The second task involves listing and specifying typesfor all the parameters for the model, as well as thedefault values where applicable, and then registration ofthese (together with the function to construct the model)in the component library. In C++, this is done by cre-ating a class with a single global instance. The languagerules dictate that the constructor for that class is calledbefore the program starts, and the constructor can thenensure that the model is properly registered.

3.3.2. Input filesThe component functionality is reflected almost

directly in the input files.

3.3.2.1. Specifying componentsIn the input files, thedifference between a fixed and a library component isthat the user needs to specify the model.

O (name atts); Fixed componentO (name model atts); Library component

For example, denitrification is a fixed component (onlyone implementation), while nitrification is a librarycomponent with two models (rate depends on theammonium content in soil or in solute). In an input file,the specification for these two components of a columnwill look like this:


(Denitrification (K 0.0417)(alpha 0.1))

(Nitrification soil (kF10 2.1e-7)(k 5.0e-5))

Here soil is the name of one of the nitrification mod-els, while K, alpha, kF10 and k are parameters to thedenitrification model and the soil nitrification model,respectively.

3.3.2.2. Adding parameterizations The interface tothe functionality for adding new reusable parameteriza-tions looks like this:

O (defcomponent name model atts)

Here,componentis the name of the library component,nameis the name which the parameterization will havein the library,modelis the name of an existing elementin the library, andatts are the parameters to add orchange compared to that model. The parameterization ofthe nitrification model used in the previous section canbe added:

(defnitrification mynit soil (kF10 2.1e-7)(k 5.0e-5))

After that, the nitrification parameters could be speci-fied simply by using the name from the library:

(Nitrification mynit)

4. Using the Daisy software

The design behind the reprogramming of Daisy hasbeen constrained by the needs of several different typesof users. The most basic use of the program is to specifythe soil, a crop rotation, and a file containing climateinformation, and run the simulation. An example is givenin Section 4.1. More advanced users may want todescribe a specific type of soil and add it to the soillibrary for use in later simulation runs, or parameterizethe generic crop model provided by Daisy to add a newcrop to the list of crops available in a simulation. Anexample is given in Section 4.2. A third group of userswill want to enhance the program in a more fundamentalway, by adding alternatives to build-in models of thevarious processes in Daisy. This could be a different wayto describe a crop, or a different model of the nitrifi-cation process. In Section 4.3 we discuss the procedure.Finally, some users will want to include Daisy as acomponent of their own simulation programs. See Sec-tion 4.4 for information about how these users are sup-ported by Daisy.

4.1. Specifying a simulation

The most obvious way to use Daisy is to setup andrun a simulation. After all, Daisyis a simulation model.The users whose need have influenced this aspect ofDaisy are:

O Modellers. These are the scientists who provide thevarious models of which Daisy is composed. To vali-date these models, and Daisy as a whole, the model-lers have to run simulations on various realistic andartificial scenarios. Daisy allows them to extract anyof the state variables at any point during the simul-ation.

O Education. Daisy has been used as a tool in education.The purpose here is to allow students to explorephysical models by running and experimenting witha simulation.

O Policy Makers. Daisy has been used extensively bypolicy makers to predict the consequence of variouspotential decisions. Policy makers have primarilybeen interested in nitrogen leaching and harvest yield,but might also examine changes in the soil organicmatter content to see changes in soil quality.

O Advisers. Agricultural advisers can use Daisy for pre-dicting harvest yield, nitrogen leaching, mineraliz-ation (for planning fertilization), irrigation need, andchanges in soil quality.

There are two ways to set up a simulation, by editingsetup files directly, or through a GUI.

4.1.1. FilesA minimal set-up file is shown below.

;; example.dai—An example daisy setup file.;; Read pre-defined parameterizations from library.(input file “library.dai”);; Setup simulation components.(weather file “example.clm”)(column MyColumn)(time 1957 1 1 1)(manager MyManager)(output “N Balance” “Harvest”);; example.dai ends here.

The lines starting with ;; are comments. There is a closerelationship between this listing and Fig. 7. Each of theovals on the figure corresponds to one declaration inthe file.

4.1.1.1. Elements The first item of the example is theinput declaration. It is a little different from the otherdeclarations in the example, in that it immediately cre-ates a parser object which then reads more declarations.It is possible to have many input declarations in a file,


and they can also be nested, making it possible to includefiles from included files.

The example states that the “file” parser model shouldbe used. The file parser model takes a single parameter,a file name, where the declarations are read from.

The remaining elements are initializing the compo-nents of the simulation.

O weather. The weather component is initialized withthe file model, which takes a single parameter, thefile, to read the weather data from.

O column. The column can actually take a number ofcolumns. In this case it only takes a single column,“MyColumn”, which is presumably a parameteriz-ation found in “library.dai”.

O time. The time attribute is a bit different from theothers, in that it is not a “component” as described insection 3.3, but a primitive type. It is initialized withthe year, month, day, and hour for the simulation start.

O manager. The manager is initialized with a pre-defined parameterization, just like “column”.

O output. The output is a list of log components specify-ing the output of the program. In this case, two para-meterizations, again presumably from “library.dai”

4.1.1.2. Inline specifications It is possible to specifythe parameters directly. I.e. instead of

(manager MyManager)

one could write(manager (progn

(if (at 1957 3 4 1)(sow SpringBarley))

(if (at 1957 4 2 1)(fertilize cattleFslurry (weight0.750)))

(if (at 1957 8 10 1)(harvest SpringBarley))

(if (at 1957 11 1 1)(stop))))

thus specifying the crop rotation inline.

4.1.2. GUIThe file parser has been developed to give full control

of all aspects of the simulation, even when new modelsare added. It gives access to any parameter included inthe model. This includes parameters that will only be ofinterest to scientists researching that particular model,and the ability to set unrealistic values for any of theparameters.

In order to make it easier for typical users to set upa typical crop rotation, a GUI front-end has beendeveloped. The GUI front-end uses Daisy as a library

to read and pretty-print setup files, and to actually runthe simulation.

The restrictions of the GUI are that it only givesaccess to parameters for some of the build-in models,and never for new models. However, it is possible toselect an existing parameterization of one of the unsup-ported models.

The advantages are that the parameters are presentedin an intuitive way, with supplementary text and rangechecking on all input fields.

The main GUI dialog for specifying the manageractions is shown on Fig. 10.

4.2. Reusing model parameterizations

Frequently, users will want to reuse parameterizationsof specific components from one simulation to another.For users of Daisy on a small scale, the main compo-nents that will end up in a parameterization library are:

O crop. The generic crop model requires a lot of workto parameterize a specific crop. Most users will useparameterizations provided by others, for examplesome of the parameterizations that are bundled withDaisy, for their crops.

O horizon. Often, not all the parameters needed for thephysical soil model are available, but the soil type isknown. In that case, one can use a library of soil typeswith known physical properties. This is not as goodas getting the data on the actual soil used, but it isoften all you can do.

O fertilizer. Daisy uses a single model for describing all

Fig. 10. Setting up a Crop Rotation.


types of organic fertilizer, with parameters such asturnover rate. When specifying the management,names for already parameterized fertilizer models like“cattle manure” or “pig slurry” are usually preferredover specifying all the parameters directly. It is cer-tainly more readable.

Even so, the horizon and fertilizer libraries are likely tobe different for different users, so unlike the crop librarythey are not bundled with Daisy.

Users who work with large scale simulations withmany columns will find it useful to create libraries con-taining standard columns and standard crop rotations.

4.2.1. Input fileIn the input file, you can define a named parameteriz-

ation of any library component.The components aboveare just the most useful.

To define a new manager, you use the “defaction”command. For example the manager in Section 6.1.2could be named “MyManager” with the following dec-laration:

(defaction MyManager progn(if (at 1957 3 4 1)(sow SpringBarley))(if (at 1957 4 2 1)(fertilize cattleFslurry (weight 0.750)))(if (at 1957 8 10 1)(harvest SpringBarley))(if (at 1957 11 1 1)(stop)))

There are similar defwhatever commands for all thelibrary components.

4.2.2. GUIThe GUI front end allows you to parameterize the

standard column and horizon models as well as the man-ager, and to save the parameterizations in a library. Fig.11 shows the horizon edit dialog.

4.3. Adding a new model

One of the most powerful features of Daisy is theability to easily add new models by linking with a filecontaining an implementation of the model. This is prim-arily useful for researchers in need of a framework to testand run their simulations, and for developers wanting tocombine Daisy with other programs. However, once themodel is implemented and the code distributed, every-body will be able to use the new model, and even com-bine it with other, independently developed models, i.e.Daisy provides a framework for combining models.

Some reasons to write an alternative model arelisted below.

Fig. 11. Setting up a Soil Horizon.

O More Information. Currently a new bioclimate modelbased on Shuttleworth and Wallace and Penman-Monteith is being developed. It requires much moredetailed weather information, but can in return alsoprovide much more detailed information about thebioclimate.

O Less Information. It is not always possible to acquireall the information needed for e.g. the standard cropor organic matter models, in that case implementinga simpler model could be an option.

O Speed. Some of the models, such as the numericalsolution to Richard’s equation, can be rather time con-suming. For large simulations using a simpler model,like the “linked reservoir” model provided by Daisy,can significantly speed things up.

O Reuse Parameterizations. We already had para-meterizations of several crops for older models. Tobe able to reuse these, we implemented the old cropmodel in the rewritten Daisy.

O Other Systems. Linking to other systems can also bedone by writing a new model. For example, the setupGUI provides its own management model, ensuring amore direct relationship with the presentation.

A technical description of how to add an implementationof a new model to Daisy can be found in Abrahamsen(1997).

4.4. Including Daisy in other model systems

In some projects, adding another model to Daisythrough the component interface may not be an option.


There can be several reasons for this, e.g., there can beconceptual problems, if the other model is addressingissues outside the one dimensional soil/crop system ofDaisy, or most significantly, there can be technical prob-lems.

O The other model might be implemented so the mainloop should be there.

O The interface between the models may affect manycomponents of Daisy, and replacing them all may notbe an option.

O The component interface is written in C++, whichmay not be link compatible with the implementationlanguage of the other model.

O The component interface is flexible, but unusual. Amore traditional interface can be easier to learn.

To address these issues, we have developed an alterna-tive C interface. The C interface consists of a numberof opaque types (like ‘daisyFweather’), and functionsoperating on these types (like‘daisyFweatherFputFprecipitation’). The C interface isintended for using Daisy as a library in a (presumablylarger) application. It has no facilities for adding newmodels to Daisy. The C API has been developed ratherad hoc, in that the functions provided are those that havebeen useful in other projects.

The advantages of the C interface are that it is simple,that most programming languages support calling a Cinterface, and that most programmers know enough C tounderstand an interface in that language. Compared tothe component interface, the disadvantages are that it isless flexible, and that you cannot automatically combineindependent projects all using the C interface. The Cinterface is documented in Abrahamsen (1998).

5. Example

In order to illustrate the model’s ability to simulateinter-cropping systems and its ability to use alternativeprocess models the following example was designed. ASpring Barley with ley is grown on a coarse sandy soil.The simulation of water transport in the unsaturated zonewas based on two different models, viz.:

O A numerical solution to Richard’s equation (RE).O A simple linked reservoir model (LR), where no verti-

cal transport out of a soil layer takes place when thesoil water potential in the layer is below2100 cm,and gravity flow takes place when the soil waterpotential exceeds the2100 cm.

The simulation was initiated 1986-12-01 and ended1988-04-01. Only the year 1987-04-01 to 1988-04-01was considered. The first part of the period was con-

sidered a “warming up” period. The period was selecteddue to a, for Danish conditions, extreme precipitationevent in July 1987, where the rainfall was 103.5 mmwithin three days. Parameterization and initialization ofthe model has been adopted from previous simulationstudies.

The set-up file for the example is shown in Table 1.As usual, the setup file relies on existing parameteriza-tions retrieved from an another file (‘library.dai’). Thisprovides us with already parameterized models forweather, crops, tillage operations and log files.

The column parameterization is of particular interest.The already parameterized ‘JB1FAndeby’ column isfurther specialized into a ‘JB1Flr’ column, using a LRwater transport model, and a ‘JB1FRichards’ column,using a RE-model for water transport. This illustratesboth how to derive new parameterizations, and how tospecify an alternative model for a specific process. Inparticular, ‘SoilWater’ is a fixed component inside thestandard column model, containing all the parametersdescribing the water content of the soil. We are onlyinterested in one of these, the ‘UZtop’ attribute, whichselects the model (and parameters) for water transport.In the example, we select the “lr” and “richards” models,respectively, neither of which requires any parameters.

The multi-crop and multi-column features introducedby this example are simply enabled by listing multiplecolumns in the “column” specification, and sowing mul-tiple crops in the “manager” specification.

The ability of the model to simulate inter-croppingsystems is illustrated in Fig. 12, where the LAI develop-ment of the two crops are shown. Only the simulationswith the LR-model are shown, because only small dis-crepancies between the models exist. It is noted that thegrass ley develops slowly due to shadowing effect of theearly developed spring barley canopy.

In Table 2, a comparison of the main elements of thewater and mineral nitrogen balances are shown. Onlyminor discrepancies between the two model approachesare found at the annual time-scale. This is also confirmedby comparison of the simulated dry matter (DM) andnitrogen yields.

In order to compare the model approaches at a finetime-scale, the daily percolation out of the rooting zoneis shown in Fig. 13. The comparison shows a clear dif-ference in the dynamics of the two approaches, e.g., dur-ing the high percolation event in July the maximum per-colation obtained by the LR-model was 29.5 mm andthe corresponding value for the RE-model was 24.6 mmand this value was obtained one day later. It is notedthat the RE-model exhibits an appreciable smoothingeffect on the output function (percolation) as comparedto the LR-model. However, for many purposes the LR-model will do.

To compare the efficiency of the two models, eachmodel was run 10 times on a 250 MHz UltraSPARC,


Table 1Main set-up file containing information for simulating Spring Barley with Ley. The two water transport models, viz a model based on Richard’sequation and a linked linear reservoirs model, are run simultaneously

;;; em+s.dai—Initialization file for EM+S experiment.;;;; We try to run the same simulation with two different soil water;; transport models.

(input file “library.dai”)

;; Andeby weather data.(weather andeby)

;; We specialize the pre-defined ApFAndeby column to use Richards;; equation and linked reservoirs for water transport, respectively.(defcolumn ApFRichards ApFAndeby

(SoilWater (UZtop richards)))

(defcolumn ApFlr ApFAndeby(SoilWater (UZtop lr)))

;; Run simulation with both columns for comparison.(column ApFRichards ApFlr)

;; Simulation start date.(time 1986 12 1 1)

;; SpringBarley with ley setup.(manager(cond ((at 1987 3 20 1)

(plowing))((at 1987 4 4 1)

(fertilize mineral(NO3 50.0e-5) ;[g/cm2]=50 kg/ha(NH4 50.0e-5))) ;[g/cm2]=50 kg/ha

((at 1987 4 5 1)(progn (sow Grass)

(sow SpringBarley)))((at 1987 9 5 1)

(harvest SpringBarley))((at 1987 9 8 1)

(fertilize mineral(NO3 40.0e-5) ;[g/cm2]=40 kg/ha(NH4 40.0e-5))) ;[g/cm2]=40 kg/ha

((at 1987 10 10 1)(harvest Grass

(stub 10) ;Leave 10 cm stub.(stem 1.00))) ;Harvest everything above stub.

((at 1988 4 1 1)(stop))))

;; Create these log files.(output water ammonium nitrate percolation barley grass Harvest)

and the average user and system time was noted. Wealso ran the warming up time to be able to compare theapproximate time for a year’s simulation. The timerequired for one year simulation was 56 s and 27 s withthe RE and LR models for water transport, respectively.

Thus, for large simulations the use of the LR-modelposes an attractive alternative.

6. Discussion

There are many systems simulating the same pro-cesses as Daisy, e.g., Soil/SoilN (Jansson and Halldin,1980; Johnsson et al., 1987) and Wave (Vanclooster etal., 1995). However, most of these are closed, includingthe first version of Daisy. We have found two efforts


Fig. 12. Simulated LAI-Development in Spring Barley and Grass.

to create open, extensible, frameworks. One is Expert-N (Engel and Priesack, 1993), of which only few detailshave been published, the other is APSIM (McCown etal., 1996) which has been chosen as standard of compari-son in the following discussion of design choices.

6.1. Design

Our design is based on a single idea, namely that eachprocess can be represented as a component with clearlydefined interface to the rest of the system, and multipleuser selectable model implementations. The idea is usedthroughout the system, subprocesses are components aswell, and auxiliary functionality such as initializationand logging are implemented using the same mechanism.

Table 2Comparison between main simulation results obtained by water transport models based on Richard’s equation and linked linear reservoirs, respect-ivelya

Water balance in mm

Potential evapotranspiration 499Inputs R.Eq.* Lin. Res.† Outputs R.Eq. Lin. Res.Precipitation 763 763 Evapotranspiration 448 440Storage change 8 2 Percolation 306 321Mineral nitrogen balance in kg N/haInputs R.Eq. Lin. Res. Outputs R.Eq. Lin. Res.Deposition 15 15 Denitrification 0 0Fertilization 180 180 Plant uptake 268 263Mineralization 73 72 Leaching 5 9Change in storage 25 25Dry Matter Yield in hkg DM/haS. Barley R.Eq. Lin. Res. Grass R.Eq. Lin. Res.Grain 48 47 Stem and leaf 31 29Straw 52 53Nitrogen Yield in kg N/haS. Barley R.Eq. Lin. Res. Grass R.Eq. Lin. Res.Grain 77 74 Stem and leaf 75 72Straw 34 34

a *Richard’s equation.†Linked Linear Reservoirs.

Fig. 13. Simulated daily percolation at 60 cm depth. Comparisonbetween results obtained with a water transport model based on Rich-ards equation and linked linear reservoirs, respectively. During thehigh percolation event in July the maximum percolation obtained bythe linked linear reservoir model was 29.5 mm and the correspondingvalue for the Richards equation model was 24.6 mm and this valuewas obtained one day later.

Daisy itself can also be viewed as a component that canbe plugged into larger systems.

The APSIM developers have chosen quite a differentpath. APSIM is structured around a single central controlunit, called the “Engine”, which other modules plug into.The main task of the engine is to pass messages betweenthe plug-in modules. These modules are similar to someof the higher level components in Daisy, which is notsurprising since we are simulating the same processes,often even using different implementations of the same


models. The main difference is that where APSIM has aflat structure and the modules are peers, Daisy is strictlyhierarchical, allowing the component design to be reusedon many different levels.

Our experience with the component design has beenmostly positive.

O The component structure forces the programmer toconcentrate on the interfaces, and to maintain them.This is basically just good software engineering prac-tice, but deadlines and work pressure often makes youderive from it, with well known bad effects on main-tainability and stability. The component structuremakes it harder to cheat than to do it right.

O Writing good interfaces is hard! Not a surprising dis-covery, but a task where the skills of computer scien-tists nicely supplement the skills of application scien-tists.

O It is often, but not always, necessary to change theinterfaces. Usually, adding new processes requireschanges to the interfaces of the existing components,while in many cases new models of existing processescan be implemented without any interface changes.

O The component structure has been an invaluable helpin dealing with concurrent development for multipleprojects. Daisy is constantly part of several differentdevelopment projects, with widely different goals. Insome projects Daisy helps to model large areas, andother projects focus on detailed modelling of specificprocesses. Having different stable and developmentmodels for different projects available and selectablefrom the setup files simplifies the modelling work.

O The component structure often ends up being usefulin unexpected places. For example the componentused for writing log files and checkpoints provedflexible enough to allow us to write a model for trans-ferring arbitrary state information to another system,that used Daisy as a component.

O The design takes some time getting used to, andtogether with the lack of C++ experience in the com-munity, it means that attempts to extend Daisy inpractice require cooperation from experienced devel-opers.

6.2. Tools

6.2.1. LanguageThe APSIM simulation engine is coded in FOR-

TRAN77, while Daisy is coded in C++. FORTRAN77was chosen for APSIM because it is well known in thescientific community, whereas C++ was chosen forDaisy because it has the language features required forthe rather ambitious design, whithout sacrificing speed.Daisy has been coded to use only ISO C++ features andno libraries apart from those described by the ISO stan-

dard, and is thus portable to all platforms where a stan-dard conforming C++ compiler exists. APSIM has beenported to many platforms.

Experience has shown us that the decision to chooseFORTRAN77 for APSIM was well justified. Few scien-tists are fluent in C++. However, the language hasproved very powerful, and a great help in the develop-ment of Daisy. Furthermore, we have found that mostof our collaborators are able to program in C, whichessentially is a subset of C++. This means it is reason-ably easy to wrap a C++ interface over a modelimplemented in C, making it directly usable in Daisy.We have also provided a C interface to Daisy for pro-jects that want to use Daisy as a component.

New users facing a similar choice as APSIM andDaisy may want to consider using FORTRAN90, whichprovides more powerful language features than FOR-TRAN77, but in a form hopefully more familiar to thescientific community.

6.3. User interface

APSIM comes with a graphical user interface GUIthat allows the user to select modules, set up croprotations, and view output. The GUI is written inMicrosoft Visual C++ and Visual Basic, and is thus notas portable as the simulation engine. Daisy has no stan-dard graphical interface. Instead, text files are used forsetting up the simulation, and produce output in tab sep-arated columns suitable for viewing by spreadsheets andother standard data presentation programs.

Another characteristic of the user interface is that theDaisy executable contains all implementations of allmodels, while the APSIM executable only contains theimplementations actually used. This means that withDaisy, the user can select models by editing the inputfiles and run the executable, while the APSIM user willhave to wait for the GUI to relink the executable. It alsomeans that the Daisy executable will be larger, but thatis not really significant on modern operating systems,because only the part of the executable being used isloaded to memory.

Our experience with the text based interfaces is posi-tive, but many users want to supplement them with GUItools to allow Daisy to be used by less experiencedpeople. Three different GUI’s have been prototyped, onefor setting up a crop rotation, one for interfacing withGIS systems, and one for browsing the various modelsand parameters. They are developed by three differentorganizations. We believe that this reflects the diverseneeds of the Daisy user community, and complementsour decision to focus on functionality, rather than graphi-cal user interfaces.


6.4. Developer interface

The characteristics of the developer interface are simi-lar in the way of thinking to the characteristics in theuser interface. APSIM comes with a specializeddeveloping environment including editors and testingutilities, and even standard procedures for developingnew code. In contrast, people who download Daisy willget a GNU Makefile and a Borland project file, and thatis it. Of course, during development of Daisy we use anumber of tools and techniques internally, but we do notconsider them part of the Daisy project, or relevant to it.

We have experienced two benefits from this. The firstis that Daisy is easy to incorporate in other projects, asit doesn’t come with its own set of support tools or pro-cedures. The second is simply that it is easy to distributethe Daisy sources, there is little to set up for the receiver.However, we cannot be certain that the informal natureof the project development will continue to serve wellas the project grows, or if we will come to rely on stan-dard tools and practices.

6.5. Future

Basically, we believe that the design and implemen-tation by now has proven itself, so focus has changedback to improving the models and adding support fornew processes, as well as continued integration in othersystems. Long term changes include improved descrip-tion of the agroecosystem and better support for distrib-uted modelling. Improved description of the agroecosys-tem includes adding process descriptions for phenomena,which are not yet included in the model, e.g., the effectof soil tillage on the transport processes in the soil, andutilizing the new functionality included in the model dur-ing the rewrite, e.g., simulation of clover/grass mixturesand rhizodeposition.

7. Concluding remarks

As described in the introduction, Daisy is a well testedmodel. With the rewrite, a number of new models havebeen implemented, allowing for the simulation of inter-cropping systems and multiple soil columns. However,thanks to the component interface, the old well testedmodels are still available.

Since the rewrite, Daisy has been used in a numberof on-going projects, and experience supports our claimthat Daisy is an open model.

O Daisy has been linked to the distributed hydrologicalcatchment model MIKE/SHE at code level. This illus-trates the use of Daisy as a component of a largersystem, using the C API described in Section 4.4.

O A new bioclimate module based on resistance theory

for the exchange of water vapour and heat in a canopyis being developed. This illustrates how to implementalternative models, using the C++ API described inSection 4.3.

O A number of crops have been parameterized since theimplementation of the general crop model, and is nowincluded in the standard library, illustrating the para-meterization facility described in Section 4.2.

O Support for pesticides has been designed, and itappears that the implementation will be able to reusethe existing solute transport and adsorption compo-nents mentioned in Section 3.2.2, indicating that thenew software design is sufficiently robust to allownew processes to be added.

Acknowledgements

We would like to thank DINA for financing the Daisyrewrite, Lars P. Fischer for providing lots of input duringthe initial design, Peter Sestoft for supervising the pro-ject and making it happen, Jens Jeppesen and RinoRanheim who implemented the GUI front-end, andDepartment of Agricultural Systems, The Danish Insti-tute of Agricultural Sciences for co-financing the GUItogether with DINA and KVL.

References

Abbott, M.B., Bathurst, J.C., Cunge, J.A., O’Connell, P.E., Rasmussen,J., 1986a. An introduction to the European Hydrological System —Systeme Hydrologique Europe´en “SHE” 2: Structure of a physi-cally based distributed modelling system. Journal of Hydrology 87,61–77.

Abbott, M.B., Bathurst, J.C., Cunge, J.A., O’Connell, P.E., Rasmussen,J., 1986b. An introduction to the European Hydrological System —Systeme Hydrologique Europe´en “SHE”, 1: History and philosophyof a physically based distributed modelling system. Journal ofHydrology 87, 45–59.

Abrahamsen, P. (1997) Daisy Programmers Guide.,URL:http://www.dina.kvl.dk/~abraham/daisy/guide/guide.html.

Abrahamsen, P. (1998) The Daisy C API.,URL:http://www.dina.kvl.dk/~abraham/daisy/c-api/c-api.html.

Blicher-Mathiesen, G., Grant, R., Jensen, C., Nielsen, H., 1990. Lando-vervagningsoplande. Faglig rapport fra DMU, nr. 6.

Blicher-Mathiesen, G., Nielsen, H., Erlandsen, M., Berg, P., 1991.Kvælstofudvaskning og udbytte ved ændret landbrugspraksis, Mod-elberegninger med rodzonemodellen DAISY. Faglig rapport fraDMU, nr. 27.

Diekkruger, B., So¨ndgerath, D., Kersebaum, K.C., McVoy, C.W.,1995. Validity of agroecosystem models. A comparison of resultsof different models applied to the same data set. Ecological Model-ling 81, 3–29.

EEA (1995) Europe’s Environment. The Dobris Assessment. The Eur-opean Agency, Copenhagen.

Engel, Th., Priesack, E., 1993. Expert-N, a building-block system ofnitrogen models as resource for advice, research, water manage-ment and policy. In: Eijsackers, H.J.P., Hamers, T. (Eds.), Inte-grated Soil and Sediment Research: A Basis for Proper Protection.


Kluwer Academic Publishers, Dodrecht, The Netherlands, pp.503–507.

Gamma, E. Helm, R., Johnson, R. Vlissides, J., 1994. Design Patterns.Addison-Wesley, Reading, Mass.

Hansen, S., Jensen, H.E., Nielsen, N.E., Svendsen, H., 1990. DAISY:Soil Plant Atmosphere System Model. NPO Report No. A 10. TheNational Agency for Environmental Protection, Copenhagen, 272pp.

Hansen, S., Jensen, H.E., Nielsen, N.E., Svendsen, H., 1991a. Simul-ation of nitrogen dynamics and biomass production in winter wheatusing the Danish simulation model Daisy. Fertilisation Research27, 245–259.

Hansen, S., Jensen, H.E., Nielsen, N.E., Svendsen, H., 1991b. Simul-ation of nitrogen dynamics in the soil plant system using the Danishsimulation model Daisy. In: Kienitz, G., Milly, P.C.D., van Gen-uchten, M.Th., Rosbjerg, D., Shuttleworth, W.J. (Eds), Hydrolog-ical Interactions Between Atmosphere, Soil and Vegetation. IAHSPublication No. 204, pp. 185–195

Hansen, S., Jensen, H.E., Nielsen, N.E., Svendsen, H., 1991c. Simul-ation of biomass production, nitrogen uptake and nitrogen leachingby using the Daisy model. In: Soil and Groundwater ResearchReport II: Nitrate in Soils, 1991: 300–309. Final Report on Con-tracts EV4V-0098-NL and EV4V-00107-C. DG XII. Commissionof the European Communities.

Hansen, G.K., Jensen, N.H., Jensen, C., Stougaard, B., Platou, S.W.,1992. Jordbundsvariation og jordbonitet i Danmark. In: Mikkelsen,S.A. (Ed.), Tidskrift for Planteavl Specialserie, Beretning S2224,Braklægning, Planteproduktion og Miljø.

Hansen, G.K., Svendsen, H., 1994. Modelberegninger og optimering afN-balancer i sædskifter for svinebrug pa˚ lerjord, vandet og uvandetsandjord. SP rapport Nr. 15, Statens Planteavlsforsøg.

Hansen, G.K., Svendsen, H., 1995a. Optimizing of nitrogen applicationon pig farms by simulation. In: Giupponi, C., Marani A., Morari,F. (Eds), Modelling the fate of agrochemicals and fertilizers in theenvironment, Proceedings of the International Workshop in Venice(Italy), 3–5 March 1994.

Hansen, G.K., Svendsen, H., 1995b. Udbytter og kvælstofudvaskning.Systemanalyser med Daisy-modellen af N-balancer. SP rapport Nr.12. Statens Planteavlsforsøg.

Hansen, G.K., Svendsen, H., 1995c. Nitrogen balances influenced byfarm management, Soil types and climate. In: Olesen, S.E. (Ed.),Proceedings of the Seminar on Site Specific Farming, SP-ReportNo. 26, Danish Institute of Plant and Soil Science, pp. 181–185.

Jansson, P.-E., Halldin, S., 1980. Soil water and heat model. Technicaldescription. Technical Report 26, 1980. Swedish Coniferous ForestProject. Dept. of Ecology and Environment Research. SwedishUniversity of Agricultural Sciences, Uppsala, Sweden.

Jensen, C., Stougaard, B., Jensen, N.H., 1992. The integration of soilclassification and modelling of N-balances with the DAISY model.In: Eijsackers, H.J.P., Hamers, T. (Eds.), Integrated Soil and Sedi-ment Research: A Basis for proper Protection. Kluwer AcademicPublishers, The Netherlands, pp. 512–514.

Jensen, C., Østerga˚rd, H.S., 1993, Nitratudvaskning under forskelligedyrkningsforhold. In: Pedersen, C.A˚ . (Ed.), Oversigt overlandsforsøgene, Landsudvalget for Planteavl.

Jensen, C., Stougaard, B., Olsen, P., 1994a. Simulation of nitrogendynamics at three Danish locations by use of the DAISY model.Acta Agric. Scand., Sect. B, Soil and Plant Science 44, 75–83.

Jensen, C., Stougaard, B., Østergaard, H.S., 1994b. Simulation of thenitrogen dynamics in farm land areas in Denmark 1989–1993. SoilUse and Management 10, 111–118.

Jensen, C., Stougaard, B., Østergaard, H.S., 1996. The performance ofthe Danish simulation model DAISY in prediction of Nmin at spring.Fertilisation Research 44, 79–85.

Jensen, L.S., Mueller, T., Nielsen, N.E., Hansen, S., Crocker, G.J.,Grace, P.R., Klir, J., Ko¨rschens, M., Poulton, P.R., 1997. Simulat-ing trends in soil organic carbon in long-term experiments usingthe soil-plant-atmosphere model DAISY. Geoderma 81 (1/2), 5–28.

Johnsson, H., Bergstro¨m, L., Jansson, P.-E., Paustian, K., 1987. Simu-lated nitrogen dynamics and losses in a layered agricultural soil.Agricultural Ecosystems and the Environment 18, 333–356.

Magid, J., Kølster, P., 1995. Modelling nitrogen cycling in an ecologi-cal crop rotation — an explorative trial. Nitrogen Leaching in Eco-logical Agriculture 12, 77–87.

McCown, R.L., Hammer, G.L., Hargreaves, J.N.G., Holzworth, D.P.,Freebairn, D.M., 1996. APSIM: a Novel Software System forModel Development, Model Testing and Simulation in AgriculturalSystem Research. Agricultural Systems 50, 255–271.

Mueller, T., Jensen, L.S., Magid, J., Nielsen, N.E., 1996. Temporalvariation of C and N turnover in soil after oilseed rape incorpor-ation in the incorporation in the field: simulation with the soil-plant-atmosphere model Daisy. Ecological Modelling 99, 247–262.

Petersen, C.T., Jørgensen, U., Svendsen, H., Hansen, S., Jensen, H.E.,Nielsen, N.E., 1995. Parameter assessment for simulation ofbiomass production and nitrogen uptake in winter rape. EuropeanJournal of Agronomy 4 (1), 77–89.

Smith, P., Smith, J.U., Powlson, D.S., Arah, J.R.M., Chertov, O.G.,Coleman, K., Franko, U., Frolking, S., Gunnewiek, H.K., Jenkin-son, D.S., Jensen, L.S., Kelly, R.H., Li, C., Molina, J.A.E., Mueller,T., Parton, W.J., Thornley, J.H.M., Whitmore, A.P., 1997. A com-parison of the performance of nine soil organic matter models usingdatasets from seven long-term experiments. Geoderma 81 (1/2),153–222.

Smith, R.E., 1992. Opus: An Integreated Simulation Model for Nonpo-int-Source Pollutants at the Field Scale. US Department of Agricul-ture. Agricultural Research Service. ARS-98, Fort Collins, Color-ado. 120 pp.

Styczen, M., Storm, B., 1993a. Modelling of N-movement on catch-ment scale — a tool for Analysis and Decision Making. 1. ModelDescription. Fertilisation Research 36, 1–6.

Styczen, M., Storm, B., 1993b. Modelling of N-movement on catch-ment scale — a tool for Analysis and Decision Making. 1. A CaseStudy. Fertilisation Research 36, 7–17.

Svendsen, H., Hansen, S., Jensen, H.E., 1995. Simulation of crop pro-duction, water and nitrogen balances in two German agro-ecosys-tems using the Daisy model. Ecological Modelling 81, 197–212.

van Keulen, H., Penning de Vries, F.T.W., Drees, E.M., 1982. A sum-mary model for crop growth. In: Penning de Vries, F.T.W., vanLaar, H.H. (Eds.), Simulation of Plant Growth and Crop Pro-duction. Simulation Monographs. PUDOC, Wageningen, pp. 87–97.

Vereecken, H., Jansen, E.J., Hack-ten Broeke, M.J.D., Swerts, M.,Engelke, R., Fabrewiz, F., Hansen, S., 1991. Comparison of simul-ation results of five nitrogen models using different data sets. In:Soil and Groundwater Research Report II: Nitrate in Soils, 1991:321–338. Final Report on Contracts EV4V-0098-NL and EV4V-00107-C. DG XII. Commission of the European Communities.

Vanclooster, M., Viaene, P., Diels, J., Feyen, J., 1995. A deterministicvalidation procedure applied to the integrated soil crop model. Eco-logical Modelling 81, 183–195.

Wagenet, R.J., Hutson, J.L., 1989. LEACHM, A process-based modelof water and solute movement, transformations, plant uptake andchemical reactions in the unsaturated zone. Version 2. Center ForEnvironmental Research, Department of Agronomy, Cornell Uni-versity, Ithaca, New York, pp. 148.

de Willigen, P., 1991. Nitrogen turnover in the soil-crop system; com-parison of fourteen simulation models. Fertilisation Research 27,141–149.

Date post:	06-Mar-2016
Category:	Documents
Upload:	robert-noddebo-poulsen
View:	212 times
Download:	0 times

EMS_2000_15_313-330

Documents