EMS_2000_15_313-330

Environmental Modelling & Software 15 (2000) 313–330 www.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. The model aims at simulating water balance, nitrogen balance and losses, development in soil organic matter and crop growth and production in crop rotations under alternate management strategies. The software, which recently was rewritten, has been carefully designed to facilitate interaction with other models, either by replacing individual Daisy processes or by using Daisy as a part of a 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 of alternative models

Software availability Program title: Daisy — A soil/crop/atmosphere model Developers: Søren Hansen and Per Abrahamsen Contact address: Søren Hansen, The Royal Veterinary and Agricultural University, Department of Agricultural Sciences, Laboratory for Agrohydrology and Bioclimatology, Agrovej 10, 2630, Ta˚strup, Denmark Tel.: +45-35-28-33-83 Fax: +45-35-28-33-84 E-mail: daisy@dina.kvl.dk URL: http://www.dina.kvk.dk/苲daisy/ First available: 1999 Hardware required: To run the binary, a PC with at least 32 MB ram. To compile: Any modern computer with at least 64 MB ram.

Software required: To run the binary: A win32 platform such as Win95, Win98, or WinNT; To compile: Any OS with GCC 2.95 or later, or a win32 platform 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-2833-84.

E-mail addresses: daisy@dina.kvl.dk (P. Abrahamsen), sha@kvl.dk (S. Hansen).

downloaded at no charge from the specified URL.

1. Introduction The loss of nitrogen into aquifers and surface waters in humid regions is an inevitable consequence of intensive agriculture. In large parts of Europe, for instance, the input to agricultural systems and the subsequent losses are so large that they constitute a threat to both the quality of surface and ground waters (EEA, 1995).

In most agricultural systems the main loss of nitrogen is due to leaching of nitrate from the fields. The fact that laboratory and field measurements necessary for assessment of nitrogen leaching from agricultural fields are expensive has prompted the development of agroecosystem models capable of simulating the nitrogen dynamics in agricultural soils and in particular simulating the leaching. In Denmark this led to the development of the Daisy 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 and Svendsen, 1995a,b,c; Jensen and Østerga˚rd, 1993; Jensen et al. 1992, 1996; Jensen et al., 1994a,b; Magid

1364-8152/00/$ - see front matter  2000 Elsevier Science Ltd. All rights reserved.

PII: S 1 3 6 4 - 8 1 5 2 ( 0 0 ) 0 0 0 0 3 - 7

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 applications comprise both scientific studies and management related studies aimed at decision support. In addition, the model has been validated in a number of major comparative 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, and water and nitrogen dynamics in agricultural soil based on information on management practices and weather data (daily values), Fig. 1. If the model is applied to areas with shallow groundwater, information on the position of the groundwater table is also required. The model can be viewed as an ensemble of processes, and in order to apply the model, the process-models must be initialized and parameterized, Fig. 1.

Recently, the Daisy model has been reimplemented.

The new model software offers extensions as compared with the original FORTRAN implementation, e.g., the simulation of multiple soil columns and inter-cropping systems. The latter feature is very useful in simulating organic farm rotations. More important, the new implementation has developed the model into an open software system that supports an easy exchange of process-model descriptions. In a scientific study this feature facilitates easy testing of alternative process descriptions, and in a management oriented study, the process description could be chosen on the basis of the required accuracy, the available data or available resources in terms of computer-time. Furthermore, the design allows for an easy implementation of new processes, e.g., adding the simulation of the fate of other agrochemicals

than the nitrogen species that were considered by the original FORTRAN implementation. In addition, the new implementation supports the linkage of Daisy with other 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 simulate groundwater quality within a hydrological catchment.

However, in order to do this they had to run the two components of the combined model system MIKE SHE/Daisy iteratively. Such a procedure is sub-optimal.

With the new implementation it is feasible to link Daisy to other models at code level. Daisy can now function as a component in a modelling system like MIKE SHE. The latter linkage is only feasible because the new Daisy model software can work in a distributed way, i.e. work with multiple soil columns.

An analysis of the original FORTRAN code revealed that the revision required, in order to develop the model into a flexible and versatile software tool, would be most extensive. Hence it was decided to redesign and rewrite the code. The basic building blocks of the new code are the process-models.

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

2. Model description A model is always a simplified representation of a real system and as such it is based on simplifying assumptions. A basic assumption in Daisy is that the modelled system can be represented by a one dimensional model.

This is a common assumption in this kind of agroecosystem models, e.g., LEACHM, (Wagenet and Hutson, 1989), SOILN (Johnsson et al., 1987), Opus (Smith, 1992), and WAVE (Vanclooster et al., 1995). Daisy simulates the parts of the water, carbon and nitrogen cycles that are related to agricultural soil systems. In addition, the soil thermal regime is simulated. An overall description of the model is given in the following. For further details is referred to Hansen et al. (1990, 1991a).

2.1. Water balance

Fig. 1.

Schematic overview of the Daisy model system.

The adopted schematization of the water dynamics in agricultural soils is illustrated in Fig. 2.The boxes represent storage of water, and the arrows represent flow of water or water vapour. Precipitation and irrigation represent driving variables or boundary conditions. Another driving variable or boundary condition, which is only given implicitly in the figure, is the potential evapotranspiration which forms both the driving force and the upper limit in the evaporation/transpiration processes. In

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

315

2.1.2. Interception by canopy Interception of water in the crop canopy is mimicked by a simple capacity model. The interception capacity depends on the leaf area of the canopy. Through-fall occurs when the interception capacity is exceeded.

2.1.3. Infiltration and ponding Ponding only occurs when water is allocated to the soil surface at a rate higher than the maximum infiltration rate. The latter being determined by the conditions within the soil itself.

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

the evapotranspiration calculations, evaporation from free water surfaces has priority over transpiration and soil evaporation.

2.1.1. Snow accumulation and melting The 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 and frozen water in the snowpack. Water is lost from the snowpack as evaporation or sublimation and as percolation when the retention capacity of the snowpack is exceeded. Evaporation has priority over sublimation.

The freezing-melting within the snowpack depends on air temperature, global radiation, ground heat flux (simulated by the soil temperature model), and albedo and depth of the snowpack. The last two are internal snowpack variables.

Fig. 3.

Schematic presentation of the snowpack model in Daisy.

2.1.4. Soil evaporation Soil evaporation only takes place if the demand by potential evapotranspiration is not fulfilled by evaporation from free water surfaces. The part of the potential evapotranspiration that is not used by these evaporative processes is split between the crop and the soil by a function of leaf area. The soil’s ability to deliver water is simulated by a potential exfiltration rate, which is determined by the conditions within the soil itself. The soil evaporation is now defined by the minimum of the two.

2.1.5. Soil water dynamics The soil water dynamics constitutes one of the most important parts of the model. Simulation of movement of water within the soil is based on potential theory and is based on a numeric solution to Richard’s equation.

Richard’s equation is a second order partial differential equation and as such it requires knowledge of two boundary conditions. The upper boundary is determined by the infiltration rate (the rate at which water is allocated to the soil surface), soil evaporation rate, or if ponding occurs, a known potential at the soil surface.

The lower boundary is defined by a known potential if the position of the groundwater table has been externally defined. In this case capillary rise can occur. Another possible boundary condition is free drainage. In this case the percolation is determined by the conditions within the soil itself.

2.1.6. Transpiration Transpiration is determined by root uptake of water.

Storage of water within the plants is neglected, hence transpiration equates the soil water uptake by roots. The previously calculated part of the potential evapotranspiration that is allocated to the crop forms the upper limit for transpiration. The water uptake by roots depends on the rooting depth and the root density distribution in connection with the soil water status within the rooting depth. The uptake is modelled by the single root concept, which is applied within each of the numeric layers that the solution to Richard’s equation works with. In the single root concept water is assumed to move radially towards the root surface where it is taken up at the same

316

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

rate it arrives at the surface. The flow of water is then determined by the conditions in the soil and the conditions at the root surface. The latter being regulated by the plant. It is a basic assumption that the plant only is able to lower the potential at the root until the potential that corresponds to the permanent wilting point, hence this condition sets the limit for the uptake. Furthermore, it is assumed that a single root exploits the soil around it corresponding to the volume within a cylinder with a radius corresponding to half the average distance between roots. Another basic assumption in this approach is that the developed potential distance profile that develops around an absorbing root can be approximated by the corresponding steady state profile. Hence the dynamics of the uptake is approximated by a series of steady-states. The total uptake which corresponds to the transpiration is obtained by integrating the whole rooting zone.

2.2. Carbon and nitrogen cycling The adopted schematization of the considered carbon cycle related to agricultural soils is illustrated in Fig. 4.

The boxes represent storage and the arrows represent flows. Carbon input to the system is through the process of photosynthesis and through amendment of organic fertilizers. Carbon is lost to the atmosphere through respiratory processes in the plant and the soil microbes.

2.2.1. Crop growth Photosynthesis and plant respiration is simulated by a crop model. Important features of the crop model are the ability to simulate the temporal variation in leaf area index (LAI), rooting depth, root density, dry matter production, and crop nitrogen demand and content because this information is required by other parts of the model.

The crop model included in the original version of Daisy mimics the canopy photosynthesis as a function of LAI, global radiation, air temperature and any water and/or nitrogen stress. Water stress occurs when the water uptake by the roots is less than the potential transpi-

Fig. 4. Schematic presentation of the Carbon cycle component included in Daisy.

ration. Nitrogen stress occurs when the nitrogen concentration in the plants gets below a certain threshold. The produced assimilates are then partitioned between the considered plant compartments, and growth and maintenance respiration takes place resulting in net production of the considered compartment. The considered plant compartments are shoot, root and for root crops also storage organs. The assimilate partitioning is governed by a development stage representing the phenological development of the crop. The development rate is simulated by a function of temperature. The LAI is simulated as a function of shoot dry matter and development stage.

Root penetration is governed by the plant, soil temperature and restrictions in the soil. Root density is governed by rooting depth and accumulated root dry matter. At harvest, the shoot dry matter is partitioned between the economically interesting part, e.g., grain, and the economically less interesting part, e.g., straw, and fractions of these are then removed as yield. The leftovers or residues, including root material, can then be transferred to the soil organic matter.

As the original crop model does not allow for the simulation of the competition between plant species, the original model has been further developed in order to cope with the inter-cropping situation. The new development is based on the principles of SUCROS (Simple and Universal CROp growth Simulator, van Keulen et al., 1982). The new crop model is more detailed than the old one and simulates dry matter in leaf, stem, storage organ, and root explicitly.

2.2.2. Organic matter turnover The soil organic matter model considers three distinctive types of organic matter, viz. newly added organic matter (AOM), living soil microbial biomass (SMB), and native nonliving soil organic matter (SOM). For each new amendment of organic matter a supplemental AOM is formed. The turnover of these pools is simulated by subdividing each of them into two subpools and applying first order degradation to the individual subpools. Furthermore, it is assumed that carbon in form of CO2 is lost from the system due to growth and maintenance respiration of SMB. The carbon flow between the individual pools is illustrated in Fig. 5. The first order degradation rates and the maintenance respiration rates are modified according to soil temperature and soil water expressed in terms of the soil water pressure potential.

Furthermore, the degradation rates may be modified according to nitrogen stress. As illustrated in Fig. 5, the turnover of organic soil nitrogen is closely linked to the turnover of organic carbon.

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

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

317

2.2.3. Nitrogen uptake Plant uptake of mineral nitrogen is determined either by the plants’ nitrogen demand or the availability of mineral nitrogen in the soil. The former is simulated on the basis of a potential nitrogen content in the plant, which is determined on the basis of the accumulated dry matter production and the development stage of the plant, and the actual nitrogen content of the plant. The latter is determined on the basis of the actual content of mineral nitrogen in the soil and the transport from the bulk soil to the root surfaces. Two mechanisms are assumed to be active in this transport, viz. mass-flow with the transpiration stream and diffusion to the root surface. The basic assumptions in these calculations correspond to the assumptions made for the calculation of the water uptake (transpiration stream).

Fig. 5. Schematic presentation of the soil organic matter turnover model included in Daisy (AOM=added organic matter, SMB=soil microbial biomass, SOM=native soil organic matter). Organic input is subdivided in structural, metabolic and recalcitrant organic matter.

2.2.4. Mineral nitrogen balance The ammonium sources are deposition, fertilization and ammonification, and the sinks are plant uptake, immobilization, nitrification and leaching (Fig. 6). For nitrate, the sources are deposition, fertilization, and nitrification, and the sinks are plant uptake, immobilization, denitrification and leaching. Deposition comprises both dry and wet depositions. Leaching is a result of numeric solutions to the convection-dispersion equation for ammonium and nitrate, respectively. These equations also keep track of how ammonium and nitrate are distributed within the considered soil profile. Like Richard’s equation, the convection–dispersion equation is a second order partial differential equation and a solution requires knowledge of two boundary conditions. In this case, the upper boundary condition is always a flux condition and the lower boundary condition is a zero-gradient condition.

2.3. Soil temperature

Fig. 6. Schematic presentation of the Nitrogen cycle component included in Daisy.

nitrogen is often termed immobilization. Organic nitrogen is lost from the system due to harvest of organic plant material or due to ammonification (mobilization).

Organic nitrogen comprises two pools, viz. organic nitrogen in the crop and in the soil.

As stated above, the organic soil nitrogen is subdivided into a number of subpools of organic matter each characterized by a fixed C:N ratio. Whether mobilization (ammonification) or immobilization takes place is determined by the carbon turnover and the corresponding C:N ratios of the considered organic matter pools (Fig. 5). If immobilization takes place and insufficient mineral nitrogen is available, then nitrogen stress occurs and the turnover is hampered.

The thermal regime of the soil is simulated by a numeric solution to the heat flow equation, taking both transfer of heat by convection and conduction into account.

3. Daisy software design In this section, the main abstractions used in the Daisy software are described. Section 3.1 gives a summary of the sequence of events in the program during a simulation run. Section 3.2 gives a static description of the main components of the simulation and their relationships. Finally, Section 3.3 describes what a component in Daisy is and the ability of the component from a programmer’s perspective.

318

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

3.1. The main software components At a sufficient high level of abstraction, all programs are 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 parsing the input. This is done by a parser component, which is conceptually completely separate from the main simulation component. The second phase is the simulation itself. The simulation model contains the physical state and processes in a number of column components (described in Section 3.2), some driving variables in the manager, weather, and time components, and a separate log component whose purpose is to write selected parts of the state to files for later inspection. These components are described further below. The word component has a specific meaning in Daisy, as described in Section 3.2 and 3.3.

3.1.1. Parser The parser translates text according to an external abstract syntax into an internal parse tree. That the syntax is abstract means that it describes the expected input on a fairly high abstraction level. E.g., the component “Denitrification” has a member “alpha” of type “number”. The concrete syntax is implemented in the parser itself.

3.1.1.1. Concrete syntax The separate implementation of the abstract and concrete syntax has several advantages. One of these is that the concrete syntax can be replaced by a new parser. That is, the default parser might 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 would like a less lisp-like (less parentheses) look, another parser might accept a C-like concrete syntax, such as alpha⫽0.1; and could be implemented without changing the rest of the 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 use one syntax and other files the other syntax.

3.1.1.2. Abstract syntax The ability to change the parser is of little practical value, since it is easier for a user to only have to learn a single syntax. Much more useful is the separation of the abstract syntax from the parser itself. This means the abstract syntax can be changed or expanded (i.e. adding new parameters) without touching the parser. In Daisy, this has been taken a step further. The implementation of each model in Daisy is responsible for providing its own abstract syntax. This means that changes in a model do not affect the code outside the file that implements the model itself. This is a key feature enabling the flexible component design described in Section 3.3.

3.1.1.3. Attribute lists The output of the parser is an abstract parse tree, implemented in Daisy as an attribute list. An attribute list is an unordered set of (name, value) pairs. The name is a string, “alpha” in the example above. The value in that example is the floating-point number 0.1. The value could also be an integer, a date, a string or any of the other types useful for parameterizing models in Daisy. One type warrants special mention.

Fig. 7 shows that time is the only component in the simulation likely to be described by a simple type. Each of the other components requires its own set of parameters. This is solved by allowing the value itself to be an attribute list. This attribute list should then have the elements required by the abstract syntax provided by the component to the parser.

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

3.1.2. Driving variables The weather model and the manager model can be viewed as external to the physical modelling of the soil crop system.

3.1.2.1. Weather The weather model must provide a number of meteorologic data used by the physical model, for example air temperature and precipitation.

Usually, these are read from a file containing daily average numbers. These numbers are then distributed through the day using astronomical data derived from the time of the year and the longitude.

There are also a number of alternate weather models which can be used. One weather model can read a file with hourly values, other models can create “artificial weather” or even “no weather” (all numbers are constant). These models are obviously unrealistic, but can be useful for testing components of the simulation under simplistic assumptions.

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

319

3.1.2.2. Manager The manager is an instance of a component type called action. The build-in actions can be divided into two categories, the primitive actions such as plowing or harvesting, and the composite actions providing programming language primitives such as “progn”, which combines a number of actions, and “if”, which makes an action depend on a given condition.

Condition is another component type, used when specifying actions and specifying logs. Again, there are two categories of conditions, primitives which test the state of the simulation such as “at”, which is true at a specific point in time, and logic conditions such as “and” which combines other conditions.

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

3.1.3. Logs The 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 variables to a user-specified file in user-specified intervals.

The state variables can be averaged or accumulated over the interval or the complete simulation at the users preference. The format is tabulator separated columns.

The checkpoint writes all state variables to a user specified file at a user specified point of time, in the same format in which the parser expects them to be when initializing the simulation. This can be used to “hotstart” the simulation at that point in a later run.

Other kinds of logs can be implemented, for example a log that displays a state variable dynamically while the simulation runs.

3.2. The column component The Daisy model itself includes specialized models of the specific processes in the simulation. Each of these specialized models may themselves contain even more specialized models, etc. The software is organized around these models within models, each model being a replaceable component, as described in Section 3.3.

Fig. 7 introduced the top level components of the simulation. In Fig. 8 we look into the major component of the simulation, that is the column.

Daisy is basically a one dimensional model, as described in Section 1. Each column object represents a vertical line in a field from the bioclimate in top to the groundwater at the bottom. The components in Fig. 8 are organized from top to bottom to match the world they model. Each “box” in the figure represents one replaceable component. Many of the components contain subcomponents, but only the subcomponents of the bioclimate are shown.

Fig. 8.

Components of a Column.

In the following, we will discuss the organisation of the components from top to bottom, their subcomponents, and the implementations which can be chosen for each subcomponent.

3.2.1. Bioclimate The main responsibility of the bioclimate component is to distribute the meteorological input it receives from the weather model based on the various crops and the soil. The main inputs are precipitation, potential evapotranspiration, air temperature and global radiation. The precipitation is distributed on various storages, such as the canopy, the snowpack (which is a separate component), and the soil surface (also a separate component). The potential evapotranspiration is distributed among these storages, (Section 2.1). The global radiation is distributed among the crops according to the relative distribution of their canopy. A crop with a high canopy will shadow a crop with a low canopy. For instance, a spring barley might intercept almost all the radiation thus shadowing the undersown grass and preventing it from developing fully until harvest of the barley.

3.2.1.1. Crops The standard crop model is by far the most complex model in Daisy, but its interaction with the rest of the model is less complex. Basically, it has to tell the bioclimate the vertical distribution of its canopy, and in return the crop receives a potential transpiration and radiation from the bioclimate. The crop model can use these to determine how much water and nitrogen to extract from the soil.

320

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

3.2.2. Soil The main soil component serves two purposes: 앫 The region between the surface and the groundwater is divided into a number of numerical layers for computational purposes. These layers are defined by the soil component, as indicated by the horizontal lines in Fig. 8. 앫 The soil’s physical properties, such as the clay content and the hydraulic conductivity are defined on a specified list of horizon components, each representing a separate type of soil.

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

3.2.2.1. Water and heat The soil water component keeps track of water storage and transport. The transport part is delegated to a separate uz (unsaturated zone) component, which has several implementations to choose from. The most complex model provides a numerical solution to Richard’s equation. A simpler and much faster model simulates water transport as a sequence of linked reservoirs. Another model implements no water transport at all, and is used when the water transport is provided by an external model through the C API (see Section 4.4).

The soil heat component keeps track of the temperature in each soil layer by means of soil thermal properties and implements a heat flow.

3.2.2.2. Ammonium and nitrate The soil content of ammonium and nitrate is tracked by two separate components. They both allow the user to specify a transportation model by selecting a nested component. The implemented transport models available are convection dispersion, convection alone (faster), or no transport (fastest!). Selecting no transport is quite useful for ammonium, since sorption often makes ammonium transport negligible. Under normal conditions, almost all leaching is in the form of nitrate.

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

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

3.2.2.3. Nitrification and denitrification The nitrification and denitrification components allow the user to specify how to model these two processes. From a software design point of view, these two components are distinguished from the other components in Fig. 8 by not requiring any state, they are pure processes.

3.2.2.4. Organic matter and mineralization The organic matter component contains several subcomponents, in the form of “pools”, Fig. 5. The SOM pools contain the basic storage of organic matter. The AOM pools contain recently added organic matter. The SMB pools contain the living biomass of the organic matter.

Each pool has a separate C/N ratio, a separate utilization use efficiency, and a separate turnover factor. Mineralization (or immobilization) happens when the biomass absorbs substrate from one pool, converting some part of it into another pool, and the rest into energy (CO2respiration).

3.2.3. Surface and ground water The surface and groundwater components provide the boundary conditions for all the transport processes.

There is only one surface model implemented, but tree different groundwater models. First, the groundwater can be well below the part of the soil we simulate, allowing for a free drainage assumption. Secondly, the groundwater 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 implemented using variations of a design pattern (Gamma et al., 1994) invented for that purpose. A design pattern is a reusable programming technique. This section describes the component design pattern. The component design pattern is implemented in C++ programming language, and depends on concepts (such as static constructors) specific to that language. The basic structure of the pattern and indication of which C++ constructs are used for implementing it are described below.

There are two variations of the component pattern.

The first is fixed components, which implements a single model, and the second is library components that allows the user to choose from a library of implementations. In general, the library components are more flexible, since new models can be added simply by adding an object file containing an implementation of the model, and the user can choose among the available models in the input files. But they have a small overhead in both time and program complexity, therefore, fixed components are used when a need for alternative models has not been anticipated or experienced.

3.3.1. Content of a component As 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 fixed components, the programmer must specify: 앫 Interface. The interface of the component is a list of

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

321

ing the mapping. It takes the interface class as a template argument.

The ‘Library’ abstraction has another function. It allows the user to give names to specific parameterizations of the models. This functionality is provided by a function that takes the name of an existing model and an attribute list as arguments, and creates a new pseudomodel with the same syntax and constructor, but the default values are overwritten by those provided in the attribute list. Once added to the library, the new parameterization is indistinguishable from a build-in model.

Fig. 9.

앫 앫 앫

앫

Library and Fixed Components.

names and types of functions and data visible to the rest of the system. It is located in a separate file (a C++ header file) and combined into a class (a C++ abstraction that makes it possible to treat a collection of related data and functions as a single unit). Other modules must include this header file in order to communicate with the component.

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

Syntax and Values. Each fixed component must specify which parameters it accepts, their type, and thus specify default values for these parameters.

Constructor. The component should be able to construct itself given an attribute list. This is done by a function (a C++ constructor) that takes an attribute list as its argument.

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

3.3.1.2. Library components A library component consists of two parts. One is the interface, which is defined in a separate file, just like for fixed components.

However, in this case the functions are marked as virtual, which is a C++ language feature that allows multiple implementations of the function to co-exist.

The other part is the Library, a mapping (implemented as a C++ class) from a name, into a syntax, some default values, and a constructor as described for fixed components. Each name in the map corresponds to a specific model. A special language technical problem is the constructor. Each library component has its own interface class, and the constructors must return objects of that class. This means that a single, common library class alone is not enough to provide the full mapping. However, C++ provides a mechanism called templates, which enables construction of algorithms that work on many types. A template named ‘Librarian’ is used for complet-

3.3.1.3. Model implementations Each model is implemented entirely in a separate file (a C++ source file). The only way to reach the implementation is through the interface of the library component. This means that a model cannot use or provide information that was not anticipated in the design of the component.

It can, however, provide more information to the user through the logger.

Basically two tasks must be done in order to make the model available to the rest of the system. The model itself must be implemented, and the rest of the system must be informed that it exists. The first task involves writing implementations of all the functions specified in the component interface. In C++ terms, this means creating a derived class which implements all the pure virtual functions in the interface class.

The second task involves listing and specifying types for all the parameters for the model, as well as the default values where applicable, and then registration of these (together with the function to construct the model) in the component library. In C++, this is done by creating a class with a single global instance. The language rules dictate that the constructor for that class is called before the program starts, and the constructor can then ensure that the model is properly registered.

3.3.2. Input files The component functionality is reflected almost directly in the input files.

3.3.2.1. Specifying components In the input files, the difference between a fixed and a library component is that the user needs to specify the model. 앫 (name atts); Fixed component 앫 (name model atts); Library component For example, denitrification is a fixed component (only one implementation), while nitrification is a library component with two models (rate depends on the ammonium content in soil or in solute). In an input file, the specification for these two components of a column will look like this:

322

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

(Denitrification (Nitrification soil

(K 0.0417) (alpha 0.1)) (kF10 2.1e-7) (k 5.0e-5))

Here soil is the name of one of the nitrification models, while K, alpha, kF10 and k are parameters to the denitrification model and the soil nitrification model, respectively.

3.3.2.2. Adding parameterizations The interface to the functionality for adding new reusable parameterizations looks like this: 앫 (defcomponent name model atts) Here, component is the name of the library component, name is the name which the parameterization will have in the library, model is the name of an existing element in the library, and atts are the parameters to add or change compared to that model. The parameterization of the nitrification model used in the previous section can be added: (defnitrification mynit soil

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

After that, the nitrification parameters could be specified simply by using the name from the library: (Nitrification mynit)

4.1. Specifying a simulation The most obvious way to use Daisy is to setup and run a simulation. After all, Daisy is a simulation model.

The users whose need have influenced this aspect of Daisy are: 앫 Modellers. These are the scientists who provide the various models of which Daisy is composed. To validate these models, and Daisy as a whole, the modellers have to run simulations on various realistic and artificial scenarios. Daisy allows them to extract any of the state variables at any point during the simulation. 앫 Education. Daisy has been used as a tool in education.

The purpose here is to allow students to explore physical models by running and experimenting with a simulation. 앫 Policy Makers. Daisy has been used extensively by policy makers to predict the consequence of various potential decisions. Policy makers have primarily been interested in nitrogen leaching and harvest yield, but might also examine changes in the soil organic matter content to see changes in soil quality. 앫 Advisers. Agricultural advisers can use Daisy for predicting harvest yield, nitrogen leaching, mineralization (for planning fertilization), irrigation need, and changes in soil quality.

There are two ways to set up a simulation, by editing setup files directly, or through a GUI. 4.1.1. Files A minimal set-up file is shown below.

4. Using the Daisy software The design behind the reprogramming of Daisy has been constrained by the needs of several different types of users. The most basic use of the program is to specify the soil, a crop rotation, and a file containing climate information, and run the simulation. An example is given in Section 4.1. More advanced users may want to describe a specific type of soil and add it to the soil library for use in later simulation runs, or parameterize the generic crop model provided by Daisy to add a new crop to the list of crops available in a simulation. An example is given in Section 4.2. A third group of users will want to enhance the program in a more fundamental way, by adding alternatives to build-in models of the various processes in Daisy. This could be a different way to describe a crop, or a different model of the nitrification process. In Section 4.3 we discuss the procedure.

Finally, some users will want to include Daisy as a component of their own simulation programs. See Section 4.4 for information about how these users are supported by Daisy.

;; 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 close relationship between this listing and Fig. 7. Each of the ovals on the figure corresponds to one declaration in the file.

4.1.1.1. Elements The first item of the example is the input declaration. It is a little different from the other declarations in the example, in that it immediately creates a parser object which then reads more declarations.

It is possible to have many input declarations in a file,

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

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

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

The remaining elements are initializing the components of the simulation. 앫 weather. The weather component is initialized with the file model, which takes a single parameter, the file, to read the weather data from. 앫 column. The column can actually take a number of columns. In this case it only takes a single column, “MyColumn”, which is presumably a parameterization found in “library.dai”. 앫 time. The time attribute is a bit different from the others, in that it is not a “component” as described in section 3.3, but a primitive type. It is initialized with the year, month, day, and hour for the simulation start. 앫 manager. The manager is initialized with a predefined parameterization, just like “column”. 앫 output. The output is a list of log components specifying the output of the program. In this case, two parameterizations, again presumably from “library.dai”

4.1.1.2. Inline specifications It is possible to specify the 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 (weight 0.750))) (if (at 1957 8 10 1) (harvest SpringBarley)) (if (at 1957 11 1 1) (stop))))

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

The restrictions of the GUI are that it only gives access to parameters for some of the build-in models, and never for new models. However, it is possible to select an existing parameterization of one of the unsupported models.

The advantages are that the parameters are presented in an intuitive way, with supplementary text and range checking on all input fields.

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

4.2. Reusing model parameterizations Frequently, users will want to reuse parameterizations of specific components from one simulation to another.

For users of Daisy on a small scale, the main components that will end up in a parameterization library are: 앫 crop. The generic crop model requires a lot of work to parameterize a specific crop. Most users will use parameterizations provided by others, for example some of the parameterizations that are bundled with Daisy, for their crops. 앫 horizon. Often, not all the parameters needed for the physical soil model are available, but the soil type is known. In that case, one can use a library of soil types with known physical properties. This is not as good as getting the data on the actual soil used, but it is often all you can do. 앫 fertilizer. Daisy uses a single model for describing all

thus specifying the crop rotation inline.

4.1.2. GUI The file parser has been developed to give full control of all aspects of the simulation, even when new models are added. It gives access to any parameter included in the model. This includes parameters that will only be of interest to scientists researching that particular model, and the ability to set unrealistic values for any of the parameters.

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

323

Fig. 10.

Setting up a Crop Rotation.

324

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

types of organic fertilizer, with parameters such as turnover rate. When specifying the management, names for already parameterized fertilizer models like “cattle manure” or “pig slurry” are usually preferred over specifying all the parameters directly. It is certainly more readable.

Even so, the horizon and fertilizer libraries are likely to be different for different users, so unlike the crop library they are not bundled with Daisy.

Users who work with large scale simulations with many columns will find it useful to create libraries containing standard columns and standard crop rotations.

4.2.1. Input file In the input file, you can define a named parameterization of any library component.The components above are just the most useful.

To define a new manager, you use the “defaction” command. For example the manager in Section 6.1.2 could be named “MyManager” with the following declaration: (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 the library components.

4.2.2. GUI The GUI front end allows you to parameterize the standard column and horizon models as well as the manager, 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 the ability to easily add new models by linking with a file containing an implementation of the model. This is primarily useful for researchers in need of a framework to test and run their simulations, and for developers wanting to combine Daisy with other programs. However, once the model is implemented and the code distributed, everybody will be able to use the new model, and even combine it with other, independently developed models, i.e.

Daisy provides a framework for combining models.

Some reasons to write an alternative model are listed below.

Fig. 11.

Setting up a Soil Horizon.

앫 More Information. Currently a new bioclimate model based on Shuttleworth and Wallace and PenmanMonteith is being developed. It requires much more detailed weather information, but can in return also provide much more detailed information about the bioclimate. 앫 Less Information. It is not always possible to acquire all the information needed for e.g. the standard crop or organic matter models, in that case implementing a simpler model could be an option. 앫 Speed. Some of the models, such as the numerical solution to Richard’s equation, can be rather time consuming. For large simulations using a simpler model, like the “linked reservoir” model provided by Daisy, can significantly speed things up. 앫 Reuse Parameterizations. We already had parameterizations of several crops for older models. To be able to reuse these, we implemented the old crop model in the rewritten Daisy. 앫 Other Systems. Linking to other systems can also be done by writing a new model. For example, the setup GUI provides its own management model, ensuring a more direct relationship with the presentation.

A technical description of how to add an implementation of 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 Daisy through the component interface may not be an option.

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

There can be several reasons for this, e.g., there can be conceptual problems, if the other model is addressing issues outside the one dimensional soil/crop system of Daisy, or most significantly, there can be technical problems. 앫 The other model might be implemented so the main loop should be there. 앫 The interface between the models may affect many components of Daisy, and replacing them all may not be an option. 앫 The component interface is written in C++, which may not be link compatible with the implementation language of the other model. 앫 The component interface is flexible, but unusual. A more traditional interface can be easier to learn.

To address these issues, we have developed an alternative C interface. The C interface consists of a number of opaque types (like ‘daisyFweather’), and functions operating on these types (like ‘daisyFweatherFputFprecipitation’). The C interface is intended for using Daisy as a library in a (presumably larger) application. It has no facilities for adding new models to Daisy. The C API has been developed rather ad hoc, in that the functions provided are those that have been useful in other projects.

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

5. Example In order to illustrate the model’s ability to simulate inter-cropping systems and its ability to use alternative process models the following example was designed. A Spring Barley with ley is grown on a coarse sandy soil.

The simulation of water transport in the unsaturated zone was based on two different models, viz.: 앫 A numerical solution to Richard’s equation (RE). 앫 A simple linked reservoir model (LR), where no vertical transport out of a soil layer takes place when the soil water potential in the layer is below ⫺100 cm, and gravity flow takes place when the soil water potential exceeds the ⫺100 cm.

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

325

sidered a “warming up” period. The period was selected due to a, for Danish conditions, extreme precipitation event in July 1987, where the rainfall was 103.5 mm within three days. Parameterization and initialization of the model has been adopted from previous simulation studies.

The set-up file for the example is shown in Table 1.

As usual, the setup file relies on existing parameterizations retrieved from an another file (‘library.dai’). This provides us with already parameterized models for weather, crops, tillage operations and log files.

The column parameterization is of particular interest.

The already parameterized ‘JB1FAndeby’ column is further specialized into a ‘JB1Flr’ column, using a LR water transport model, and a ‘JB1FRichards’ column, using a RE-model for water transport. This illustrates both how to derive new parameterizations, and how to specify an alternative model for a specific process. In particular, ‘SoilWater’ is a fixed component inside the standard column model, containing all the parameters describing the water content of the soil. We are only interested in one of these, the ‘UZtop’ attribute, which selects 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 introduced by this example are simply enabled by listing multiple columns in the “column” specification, and sowing multiple crops in the “manager” specification.

The ability of the model to simulate inter-cropping systems is illustrated in Fig. 12, where the LAI development of the two crops are shown. Only the simulations with the LR-model are shown, because only small discrepancies between the models exist. It is noted that the grass ley develops slowly due to shadowing effect of the early developed spring barley canopy.

In Table 2, a comparison of the main elements of the water and mineral nitrogen balances are shown. Only minor discrepancies between the two model approaches are found at the annual time-scale. This is also confirmed by comparison of the simulated dry matter (DM) and nitrogen yields.

In order to compare the model approaches at a fine time-scale, the daily percolation out of the rooting zone is shown in Fig. 13. The comparison shows a clear difference in the dynamics of the two approaches, e.g., during the high percolation event in July the maximum percolation obtained by the LR-model was 29.5 mm and the corresponding value for the RE-model was 24.6 mm and this value was obtained one day later. It is noted that the RE-model exhibits an appreciable smoothing effect on the output function (percolation) as compared to the LR-model. However, for many purposes the LRmodel will do.

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

326

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

Table 1 Main set-up file containing information for simulating Spring Barley with Ley. The two water transport models, viz a model based on Richard’s equation 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) (NH4 40.0e-5))) ((at 1987 10 10 1) (harvest Grass (stub 10) (stem 1.00))) ((at 1988 4 1 1) (stop))))

;[g/cm2]=40 kg/ha ;[g/cm2]=40 kg/ha

;Leave 10 cm stub. ;Harvest everything above stub.

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

and the average user and system time was noted. We also ran the warming up time to be able to compare the approximate time for a year’s simulation. The time required for one year simulation was 56 s and 27 s with the RE and LR models for water transport, respectively.

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

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

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

Fig. 12.

Simulated LAI-Development in Spring Barley and Grass.

to create open, extensible, frameworks. One is ExpertN (Engel and Priesack, 1993), of which only few details have been published, the other is APSIM (McCown et al., 1996) which has been chosen as standard of comparison in the following discussion of design choices.

6.1. Design Our design is based on a single idea, namely that each process can be represented as a component with clearly defined interface to the rest of the system, and multiple user selectable model implementations. The idea is used throughout the system, subprocesses are components as well, and auxiliary functionality such as initialization and logging are implemented using the same mechanism.

327

Fig. 13. Simulated daily percolation at 60 cm depth. Comparison between results obtained with a water transport model based on Richards equation and linked linear reservoirs, respectively. During the high percolation event in July the maximum percolation obtained by the linked linear reservoir model was 29.5 mm and the corresponding value for the Richards equation model was 24.6 mm and this value was obtained one day later.

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

The APSIM developers have chosen quite a different path. APSIM is structured around a single central control unit, called the “Engine”, which other modules plug into.

The main task of the engine is to pass messages between the plug-in modules. These modules are similar to some of the higher level components in Daisy, which is not surprising since we are simulating the same processes, often even using different implementations of the same

Table 2 Comparison between main simulation results obtained by water transport models based on Richard’s equation and linked linear reservoirs, respectivelya Water balance in mm Potential evapotranspiration Inputs R.Eq.* Precipitation 763 Storage change 8 Mineral nitrogen balance in kg N/ha Inputs R.Eq. Deposition 15 Fertilization 180 Mineralization 73 Change in storage ⫺5 Dry Matter Yield in hkg DM/ha S. Barley R.Eq. Grain 48 Straw 52 Nitrogen Yield in kg N/ha S. Barley R.Eq. Grain 77 Straw 34 a

Lin. Res.† 763 2

Outputs Evapotranspiration Percolation

R.Eq. 448 306

499 Lin. Res. 440 321

Lin. Res. 15 180 72 ⫺5

Outputs Denitrification Plant uptake Leaching

R.Eq. 0 268 5

Lin. Res. 0 263 9

Lin. Res. 47 53

Grass Stem and leaf

R.Eq. 31

Lin. Res. 29

Lin. Res. 74 34

Grass Stem and leaf

R.Eq. 75

Lin. Res. 72

*Richard’s equation. †Linked Linear Reservoirs.

328

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

models. The main difference is that where APSIM has a flat structure and the modules are peers, Daisy is strictly hierarchical, allowing the component design to be reused on many different levels.

Our experience with the component design has been mostly positive. 앫 The component structure forces the programmer to concentrate on the interfaces, and to maintain them.

This is basically just good software engineering practice, but deadlines and work pressure often makes you derive from it, with well known bad effects on maintainability and stability. The component structure makes it harder to cheat than to do it right. 앫 Writing good interfaces is hard! Not a surprising discovery, but a task where the skills of computer scientists nicely supplement the skills of application scientists. 앫 It is often, but not always, necessary to change the interfaces. Usually, adding new processes requires changes to the interfaces of the existing components, while in many cases new models of existing processes can be implemented without any interface changes. 앫 The component structure has been an invaluable help in dealing with concurrent development for multiple projects. Daisy is constantly part of several different development projects, with widely different goals. In some projects Daisy helps to model large areas, and other projects focus on detailed modelling of specific processes. Having different stable and development models for different projects available and selectable from the setup files simplifies the modelling work. 앫 The component structure often ends up being useful in unexpected places. For example the component used for writing log files and checkpoints proved flexible enough to allow us to write a model for transferring arbitrary state information to another system, that used Daisy as a component. 앫 The design takes some time getting used to, and together with the lack of C++ experience in the community, it means that attempts to extend Daisy in practice require cooperation from experienced developers.

6.2. Tools 6.2.1. Language The APSIM simulation engine is coded in FORTRAN77, while Daisy is coded in C++. FORTRAN77 was chosen for APSIM because it is well known in the scientific community, whereas C++ was chosen for Daisy because it has the language features required for the rather ambitious design, whithout sacrificing speed.

Daisy has been coded to use only ISO C++ features and no libraries apart from those described by the ISO stan-

dard, and is thus portable to all platforms where a standard conforming C++ compiler exists. APSIM has been ported to many platforms.

Experience has shown us that the decision to choose FORTRAN77 for APSIM was well justified. Few scientists are fluent in C++. However, the language has proved very powerful, and a great help in the development of Daisy. Furthermore, we have found that most of our collaborators are able to program in C, which essentially is a subset of C++. This means it is reasonably easy to wrap a C++ interface over a model implemented in C, making it directly usable in Daisy.

We have also provided a C interface to Daisy for projects that want to use Daisy as a component.

New users facing a similar choice as APSIM and Daisy may want to consider using FORTRAN90, which provides more powerful language features than FORTRAN77, but in a form hopefully more familiar to the scientific community.

6.3. User interface

APSIM comes with a graphical user interface GUI that allows the user to select modules, set up crop rotations, and view output. The GUI is written in Microsoft Visual C++ and Visual Basic, and is thus not as portable as the simulation engine. Daisy has no standard graphical interface. Instead, text files are used for setting up the simulation, and produce output in tab separated columns suitable for viewing by spreadsheets and other standard data presentation programs.

Another characteristic of the user interface is that the Daisy executable contains all implementations of all models, while the APSIM executable only contains the implementations actually used. This means that with Daisy, the user can select models by editing the input files and run the executable, while the APSIM user will have to wait for the GUI to relink the executable. It also means that the Daisy executable will be larger, but that is not really significant on modern operating systems, because only the part of the executable being used is loaded to memory.

Our experience with the text based interfaces is positive, but many users want to supplement them with GUI tools to allow Daisy to be used by less experienced people. Three different GUI’s have been prototyped, one for setting up a crop rotation, one for interfacing with GIS systems, and one for browsing the various models and parameters. They are developed by three different organizations. We believe that this reflects the diverse needs of the Daisy user community, and complements our decision to focus on functionality, rather than graphical user interfaces.

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

6.4. Developer interface The characteristics of the developer interface are similar in the way of thinking to the characteristics in the user interface. APSIM comes with a specialized developing environment including editors and testing utilities, and even standard procedures for developing new code. In contrast, people who download Daisy will get a GNU Makefile and a Borland project file, and that is it. Of course, during development of Daisy we use a number of tools and techniques internally, but we do not consider them part of the Daisy project, or relevant to it.

We have experienced two benefits from this. The first is that Daisy is easy to incorporate in other projects, as it doesn’t come with its own set of support tools or procedures. The second is simply that it is easy to distribute the Daisy sources, there is little to set up for the receiver.

However, we cannot be certain that the informal nature of the project development will continue to serve well as the project grows, or if we will come to rely on standard tools and practices.

6.5. Future Basically, we believe that the design and implementation by now has proven itself, so focus has changed back to improving the models and adding support for new processes, as well as continued integration in other systems. Long term changes include improved description of the agroecosystem and better support for distributed modelling. Improved description of the agroecosystem includes adding process descriptions for phenomena, which are not yet included in the model, e.g., the effect of soil tillage on the transport processes in the soil, and utilizing the new functionality included in the model during the rewrite, e.g., simulation of clover/grass mixtures and rhizodeposition.

7. Concluding remarks As described in the introduction, Daisy is a well tested model. With the rewrite, a number of new models have been implemented, allowing for the simulation of intercropping systems and multiple soil columns. However, thanks to the component interface, the old well tested models are still available.

Since the rewrite, Daisy has been used in a number of on-going projects, and experience supports our claim that Daisy is an open model. 앫 Daisy has been linked to the distributed hydrological catchment model MIKE/SHE at code level. This illustrates the use of Daisy as a component of a larger system, using the C API described in Section 4.4. 앫 A new bioclimate module based on resistance theory

329

for the exchange of water vapour and heat in a canopy is being developed. This illustrates how to implement alternative models, using the C++ API described in Section 4.3. 앫 A number of crops have been parameterized since the implementation of the general crop model, and is now included in the standard library, illustrating the parameterization facility described in Section 4.2. 앫 Support for pesticides has been designed, and it appears that the implementation will be able to reuse the existing solute transport and adsorption components mentioned in Section 3.2.2, indicating that the new software design is sufficiently robust to allow new processes to be added.

Acknowledgements We would like to thank DINA for financing the Daisy rewrite, Lars P. Fischer for providing lots of input during the initial design, Peter Sestoft for supervising the project and making it happen, Jens Jeppesen and Rino Ranheim who implemented the GUI front-end, and Department of Agricultural Systems, The Danish Institute of Agricultural Sciences for co-financing the GUI together 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 — Syste´me Hydrologique Europe´en “SHE” 2: Structure of a physically 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 — Syste´me Hydrologique Europe´en “SHE”, 1: History and philosophy of a physically based distributed modelling system. Journal of Hydrology 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. Landoverva˚gningsoplande. Faglig rapport fra DMU, nr. 6.

Blicher-Mathiesen, G., Nielsen, H., Erlandsen, M., Berg, P., 1991.

Kvælstofudvaskning og udbytte ved ændret landbrugspraksis, Modelberegninger med rodzonemodellen DAISY. Faglig rapport fra DMU, nr. 27.

Diekkru¨ger, B., So¨ndgerath, D., Kersebaum, K.C., McVoy, C.W., 1995. Validity of agroecosystem models. A comparison of results of different models applied to the same data set. Ecological Modelling 81, 3–29.

EEA (1995) Europe’s Environment. The Dobris Assessment. The European Agency, Copenhagen.

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

330

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

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. The National Agency for Environmental Protection, Copenhagen, 272 pp.

Hansen, S., Jensen, H.E., Nielsen, N.E., Svendsen, H., 1991a. Simulation of nitrogen dynamics and biomass production in winter wheat using the Danish simulation model Daisy. Fertilisation Research 27, 245–259.

Hansen, S., Jensen, H.E., Nielsen, N.E., Svendsen, H., 1991b. Simulation of nitrogen dynamics in the soil plant system using the Danish simulation model Daisy. In: Kienitz, G., Milly, P.C.D., van Genuchten, M.Th., Rosbjerg, D., Shuttleworth, W.J. (Eds), Hydrological Interactions Between Atmosphere, Soil and Vegetation. IAHS Publication No. 204, pp. 185–195 Hansen, S., Jensen, H.E., Nielsen, N.E., Svendsen, H., 1991c. Simulation of biomass production, nitrogen uptake and nitrogen leaching by using the Daisy model. In: Soil and Groundwater Research Report II: Nitrate in Soils, 1991: 300–309. Final Report on Contracts EV4V-0098-NL and EV4V-00107-C. DG XII. Commission of 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 af N-balancer i sædskifter for svinebrug pa˚ lerjord, vandet og uvandet sandjord. SP rapport Nr. 15, Statens Planteavlsforsøg.

Hansen, G.K., Svendsen, H., 1995a. Optimizing of nitrogen application on pig farms by simulation. In: Giupponi, C., Marani A., Morari, F. (Eds), Modelling the fate of agrochemicals and fertilizers in the environment, 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 by farm management, Soil types and climate. In: Olesen, S.E. (Ed.), Proceedings of the Seminar on Site Specific Farming, SP-Report No. 26, Danish Institute of Plant and Soil Science, pp. 181–185.

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

Jensen, C., Stougaard, B., Jensen, N.H., 1992. The integration of soil classification and modelling of N-balances with the DAISY model.

In: Eijsackers, H.J.P., Hamers, T. (Eds.), Integrated Soil and Sediment Research: A Basis for proper Protection. Kluwer Academic Publishers, The Netherlands, pp. 512–514.

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

Jensen, C., Stougaard, B., Olsen, P., 1994a. Simulation of nitrogen dynamics 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 the nitrogen dynamics in farm land areas in Denmark 1989–1993. Soil Use and Management 10, 111–118.

Jensen, C., Stougaard, B., Østergaard, H.S., 1996. The performance of the 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. Simulating trends in soil organic carbon in long-term experiments using the soil-plant-atmosphere model DAISY. Geoderma 81 (1/2), 5–28.

Johnsson, H., Bergstro¨m, L., Jansson, P.-E., Paustian, K., 1987. Simulated 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 ecological crop rotation — an explorative trial. Nitrogen Leaching in Ecological 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 for Model Development, Model Testing and Simulation in Agricultural System Research. Agricultural Systems 50, 255–271.

Mueller, T., Jensen, L.S., Magid, J., Nielsen, N.E., 1996. Temporal variation of C and N turnover in soil after oilseed rape incorporation in the incorporation in the field: simulation with the soilplant-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 of biomass production and nitrogen uptake in winter rape. European Journal 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., Jenkinson, 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 comparison of the performance of nine soil organic matter models using datasets from seven long-term experiments. Geoderma 81 (1/2), 153–222.

Smith, R.E., 1992. Opus: An Integreated Simulation Model for Nonpoint-Source Pollutants at the Field Scale. US Department of Agriculture. Agricultural Research Service. ARS-98, Fort Collins, Colorado. 120 pp.

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

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

Svendsen, H., Hansen, S., Jensen, H.E., 1995. Simulation of crop production, water and nitrogen balances in two German agro-ecosystems using the Daisy model. Ecological Modelling 81, 197–212. van Keulen, H., Penning de Vries, F.T.W., Drees, E.M., 1982. A summary model for crop growth. In: Penning de Vries, F.T.W., van Laar, H.H. (Eds.), Simulation of Plant Growth and Crop Production. 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 simulation 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 EV4V00107-C. DG XII. Commission of the European Communities.

Vanclooster, M., Viaene, P., Diels, J., Feyen, J., 1995. A deterministic validation procedure applied to the integrated soil crop model. Ecological Modelling 81, 183–195.

Wagenet, R.J., Hutson, J.L., 1989. LEACHM, A process-based model of water and solute movement, transformations, plant uptake and chemical reactions in the unsaturated zone. Version 2. Center For Environmental Research, Department of Agronomy, Cornell University, Ithaca, New York, pp. 148. de Willigen, P., 1991. Nitrogen turnover in the soil-crop system; comparison of fourteen simulation models. Fertilisation Research 27, 141–149.