iLand Tech blog Blog Actions

some ideas and technical stuff....

iLand 1.0 release (in numbers)

Wednesday 16 of November, 2016

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!

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).

 Region % of Downloads Europe 58% Asia and Oceania 22% North America 16% South Ameria 3% Afrika 1 %

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).

 Release Release Month Downloads Description 0.3 2012/03 30 iLand core processes (paper) 0.69 2012/09 36 landscape processes (paper) 0.7 2013/10 27 wind module (paper) 0.8 2014/07 106 fire module (paper) 1.0 2016/11 tbc! bark beetle and management modules

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.

Game of life

Thursday 20 of November, 2014

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 &gt;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&lt;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 &amp;&amp; n==3)
engine.setPixelValue(x,y, 10); // live in next round
// death
if (state==1 &amp;&amp; (n&lt;2 || n&gt;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()&lt;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 &lt; n;++i) {
iteration();
//if you want to slow down: Globals.wait(50);
}
}

New iLand release 0.8!

Wednesday 30 of July, 2014

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!

a clusterful of secrets

Friday 10 of January, 2014

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

#!/bin/sh
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?

64 bits and Qt 5

Thursday 06 of June, 2013

Random number quality

Monday 08 of October, 2012

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) &lt; 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).

iLand 0.69 - the new kid on the block

Thursday 27 of September, 2012

iLand web - relaunch!!

Friday 09 of March, 2012

Vegetation snapshots and Javascript

Tuesday 29 of November, 2011

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
}

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!)

Summer time is fire time

Tuesday 28 of June, 2011

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!

• «
• 1 (current)
• 2