1 / 13

Outline

Designing an object-oriented architecture for process- based modelling of soil nitrogen fluxes in DANUBIA Christian Klar and Peter Neuhaus. Outline. Introduction Model description Modelling tools OOP, Java & UML Process model Architecture Computation cycle

aysel
Download Presentation

Outline

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Designing an object-oriented architecture for process-based modelling of soil nitrogen fluxes in DANUBIA Christian Klar and Peter Neuhaus

  2. Outline Introduction Model description Modelling tools OOP, Java & UML Process model Architecture Computation cycle Debugging and validation Easy expandability Summary Perspective

  3. 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. 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. 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. OOP, Java and UML How can ecosystem modelling benefit from Object Oriented Programming?

  7. Architecture Grid cell, Process pixel Container for processes Delegates calculations per layer Debugging tool Common data object, preparation of data Interface for processes, defines states Processes encapsulate their own state, process description, data Explicit and restricted data exchange

  8. Processes Data computation Datapool Data export Computation cycle Datapool Data import& preparation

  9. 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. Easy expandability • Adding a new process: • e.g. modelling of phosphorous conversion or N2O emission • Building an interface • only few lines of code • specifies which data can be exchanged with pool • Implementing the process logic • implementation of the process algorithms • no side effects with other processes or pool data (encapsulation) • Data pool extension • only if new input or output data are needed • Process registration • via config-file

  11. Summary • The Process framework serves multiple purposes: • 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 • Data integrity • explicit and restricted data exchange • controlled access to and manipulation of shared and global data • Debugging and validation • log and debug output is configurable at runtime • selection of processes is configurable at runtime • Applicability • easy for new/unexperienced-programmers • model calculations easily manageable and traceable

  12. 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. 1. 2. 3. Debugging and validation • Sequence diagram: • fetch() and compute()are forwarded • whenever compute() is called the proxy‘s debug() method is triggered • debug() uses introspection to get actual data values from the respective process object at each timestep • data values are then logged by DataWriter object 4.

More Related