The ooCAESAR Project
The ooCAESAR effort continues.. but we're not sure what to call it yet
What is ooCAESAR? |
|
| ooCAESAR (pronounced "double Õ Caesar") was
to be a scenario-driven landscape evolution model (LEM) software package.
The double o's referred to the object oriented framework within which
the model has been designed. Originally, ooCAESAR inherited its name
and many of the conceptual algorithms from Professor Tom Coulthard's
LEM - CAESAR (Cellular Automaton Evolutionary Slope and River) Model.
However, ooCAESAR differs from CAESAR and other LEMs in that id does
not represent a single model. Instead, ooCAESAR allows the user to
combine potentially infinite combinations of process representations
to design the model that is best suited to the user's needs. Moreover,
through the development of the model, we are relying less and less
on CAESAR's trademark routing algorithms. As such, the name is undecided
for now. If you are new to LEM modelling, two concise reviews by Coulthard (2001) and Wilgoose (2005) can help bring you up to speed. For further references, you can refer to the bibliography provided below. Briefly, LEMs simulate the geomorphic response (typically of a catchment or a channel reach) to certain drivers (minimally climate and topography). The landscape is represented with a topographic model (like the example at right), and at every time step a new topographic model is produced representing the products of erosion, deposition and storage. LEMs come in a variety of forms (see here for links to models), which are normally dictated by the model developer's research interests and coding experience. |
 |
History of CAESAR¹... (Not Julius) & Acknowledgements |
|
 Sorry, for history of Julius Caesar, try here instead.  Screen shot of recent version of CAESAR. |
CAESAR was originally developed by Tom Coulthard,
as part of his PhD at the University of Leeds, U.K., under the supervision
of Professors Mike Kirkby and Professor Mark Macklin. Since then CAESAR has
evolved significantly, in both complexity and application. The CAESAR
project team at Aberystwyth has grown and benefited from the contributions
of Gez Foster, Ian Dennis and Marco Van de-Weil as well Jeremy Walsh
from NIWA, Christchurch, New
Zealand. All models are developed for a specific purpose. Below, Tom Coulthard describes what CAESAR was originally developed for: "CAESAR was originally designed to investigate the relative roles of climate and land-cover on the Holocene evolution of river catchments in the UK. It is flexible, and relatively easy to apply to DEM's of any river catchment. As it was designed to operate over 10 to 10000 year time scales, CAESAR simulates every flood event - driven either by an input hydrograph or from a rainfall sequence - which drives an internal hydrological model. CAESAR was designed to pay close attention to fluvial processes - which it could be argued are most dominant at these time scales. Therefore, it operates with relatively small grid cells (they can range from 1-100m in size) and simulates the channel width with one or more cells. It allows divergent and convergent flow - so is ideal for simulating braided rivers and alluvial fans, and importantly carries out fluvial erosion and deposition over a range of grain sizes linked to a series of active layers. This can allow a stratigraphy to develop, as well as important fluvial effects such as bed armoring restricting sediment supply." For my own applications of CAESAR, I found myself needing to make modifications to the source code to get the model to meet my needs. It struck me that each of the hand full of Landscape Evolution Models that exist in the world (roughly 10, here are some of them) were developed to meet the specific needs and interests of the person developing them. This greatly limits the utility of each LEM to meet other individual user's needs. Given the history of CAESAR (the model, not Julius), it is likely that CAESAR will continue to morph and change to meet the varied research needs of those who are using it. The idea behind ooCAESAR is simply to expose those various changes, and improvements to the LEM as user options instead of a series of individually hard-coded realizations or releases of the model. It is hoped that this modular object oriented implementation of CAESAR will allow those investigators to share their contributions to the code with each other, without imposing their specific needs on all other or future users of the code. In other words, the user decides what features to include in their own specific studies to make CAESAR "fit for that purpose." |
| ¹The above history was ad-libbed and/or quoted from the CAESAR/TRACER web page. | |
What improvements should ooCAESAR offer to users? |
|
EASIER TO USE
MORE POWERFUL AND FLEXIBLEThe user will be able to choose what processes to turn on or off from a suite of optional process models and variants in the following categories:
CLOSER ALLIGNMENT TO THEORYThe user interface, input and output options have been modified to make more intuitive sense. If ooCAESAR is used as a teaching tool, users should find a closer alignment between the conceptual models and process segregation often used to teach geomorphology.DEEPER EXPLORATION OF UNCERTAINTYNormally, the user can only adjust how a model is parameterized (hence allowing exploration of unreliability or parametric uncertainty). With the reorganization of the code into an object oriented framework the user can actually choose which process models are used. This means different coding algorithms of the same conceptual models, or competing process models can be interchanged and compared side by side within the same framework. This extends the capability of exploration of structural uncertainty in a model from just code-developers to users. |
What about researchers and code-developers? |
|
| It is difficult to speculate whether
code-developers will find the ooCAESAR easier or more difficult to
work with. Like CAESAR, ooCAESAR is coded in Microsoft's C# language
within the Visual Studio.NET environment. Visual Studio.NET is an
expensive but powerful development environment. In principle, the
source code could be modified in one of several freely available development
environments (e.g. SharpEdit),
but this has not been tested. With the increased functionality and flexibility of ooCAESAR also comes increased complexity. I have tried to keep the layout and organization consistent and easy to follow with ample comments and documentation to explain what is going on. The original CAESAR was migrated from C code to C# and inherited much of the rigid structure and logic of that old C or FORTRAN style of coding. The advantages of this are that the entire source code is in one file and to someone used to this style of programming, you can find your way around relatively quickly. Unfortunately, this does not take advantage of the power and flexibility of object oriented programming. The ooCAESAR project was partially inspired by the reorganization of CAESAR undertaken by Jeremy Walsh at NIWA. However, ooCAESAR is more than a reorganization. The GUI and guts have been recoded from the ground up (but many of the process algorithms are conceptually identical). If you are familiar with object oriented programming, making your own additions/modifications should be a breeze. If not, there are lots of examples to work from and lots of resources on the web are available to help you limp along. Alternatively, you can always just tweak the original CAESAR to meet your needs. The code is organized into class libraries, which expose their properties and methods to the developer without requiring you to understand too much about how they are actually coded. There are roughly four categories of classes that the developer will most typically access in ooCAESAR:
|
What will I need to use it? |
|
SYSTEM REQUIREMENTS
|
MINIMUM DATA REQUIREMENTS
REQUIRMENTS OF YOU
|
What will it cost? |
|
| NOTHING! CAESAR is Copyrighted ©2005 T.J. Coulthard ooCAESAR is Copyrighted ©2005 J.M. Wheaton CAESAR and ooCAESAR are developed as research tools and made freely available to anyone who wishes to use them. To insure that this is always the case, both are licensed under a GNU General Public License. So sorry, you will never get rich trying to sell this thing. The details are included in the installation but are as follows: This program and the source code are free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You will have received a copy of the GNU General Public License along with this program when you install it; if not, write to the: Free Software Foundation, Inc. |
Sneak Preview of the GUI.. |
||
PROJECTS:With simulation modelling, it is quite common to produce many simulations of the same thing with slight variants between simulations. This leads to the duplication of data, which aside from being confusing, is a data management head-ache. In ooCAESAR, a hierarchal project structure has been introduced to eliminate the unnecessary duplication of data, and to allow easier interpretation and cross comparison of individual simulations. In the figure at right, a preview of the project manager is shown. Dialogs and wizards accessible from the menus guide you through the loading of individual data items into the project input data structure. Typically the project will be organized around a specific catchment. Within that project, the user may choose to run coarse-scale simulations of the entire catchment, and more detailed simulations of certain sub-catchments or reaches. Furthermore, the user may wish to use the outputs of the catchment simulations to drive reach-scale simulations. With the project organizational structure, this is now intuitive and simple to do. In summary, a project consists of an automatically created directory structure, associated meta-data files and configuration files. The project is populated with simulations that are driven by input data and scenarios as described below.SIMULATIONS:The simulation is the most basic product of a model. In ooCAESAR, every simulation consists of a configuration file, which is produced with the help of a setup dialog or set up wizard (advanced dialog shown at right). The configuration file tells the program where to find the appropriate input data and scenarios, how to run the simulation and where to store the output data and analyses. I have required that simulations are housed in a parent project. Doing so allows all the available and compatible input data files to be checked and made visible in the configuration set up dialogs. In total there are nine types of information required to define a simulation:
Once the simulation configuration is defined, it can be run. Simulations can run anything from a single-flood event to 10's of 1000's of years. Accordingly, run-time can last anything from minutes to months. Simulations can be easily started, paused, restarted or stopped and saved. You can not replay a simulation without re-running it, but you can choose to record an AVI file which allows you replay the simulation with your own selection of output data layers turned on. INPUT DATA:Input data consists both of both rasters and grain size distributions. The input rasters generally represent boundary conditions and/or initial conditions (e.g. topography, depth to bedrock, erodability, vegetation type). For analyses, input rasters include classification masks (e.g. land use, critical areas, morphometric) to allow the model results to be easily segregated by these categories. All the rasters are imported and exported as Arc-compatible Ascii files. Simple visualization can be done from within ooCAESAR, but the Ascii files can be imported and visualized in most GIS applications (e.g. ARC, AutoCAD Map, Landserf). A simple dialog is provided for entering in multiple grain size distributions, which can be thought of as the source sediment for the simulations. In the simulation, you can use a single grain size distribution for an entire catchment or multiple distributions in regions defined by the input raster masks (e.g. sub-catchments). SCENARIOS:Let us define a scenario as any unique chronological sequence of events. ooCAESAR simulations rely on scenarios to drive the model. The only required scenario is a climate scenario. For a catchment simulation this consists of a rainfall record (hyetograph), whereas for a reach simulation this consists of a hyetograph and sedigraph (the spatial distribution of these inputs are user controlled). The important features of a scenario are the:
|
Click on images for full-size preview. A screen shot of the project manager and project reminder dialog. The project manager provides a simple Windows Explorer style interface to view and query all the data loaded in the project. You can post project reminders in any of these data directories to help keep track of tasks or just to remind you what something was.  A screen shot of the simulation window. During a simulation the user can view the hydrograph and sedigraph at the outlet, be alerted of upcoming events (e.g. flood, fire, earthquake) or navigate along the simulation time-line. A pop-up dialog can also be viewed that shows a raster map of the current simulation state (similar to current CAESAR).  The ecohydraulics module (accessible from the advanced simulation dialog). This dialog allows the user to choose the options for how the Ecohydraulic model will run. Both traditional PHABSIM style simulations and expert-based Fuzzy Inference System type simulations are permitted. The input files are CASiMiR compatible and the conceptual algorithms are similar to CASiMiR (Jorde and Schneider ~ SJE). |
References and Downloads: |
|
Sear, D.A., Wheaton, J.M.
and Darby, S.E., 2008. Collaborators & Acknowledgements: |
|
The danger in making a list of people to thank
is always that you leave someone off (apologies in advance). Nonetheless,
I'd wish to thank the following individuals (in alphabetical order)
for their time and intellectual contributions to ooCAESAR:
|
|
Funding: |
|
The ooCAESAR project has grown out of my PhD research
on Uncertainties
in River Restoration. At the inception of the PhD and the grants
that funded it, there was no intention to pursue an ooCAESAR project.
It became apparent partway through the PhD that a purpose-built ooCAESAR
software package would be much better equipped to address the research
questions of interest than existing models (e.g. CAESAR). As such
the ooCAESAR project was born and I thank the organizations below
who by generously funding the PhD made ooCAESAR possible:
These are the organizations (not already mentioned) who have specifically provided financial support for ooCAESAR :
|
|