iLand 1.0 Release (in numbers)

When we began working on iLand - around 2009 - we knew we that we set out for a longer journey. Today, more than 7 years after those first steps, we are proud to release version 1.0 - which is an excellent opportunity to look at the history and the current state of the project.

iLand website

Scientific publications are a key factor of a usable model documentation, but alone insufficient. A complex ecosystem model includes much more process and implementation details which cannot be stuffed into research articles. But those details need to be somewhere, and hey - full text search would be awsome, too! So, quite naturally, we designed the iLand documentation to be online (this site).
The internet develops really at a fast pace, both technically and visually. We went online with our wiki site using the TikiWiki version 3 in 2009. While the content of the site grew steadily, the site saw only smaller adjustments and additions (e.g., iLand downloads). Again, version 1.0 is a big milestone as we took the opportunity for a larger (and well due) overhaul of the whole infrastructure (this starts with upgrading outdated Ubuntu server versions ;) ). Some key features of the updated site (which you are likely visiting right now) are:

• mobile friendly: reading iLand blogs or docs on your mobile device is now a breeze
• switching to MathJax for rendering equations (we used a free online service to render equations to images before - thanks to John Forkosh for providing this free service for years!!)
• visual upgrade: the updated site design improves readability by larger fonts and more white space; by the way: the picture of the "forest" that we used for the banner on the top of the page was shot in the Rhodope mountains in southern Bulgaria (which is a great place for a hike!)

Below (for future reference) are screenshots from the former and the current iLand web site:

Publications

iLand is primarily a research tool, therefore publications in scientific journals are a key part of the project. So far, 10 iLand related papers have been published (4 focusing on modeling, 6 more on applications, though distinction is somewhat blurry) that have been cited >150 times. Things seem to accelerate: the first paper came out three years after the start of the project (Seidl et al. 2012), but we managed to put out 4 papers alone in 2016 . And more papers are in the pipeline... so stay tuned!

Downloads

Since the very beginning we believed that open access to scientific tools and the reproducibility of scientific results are cornerstones of the scientific project. Consequently, iLand has always been (and will be) released under an open source library (GPL) and can be freely downloaded and shared. Since the first public release in March 2012, around 200 people around the globe did exactly this:

Most downloads originated in Europe, followed by Asia and North America (see Table).
We found the highest downloads per capita-ratio for Austria (0.0002%, a total of 10% of the downloads), most likely because iLand "headquarters" are located in Austria.

Releases

The current release 1.0 is the 5th official iLand release. The following table provides an overview over those releases (see this page for details about previous releases).

Counting lines of code

We used the CLOC tool to count the lines of code that are in the iLand code base. The tool can strip away all empty and comment lines, counting only lines that "do something". As of now, iLand contains 29,875 lines of C++ code (LOC). This is a marked increase compared to earlier versions (release 0.3: 12,723 LOC, 0.69: 16, 841 LOC): iLand is still growing. And since we are at it: the new forest management module (ABE) is quite heavy (5,942 LOC), compared to the all disturbance modules combined (3,142 LOC). Interestingly, each disturbance module has a similar line count: wildfire: 932, LOC, wind: 1,027 LOC, bark beetle: 1,177 LOC.

We are currently working on a bark beetle disturbance module for iLand (see disturbance+modules for a list of already existing modules). One important aspect here is the spread of bark beetle infestations – and here many possible approaches exist. While scribbling at the whiteboard, we realized, however, that we are not able to fully understand the dynamic behavior of those approaches. Therefore, we started by creating a very general “playing field” based on a “grid” of pixels that allows playing around with different algorithms.

Luckily, we could re-use components that we developed earlier (such as the module-structure of iLand, or the visualization capabilities of the GUI), or facilitate already familiar techniques such as using Javascript. The result is a yet simple but quite powerful “general cellular automaton engine”. The algorithm and rules are written in Javascript using a very simple interface to query values of pixels and to change the state of pixels. In fact, this engine can be used for much more than toying around with bark beetle spread. Theoretically, the things that run in that engine may even be totally unrelated to forests (almost unthinkable!). Actually, it appeared to me that it would be perfectly suited for the famous “Conways game of life”. This simple cellular automaton inspired and fascinated many, many people (including a younger me): how can such a simple set of rules lead to an immense variety of life-like patterns? And – looking for example at http://www.conwaylife.com/, the appeal has not ceased.

I – obviously – could not resist and hacked together a version of the “game of life”. The combination of iLand and Javascript showed again its strength –the iLand GUI is neat for visualizing the game, and using Javascript the development (or rather prototyping) cycles are very short. As the iLand GUI contains also a basic Javascript-shell (at least a command history), the whole process is quite interactive and fun. I am really wondering if such a setup could make sense in teaching…
Anyway, here is a quick example of a running a „game of life“ – it is a 100x100 pixels grid; starting conditions are random and simulation time is 100 iterations. You can see a bunch of oscillators, gliders, and more (the Game of life wiki contains a collection of >750 named patterns).

And, just in case you are interested, here is also the source code....

// Conways GAME OF LIFE
// Werner Rammer, 2014
var engine = BarkBeetle; // just to have a nicer named link to iLand

var offset_x = [-1, 1, 0, 0, -1, 1, -1, 1];
var offset_y = [0, 0, -1, 1, -1, -1, 1, 1];
function count_neighbors(x,y) 
{
		var found = 0;
		for (var nb=0;nb<8;nb++) {
			if (engine.pixelValue(x + offset_x[nb], y + offset_y[nb]) % 2 ==1) {
				found++;
			}
		}
		return found;
}


function step(x,y) 
{
	var state = engine.pixelValue(x,y) % 2;
	var n = count_neighbors(x,y);
	// birth
	if (state==0 && n==3) 
		engine.setPixelValue(x,y, 10); // live in next round
	// death
	if (state==1 && (n<2 || n>3))
		engine.setPixelValue(x,y, 11); // die in next round
	
}

function finalize(x,y) {
	var state = engine.pixelValue(x,y);
	if (state==10) 
		engine.setPixelValue(x,y, 1);
	if (state==11) 
		engine.setPixelValue(x,y, 0);
	
}

var n_iter = 0;
function start() {
    // initialize with a random population
	engine.init( function(x,y) { if (Math.random()<0.1) return 1; return 0;} );
	Globals.repaint();
	n_iter = 0;
}
function iteration() {

    engine.run( step );
	
	engine.run( finalize );
	
	Globals.repaint();
	Globals.screenshot(Globals.defaultDirectory("home")+"image/img"+n_iter+".png"); n_iter++;
}

function run(n) {
	for (var i=0;i < n;++i) {
		iteration();
		//if you want to slow down: Globals.wait(50);
	}
}

We are happy to announce the release of a new iLand version (0.8). Its main feature is the inclusion of a dynamic fire disturbance module. The model software (including a ready-to-run example and the full source code) are available at the download page.

The release follows our recent publication in Ecological Applications on the role of disturbance legacies. The paper presents an application of iLand at the HJ Andrews experimental forest in Orgeon, US. In the study we ran long-term simulations (with the new fire module engaged) starting from different legacy levels after a landscape level disturbance, and analyzed the simulated successional patterns over 500 years. We found that life tree legacies have not only an effect on the long-term trajectories of ecosystem carbon storage, but also on species composition and structure. More details can be found in this and this blog post. The development and testing of the iLand wildfire module - which was a prerequisite for conducting this study - is described in detail in two Appendices of the paper (and of course in the iLand wiki).

In fact the development of the iLand fire module actually started already 2011 (see, for example, this blog post), illustrating nicely that the cycle of model development, model application, paper writing, and paper publication can take quite a long time.

But there is more than the new fire module in this release. Most notably, iLand now also includes a command-line version (without a graphical user interface), making it a perfect tool for High-Performance-Computing environments (note that the download package contains only windows binaries though). In addition, many small fixes and additions made it into this release (e.g., more detailed database outputs, extended Javascript bindings for forest management, improved stability due to bugfixes, ...).

With this release the number of available disturbance modules effectively doubled (now being two). Since we, of course, are aware that three shall be the number, we are currently working on also bringing bark beetles into iLand. So stay tuned!

Background

When we started thinking about simulating forest landscapes with a crazy high (i.e. single tree) resolution and were bouncing ideas how to accomplish this back and forth, we always tried to gauge whether we’d end up with useful tool for all practical purposes; practical here means to have a tool that can be used with standard PCs (no extra expensive hardware required) and in a time frame of minutes to hours (so you don’t have to wait weeks until a simulation is finished). Quite frequently, when we liked an idea but were not so sure about the “practical” impacts, we’d resort to the Moore’s law argument which goes like: “it might not be practical today, but in a couple of years computers will be much faster and will have much more memory…”. Actually, we *did* see some progress in the field of office computer hardware over the last years (and, by using multithreading and 64 bit architecture, we also try to facilitate these trends as far as possible). However, the big computer-power revolution happened in the supercomputer-area. The Top-500 list of supercomputers lists (surprise) the 500 fastest computer clusters in the world since the early 1990s. And the computer power grew by amazing 5 to 6 orders of magnitude in these 20 years. Since the machinery used by those supercomputers is not radically different from the stuff that we were used to (i.e., Intel or AMD processors, Linux operating system), it has always been tempting to tap into that resource. Enter the VSC:

The Vienna Scientific Cluster

The VSC is a supercomputer situated at the technical university Vienna and jointly operated by a bunch of Austrian universities. The first cluster (VSC-1) was built in 2009 and featured about 4000 processor cores – in 2009 it reached the rank 156 in the top-500 list of supercomputers. In the meanwhile, the cluster was extended (VSC-2, completed 2011, 21000 cores, awesome #56 in the top-500 list 2011), and currently plans to build VSC-3 are under way. Fortunately, the University of Natural Resources and Life Sciences (BOKU) is part of the VSC-consortium, which allows us to apply for using the computer resources.

Currently we work on an EU-funded project (www.fundiveurope.eu) that tries to boost biodiversity research in Europe. Our task within the project is to estimate the effect of biodiversity on the provisioning of ecosystem services in disturbed forest landscapes. To do this, we simulate a large number of different artificial landscapes characterized by different species mixtures and disturbance regimes – all in all a large number of simulations (about 4500). When we realized that our office PCs would have to crunch numbers for month, we seriously started to explore the supercomputer option.

The iLand cluster version

To actually create a “cluster version” of iLand for the VSC-1 was extremely easy, because the required components were already more or less in place:

• iLand is using the Qt-toolkit, and “cross-platform” is at the very heart of Qt.
• iLand can be run either with a full-fledged GUI or as a console application.
• iLand has been ported recently to 64bit architecture and has been made ready for a wider set of compilers (gcc, msvc)

From a user’s perspective, the “cluster” is just like your typical Linux shell; you have a home directory and have access to all the available software (such as Matlab, R, Mathematica, …). Qt and subversion was already there, so compiling iLand for with the (recommended) Intel compiler (icpc) was not very complicated: you “checkout” the source from the SVN-repository and build with a command such as:

qmake iland.pro –spec linux-icc-64 CONFIG+=release
make

the “linux-icc-64” tells Qt to user the mkspecs of the icpc-compiler, and all the rest happens automagically behind the scenes – awesome! Some minor changes later (very convenient with SVN) we had a running iLand executable and were able to start What really helped a lot in the whole process was the IT staff of the VSC: very friendly and helpful, thank you very much, guys!
The cluster facilitates the “sun grid engine” (SGE) system for managing computer jobs. iLand does not use “MPI”-style parallelization (i.e. the execution of one program at the same on multiple nodes). Therefore, we use the cluster as if it was simply a collection of individual PCs (nodes): a single simulation consists of copying the input data to the target node, running the simulation on the node, and copying back the results to the home-directory. The whole process is managed by the SGE; what we had to specify is a “sge”-script:

#$ -V
#$ -cwd
#$ -N iLand
#$ -t 1-2864:1
#$ -pe smp 8
#$ -l h_rt=02:00:00
# N: name
# t: the number of tasks 1-x:stepsize
# pe: one node for each execution
# export OMP_NUM_THREADS: execute with 8 threads.
# start with qsub  run.missing.sge

#!/bin/sh
export OMP_NUM_THREADS=8
echo "copy data to the shared memory of the node /dev/shm"
mkdir /dev/shm/iland_project
mkdir /dev/shm/iland_project/log
mkdir /dev/shm/iland_project/output
cp -r $HOME/iland/projects/FUNDIV/* /dev/shm/iland_project

MISSID=${SGE_TASK_ID}
### the $ is the argument (i.e. the ID)
### get the 2nd and the 3rd value (comma separated)
VARSPECIES=`grep ^$MISSID, /dev/shm/iland_project/design/master_sim_table_miss.csv | cut -d "," -f 12`
VARDRI=`grep ^$MISSID, /dev/shm/iland_project/design/master_sim_table_miss.csv | cut -d "," -f 13`
VARTYPE=`grep ^$MISSID, /dev/shm/iland_project/design/master_sim_table_miss.csv | cut -d "," -f 14`
ID=`grep ^$MISSID, /dev/shm/iland_project/design/master_sim_table_miss.csv | cut -d "," -f 2`
echo "ID $ID species: $VARSPECIES and DRI: $VARDRI type: $VARTYPE missing#: $MISSID"

echo "now run the model, for 500 years"
$HOME/iland/build/ilandc/ilandc /dev/shm/iland_project/project_Hain_sim.xml 500 user.generic_disturbance.return_interval=$VARDRI user.generic_disturbance.type=$VARTYPE model.settings.seedDispersal.externalSeedBackgroundInput="$VARSPECIES"
echo "copy back the results to data${ID}"
mkdir $HOME/jobs/results/data${ID}
mv /dev/shm/iland_project/output/* $HOME/jobs/results/data${ID}
mv /dev/shm/iland_project/log/log.txt $HOME/jobs/results/data${ID}/
echo "done."

The script combines some Linux shell magic (“grep” et al) and command line options of ilandc to extract the parameters of each simulation from a “master”-table that contains the layout of the full exercise.

How does the cluster perform?

The scheduling of jobs on the cluster is a bit unpredictable: sometimes not a single job is executed for hours, then, as if in a hurry, fifty simulations are run in parallel. A simulation on one node takes about the same time as on an office PC (the VSC-1 uses Intel quadcore CPUs (X5550), but the trick is the number of nodes. The general workload of the cluster seemed to decline considerably around Christmas, providing a good slot for the iLand simulations: the full simulation set took about 2.5 days, peaking at 300 simulations per hour – I guess that at this point almost 50% of the cluster was simulating forest landscapes ;)

Conclusion

• The “cluster” vastly expands the possibilities for future model application; we have already a couple of ideas what we can do with it in the future.
• The VSC is an awesome service and we are extremely happy that we can use it. People there are very helpful and the administrative side of things is also very smooth. Thanks again!
• Personally, it is quite satisfying that the vague idea of using supercomputers that we had in 2008 (or so) has now finally come true in 2013!
• The Moore’s law is still our friend. What will be possible in 2023?

Qt 5

Qt 5 was released a couple of month ago (end of 2012) and now Qt 5.1 (beta) is here - which is exciting since 5.1 promises more stability and includes, most notably, Qt desktop components (besides the Android and iOS stuff). The desktop components allow creating QML based user interfaces using ready made standard, ahem, components like buttons, tool bars, and menus. The GUI of iLand is currently based on the "traditional" Qt widgets (which work well), and there are no plans to change this now. But in the long run, who knows...

Equally important: Qt comes now in more precompiled (binary) flavors taking away the need to compile Qt yourself (which is a pain and requires a lot of messing around with compilers, configurations, ... just google the topic). Interestingly, there is now a 64bit MSVC 2012 version available (MSVC is the microsoft visual c++ compiler which is free when you use just the compiler without visual studio itself). The Qt guys use MVSC as default compiler for windows, so I decided to give the setup a try. In order to use MSVC you have to install the compiler and the debugging tools for Windows (look for instance here). Having done that, the integration in Qt Creator works very well.

Porting from Qt 4 to Qt 5

Porting iLand from Qt 4 to Qt 5 was actually not a big deal. There are a lot of more or less helpful resources on the net (like this or that). One thing was hard to find, though. iLand uses statically linked plugins  for its disturbance modules. And the way plugins are handled changed slightly, but significantly - there are new macros (like Q_PLUGIN_METADATA) which you need to add to your code, and there is one nasty issue I'd like to share: Somewhere in the main application, you need to import the plugin, using the Q_IMPORT_PLUGIN macro:

Q_IMPORT_PLUGIN(PluginName)

As the documentation states (and as it was the case in Qt 4), PluginName was the name that was specified as the build target in the .pro file (in our case, e.g., iland_fire). This does not work and you get "unresolved externals" linker errors. Hours later, I found that you need to specify the class name of the plugin class instead: in our case e.g., FirePlugin. There seems to be some disucssion internally (https://bugreports.qt-project.org/browse/QTBUG-24496) and using the class name could be also only a workaround - we'll see.

Using MSVC on windows speeds up the compilation process enormously (compared to gcc) - what used to take minutes is now a matter of 30 seconds (like, rebuilding the whole iLand application).

going to 64 bits

When we did the simulations for the HJ Andrews landscape (e.g., for this paper), we ran into the memory limiations of 32bit software. With the help of some tricks (-Wl,--large-address-aware), we were barely able to run the HJA, and since then it was clear that at some point we need to switch to a 64 bit architecture. I had the expectation, that the process will be a bit bumpy and that some memory saving micro-optimizations will bite back. Interestingly, nothing like that happened. Compilation was smooth and iLand worked as expected.

And even better: iLand is now considerably faster. There were a couple of optimizations that went into Qt 5, and MVSC seems to outperform GCC (at least for the Qt libraries). And there is maybe also some gain in using 64 bit CPU as such (maybe an increased used of SSE instructions, more registers, ...). The table shows the increase for HJ Andrews simulation (6400ha, 500 simulated years, starting from bare ground, including fire disturbances, Core i5-2500, Windows 7, 64bit). 

  Thats awsome! 

Deploying applications based on Qt 5

The process of deploying Qt based applications (i.e., including all the necessary DLLs and other files) is always time consuming and a bit frustrating. This has not changed with Qt 5. And the documentation in this regard is far from perfect. What you need to have is the following:

• in the application directory you need to need the icudt51.dll, icuin51.dll and icuuc51.dll (which provide some unicode support and are required for webkit, but for some reason you need to include this for every qt application). They are alone about 25MB which really sucks. I hope this will be fixed in future versions.
• You need to have "platforms" subfolder with "qminimal.dll" and "qwindows.dll". You find the files in the plugins/platforms folder of Qt.

Conclusion

For iLand, going to 64bit and Qt 5 was not a big effort, but brought improved performance!

Background

The modeling of stochastic processes such as tree mortality or the ignition of wild fires heavily relies on "randomness": a tree may either die or not, or a fire may start at a specific position or not. The probability of such events differ widely, but ultimately a decision is made: a tree dies or a fire ignites (or not). The typical approach in modeling involves drawing a random number from a uniform distribution and comparing that random number to the probability of the event. As probabilites are given in the range zero to one, we use also the 0-1 range for the random-numbers:

In C-like pseudocode, this looks like:

if (random_number(0,1) < probability_of_the_event)
	event_happens();
else
	event_does_not_happen();

Of course, the non-trivial thing are the random numbers since computers are deterministic by design. Developing algorithms that provide random numbers is an art by itself and involves very clever maths. Luckily, some of those brilliant people are kind enough to provide either the code or papers such as "A 623-Dimensionally Equidistributed Uniform Pseudo-Random Number Generator". By the way, those folks are also gifted in finding names for their creations like "Mersenne Twister" or "XORShift96". All random generators (or at least those that I am aware of) provide random numbers as "unsigned integers", i.e. as 32 bit numbers (between 0 and 2^32-1, i.e., approx. 4.3 billions) that are then converted to the target range. This granularity is usually not a problem, but if you look at the pseudocode above and if you consider events with a very low probability (e.g., 0.000001%), it is evident, that there are two potential problems: First, you'll run into troubles for probabilities close to the smallest possible probability that can be resolved with a single 32 bit random number (2.32E-10). Second, the approach is very sensitive to the quality of the distribution of very small numbers that the random generator is able to provide.

Actually, I started the whole investigation when a strange pattern of ignitions in the iLands wildfire module was detected; usually, probabilities of a fire igniting a certain pixel in a year are around 10E-7 to 10E-8 (that is low, but still well above the probabilistic "planck-length" of 2E-10 - speaking in integers, if the random generator draws numbers below 100 or 1000, the event happens). The problem was, however, that the artificial test case that I set up used only a limited number of random numbers leading to a far too low a number of ignitions. So I decided to test the random generators more thoroughly.

The test

Within the iLand framework, the following random number generators are available (documenting that this is not the first encounter with the topic). See also http://www.lomont.org/Math/Papers/2008/Lomont_PRNG_2008.pdf for a nice introduction to the general topic.

Mersenne: Mersenne Twister, published 1998, very fast, very nice.
Mersenne 2: the same Mersenne Twister, but with a new random seed after every 4000000 numbers (effect of artificial additional seeding)
XOR96: The Marsaglia Xor-shift generator
Well-RNG: An partially improved version of the Mersenne Twister, published 2006
fastRandom: a very simple but yet powerful generator from Intel

Setup of the test

We were checking how good random number generators are able to produce very small numbers. We did this by drawing 4,000,000,000 random numbers from the range 0,1 for each algorithm, and by counting how many numbers were below 10e-8, 10e-7, 10e-6, 10e-5, 10e-4 and 10e-3, thus representing probabilities from 0.000001% to 0.1%. The resulting numbers were compared to the expected number from the Poisson distribution. For each random number generator, the test was repeated three times. For allowing comparisons of different scales, results were scaled to the expected mean value, i.e. by dividing the counted result with the expected number of values (e.g. 4,000,000 for p=0.1%).

Results

Distribution of small random numbers

Frequency of extremely small random numbers. The dashed line provides the 1st and 99th percentile according to the general Poisson-distribution. The numbers are scaled to 1. (E.g.: the expected value for p=10e-8 would be 40 for 4,000,000,000 repetitions).

The Mersenne 2 and the XOR96 performed poorly, while all other algorithms yielded good results. When averaging all the values (except for the lowest p=10e-8), the Mersenne Twister and the fast Random algorithm performed best. It is quite interesting that reseeding the Mersenne Twister worsens the results.

Runtime performance
In good tradition of this blog, the runtime performance was also measured.

Time for drawing 4,000,000,000 random numbers in milliseconds (2009 dual core laptop).

All assessed random number generators are reasonably fast (the measured time included also comparing and counting the results). The 2009-laptop crunched more than 60,000 numbers per millisecond.

Comparing to a random-number-caching approach
A test was also conducted with an approach that uses caching and re-using of random numbers: an internal buffer was filled (e.g. 500000 numbers) and then recycled for 20 times. This was originally designed to avoid problems with non-reentrant code and occasional crashes in multi threading mode.
As could be expected, the results were poorer, as only 5% of the random numbers were effectively drawn from the distribution. However, the average runtime was reduced by 15% to 20% (average of 52000ms).

performance of random number generators when applying a cache algorithm. The outer dashed line provides the 1st and 99th percentile, the inner the 5th and 95th percentile according to the Poisson-distribution.

Conclusion

The assessed random number generators Mersenne Twister, WellRNG and fastRandom are well suited to provide very small random numbers used for modeling rare stochastic events. Caching random numbers provides a small performance benefit, but at the cost of precision. As a result, the caching algorithm with a reduced number of 5 cache cylces and with the Mersenne Twister generator will be used in future. (Note: the original problem of implausible ignition patters was removed when the caching algorithm was adapted to be refilled also within a simulation year).

After the going online of the new iLand paper in Ecosystems, we proudly present a new release  of the iLand model that was described and used in the aforementioned study. The download package contains the iLand software (compiled for Windows) and an extensive, fully functional example (a part of the HJ Andrews forest, see the screenshot).

Although relatively few time has passed since the last release (version 0.3, March 2012), a relatively large amount of additions and modifications are included in the new version: the records show approximately 250 commits in the subversion repository from roughly April 2010 up to May 2011. The number of lines in the C++ source code (without comments and empty lines, counted by cloc)  increased from a not-too-shabby 12732 to an awsome 16841. If you want to check the numbers for yourself, have a look at our new public SVN repository, which contains the full source code of iLand (which, by the way, is released under the GPL open source licence).

In case you worry, that iLand development stopped a year ago, rest assured that development continues (see e.g. posts on ongoing activities for modeling  fire or wind), and that the software and code are released after the respective scientific publications.

Now lets turn to some of the new ingredients of the new release:

Seed Dispersal / Establishment / Regeneration

This is the first real landscape process covered by iLand: seed dispersal is modeled on a 20x20m grid (some early results were presented in the blog more than two years ago). Also included are an establishment module, sporting an phenology based mechanistic approach (TACA), and  the growth of sapling (trees below a height of 4m in iLand), both happening on a 2x2 m grid. 

Soil, Carbon and Nitrogen cylce

The second big topic was closing the carbon and nitrogen cycle and adding a soil module. The soil module applies the ICBM/2N approach which was selected due to its simplicity and parameter parsimony. We also added a module for handling  standing dead trees, and closed the links between soil and the living vegetation.

Landscape level simulation

Since 0.69, the "landscape" in the model acronym is well deserved: iLand is now able to initialize and simulate complex forest landscapes. To that end, we implemented features to set up the model from GIS based data and also to save some of the results as GIS readable grid files.

Management and Javascript Bindings

iLand 0.3 already contained a management module, but the module in 0.69 offers much more. You can now base management on spatial entities (read GIS polygons), or access regeneration, snags and soil pools from Javascript (in case you want to mimick disturbance events). Generally, the scripting capabilites increased in many ways: for instance APIs for controlling outputs or the "viewport" of the iLand viewer are available.

Memory and CPU Performance

The HJ Andrews simulations, with its more than 6000 ha and 500 years of simulated time, were challenging and required both fastening the debugging and performance thumbscrews. A current office PC  should suffice (but nice are 8GB RAM with a couple of cores and a 64 Bit Windows), and it is fun to see all CPU cores simmering at 100% CPU load. We were also able to reduce the run time of the HJ Andrews simulations from 5 hours to a little more than 1 hour by adding one tiny little ampersand that was initially forgotten, demonstrating the "small cause - large impact" principle (and of course it took ages to find that bottleneck).

Wiki Improvements

And, last but not least, a whole bunch of wiki pages are publicly avaiable now - happy reading!

We are happy to announce that now large portions of the iLand wiki are now online for public access!

During the last three and a half years, the iLand wiki continuously growed along the modelling concepts and the model software - but for registered users only. Now it is time to raise the curtain! The first official iLand publication is (finally) in press (see this blog post for some philosphical musings  over this process), and the Marie Curie Fellowship that provided the main funding for the development has almost ended.

We took this also as an opportunity to improve the wiki and the overal appearance of the iLand home on the web - we hope you like it. The iLand wiki is powered by the open-source wiki software TikiWiki which is developed by a very active community. One major task was to upgrade the wiki software from an ancient version, which was not always as easy we had hoped, but brought as a lot of new functionalities, improvements and bug fixes. 

We also re-designed the public start page trying to provide a visually pleasing and informative entry point for our site. Also new is the download page that allows free download of the iLand software and source code. Currently, we have a total number of 110 public wiki pages - something we are quite proud of.

Note, that a part of the wiki is still for registered users only. These pages cover unpublished parts of the model (e.g. regeneration) and you will encounter "not logged in" error messages when you try to view them. But rest assured that these pages will not remain in private darkness forever!

If you miss something important, find dead links or have any other feedback  we'd be happy to hear from you!

During the last couple of weeks our efforts are concentrated on the evaluation of the currently developed fire module (see also the last blog post). Besides, we - and especially Rupert - are working hard on getting manuscripts ready for publication.
But back to the fire module: a part of this exercise is to compare simulated with historic fire sizes. This requires, of course, simulated "historic" vegetation states, something we are working on anyways. However, the hard thing would be to run iLand for hours just to reach a point in time after, say, 400 years of simulation.
To make things more tractable, we invented the so-dubbed vegetation snapshots. Essentially, a snapshot is a SQLite database containing the full dynamic content of the vegetation, i.e. all non-dynamic variables of all trees, of all trees in the regeneration layer, of all standing dead trees, and of all soilpools.
Thanks to the very small list of such variables, this endeavor turned out to be pleasantly straightforward. The full C++ code to create the database, save and restore the data is not more than 350 lines of code.

The second ingredient to an efficient fire-evaluation environment, is making both fire events and the control of vegetation snapshots scriptable, and thus automatable. Not a big deal, thanks to Qt and Javascript. This allows the modeler to explicitly (and reproducible!) load a "historic" vegetation snapshot, then to ignite repeated wildfires with certain properties at a certain location, and last but not least, to save fire dispersal patterns as grids. A "fire simulation" mode was also introduced to allow fires spread without actually modifying the vegetation state.
Adding some automation magic on the R side allowed to set up and run a quite sophisticated simulation experiment almost in auto-pilot.

And what if one wants to reuse the analysis scripts when doing a fully dynamic simulation (including dynamic fire) - well, than adding a javascript "event handler" that executes user-defined javascript code after each fire is just a couple of lines away...
And just to show how such a javascript function could look like, a small example:

// event handler. Set the fire.onAfterFire to "afterFireProcessing()"
function afterFireProcessing() {
   var praefix = Fire.id;
   // save the form of the fire in ESRI raster format
   // save a file for each fire
   Fire.gridToFile('spread', 'output/fire/spread' + praefix + '.txt');
}

So what have we learned?

• if the simulated entities are simple with regard to state variables, manipulating them is also simple
• if (service-) functionality is exposed to be scriptable, somebody may some day starts to combine those pieces to create something new - well, that is exactly the point of scripting...
• the underlying technical components of the iLand project, i.e. Qt with Javascript bindings, and the SQLite database, are great tools, besides being real open source (yes, Qt also!)

Reflecting pretty well the weather conditions outside, we recently started to implement some "hot" stuff, i.e. fire disturbances. The fire disturbance module is the first of its kind in the iLand world, others (like wind or bark beetle) are expected to follow.
A question that we pondered regularly over the last years (note the plural!) is the degree of modularization we are aiming for. This is about how easy it would be to add or change such modules and also about how easy it should actually be to implement such a module.
With the advent of the fire module it was necessary to nail some things down; at least for the time being. The guiding principles are now:

• modules are implemented in C++.
• A module is a module also in a technical sense, i.e. it is implemented as a Qt-Plugin
• On the iLand-core side of things, a couple of C++ interfaces are defined. Such interfaces are rather specific and allow plugins to "hook" into some functionality. An example is the "WaterInterface" enabling a module to extract details of the soil water balance (e.g. used to calculate some fancy fire weather index)
• For the time being, modules are statically linked to the iland core executable, so there is no way to distribute modules by copying only some DLLs. However, modules can be simply switched on/off using the standard XML project file

With our design of the iLand structure we aim at some middle ground: on the one hand we'd like to have a modular concept allowing for some flexibility and different versions of modules, but on the other hand we keep the level of generalization low to avoid unnecessary complications and homegrown problems.

A future option is to implement a more general module including a javascript interface: this would allow the implementation of modules with the core logic written in javascript (easily editable, easily readable, ...). Such an approach would for sure lower the barrier for possible users to develop new or modify existing modules. However, complex modules with many interactions with the core model are likely to remain pure C++.
Having a module in C++, of course, does not rule out possible contribution by third parties, but we think if somebody is interested in playing around with iLand, it will probably not the first thing for him or her to do to fire up a C++ editor...

But let's get back to the fire module. One prerequisite for the module was the addition of a digital elevation model to iLand - an important step for the model to actually earn the 'landscape' in its name. Having that and a fire spread algorithm that is sensitive to the terrain provides an excellent pretext to post some screen shots of iLand in action:
<img src='tiki-view_blog_post_image.php?imgId=15' border='0' alt='fire spread 1' />
<img src='tiki-view_blog_post_image.php?imgId=16' border='0' alt='fire spread 2' />
The grey scale image is the visualization of the DEM (it is mountain slope somewhere in Austria - you see the road in the lower part?) assuming a fixed position of the sun. The overlain colored patches depict the extent of a individual fire event (a fire-pixel is 20x20m). The colors indicate the sequence of burning cells: starting from blue (ignition point) over green to yellow.
We really enjoy watching our iLand thingy grow along the lines laid out quite some time ago!