1. Christian Klar and Peter Neuhaus 19.9.2005 Working group ‚Agroecosystems‘ Designing an object-oriented architecture for process- based modelling of soil nitrogen fluxes in DANUBIA Christian Klar and Peter Neuhaus

2. Christian Klar and Peter Neuhaus 19.9.2005 Working group ‚Agroecosystems‘ Outline Introduction Model description Modelling tools OOP, Java & UML Process model Architecture Computation cycle Debugging and validation Easy expandability Summary Perspective

3. Christian Klar and Peter Neuhaus 19.9.2005 Working group ‚Agroecosystems‘ Introduction GLOWA-Danube and DANUBIA Integrative and interdisciplinary research program of the BMBF GLOWA – Global Change of the Water cycle Development of integrative strategies for the sustainable and anticipatory management of water at the regional scale (Upper Danube catchment) Development of the integrative, multi-disciplinary decision support system DANUBIA What is our function/role in GLOWA-Danube? Working group ‘Agroecosystems‘ is responsible for the development of the agricultural plant growth and the nitrogen transformation component within GLOWA-Danube Implementation of nitrogen transformation processes and plant uptake Why to develop a new model instead of using an existing one? Connection to the complex framework of DANUBIA demands technical adaptations/restrictions DANUBIA is implemented in JAVA JAVA as programming language still rarely used in ecological modelling

4. Christian Klar and Peter Neuhaus 19.9.2005 Working group ‚Agroecosystems‘ Model description General information: Process description based on CERES approach Spatially distributed Spatial resolution: 1 km² Temporal resolution: daily Why CERES? Suitable process description for the use in DANUBIA Established in the modelling society Well validated Freely available code Project status: Technical development and validation completed Validation of model results has just started

5. Christian Klar and Peter Neuhaus 19.9.2005 Working group ‚Agroecosystems‘ OOP, Java and UML Why to use these modelling tools? OOP (Object oriented programming) especially suited for ecological modelling by „breaking systems into intellectually manageable components and combining them and making explicit the interactions between them“ (Wainwright 2005, 9) JAVA is one of the most widespread OOP-languages, industry standard, independent of operating system and comparatively easy to learn UML (Unified modelling language) is a graphical meta-modelling language to describe the structure of models and  serves as common interdisciplinary language to describe models and interfaces  enables involved disciplines to jointly model complex processes and interactions in an integrated system (Ludwig et al. 2003) UML and JAVA are well suited for object-oriented ecological modelling!

6. Christian Klar and Peter Neuhaus 19.9.2005 Working group ‚Agroecosystems‘ OOP, Java and UML How can ecosystem modelling benefit from Object Oriented Programming?

7. Christian Klar and Peter Neuhaus 19.9.2005 Working group ‚Agroecosystems‘ Architecture Grid cell, Process pixel Delegates calculations per layer Common data object, preparation of data Interface for processes, defines states Container for processes Explicit and restricted data exchange Processes encapsulate their own state, process description, data Debugging tool

8. Christian Klar and Peter Neuhaus 19.9.2005 Working group ‚Agroecosystems‘ Computation cycle Datapool Data import & preparation Processes Data computation Datapool Data export

9. Christian Klar and Peter Neuhaus 19.9.2005 Working group ‚Agroecosystems‘ Debugging and validation Process debug proxy: facilitates technical debugging and validation of processes without manipulation of source code acts as an intermediary for any process object implements the same interface as the process object (Process) forwards method calls to process object and writes/logs information about the process state

10. Christian Klar and Peter Neuhaus 19.9.2005 Working group ‚Agroecosystems‘ Easy expandability Adding a new process: e.g. modelling of phosphorous conversion or N 2 O emission 1) Building an interface  only few lines of code  specifies which data can be exchanged with pool 2) Implementing the process logic  implementation of the process algorithms  no side effects with other processes or pool data (encapsulation) 3) Data pool extension  only if new input or output data are needed 4) Process registration  via config-file

11. Christian Klar and Peter Neuhaus 19.9.2005 Working group ‚Agroecosystems‘ Summary The Process framework serves multiple purposes: 1)Modular structure and encapsulation - clear organisation of code, separation of scientific content from technical framework - separation and encapsulation of individual processes - no uncontrollable side effects 2)Data integrity - explicit and restricted data exchange - controlled access to and manipulation of shared and global data 3)Debugging and validation - log and debug output is configurable at runtime - selection of processes is configurable at runtime 4)Applicability - easy for new/unexperienced-programmers - model calculations easily manageable and traceable

12. Christian Klar and Peter Neuhaus 19.9.2005 Working group ‚Agroecosystems‘ Perspective for DANUBIA Parametrisation, calibration and validation: On the microscale Comparison of modelling results with measurements and validated point models, statistical analysis Perspective: Modelling of nitrogen fluxes between soil-plant system Spatially distributed nitrogen fluxes modelling on the mesoscale Development of a subscale approach with landuse/soil texture classes to consider landscape heterogeneity Development of strategies to validate nitrogen fluxes on a regional scale Modelling of nitrogen fluxes under Global Change conditions (long term predictions)

13. Christian Klar and Peter Neuhaus 19.9.2005 Working group ‚Agroecosystems‘ Debugging and validation Sequence diagram: 1)fetch() and compute() are forwarded 2)whenever compute() is called the proxy‘s debug() method is triggered 3)debug() uses introspection to get actual data values from the respective process object at each timestep 4)data values are then logged by DataWriter object 1. 2. 3. 4.