Toulouse, France 28-31 May 2013
By Robin Wilson SSI Fellow and a PhD candidate at University of Southampton
DART is a state-of-the-art tool that is built using many software sustainability best practices.
It provides a unique ability to simulate satellite and airborne images.
The training workshop was designed very appropriately for a wide range of abilities and everyone found it very useful even at their different stages.
The use of text configuration files, and the useful documentation is great - a real example.
The DART workshop was held in Toulouse for users of the Discrete Anisotropic Radiative Transfer Model, a state-of-the-art simulation model in remote sensing. The 20 or so attendees were very international in flavour, with people from leading remote-sensing institutions including the Remote Sensing Laboratory at the University of Zurich, CSIRO in Australia, INPE in Brazil and CNES (the French National Space Agency). Indeed, CNES are one of the major users, and support the development of DART financially.
Some of the attendees of the workshop were experienced DART users who wanted to discuss advanced usage, and some were very early beginners, but the workshop was well-designed to cater to this variety of needs. We started with a morning of lectures on the physical basis of DART - which was very useful - and then continued with some of the standard tutorials (with help from the original authors when things went wrong), followed by work on specific areas of interest to use. The programmers and the leader of the project were always available for help, and were very responsive to comments (see below).
The software is not open-source, and is released for free to scientists after they have signed a license. Unfortunately the license agreement has to be signed on behalf of their institution, and references the French patent that Paul Sabatier University have on the software. This has caused significant problems for some users, with universities insisting that the contract is examined by their lawyers and the patent is translated, and it taking over a year to get the license agreed by the university. The license also requires you to list exactly who will be using the software and what computers it will be installed on, significantly limiting the possibility of using it for teaching, even though this is one of its stated aims.
The stated aim of DART is to simulate satellite and airborne images in the reflective and thermal infra-red domains, and its unique selling point is that it combines many domains of simulation into one piece of software - something that no other tool does. For example, DART can simulate vegetation, Lambertian and anisotropic surfaces, topography, all angular effects, 3D urban objects, a variety of land-covers, and even LiDAR images. DART was developed to support research projects examining the sensitivity of satellites to biophysical parameters (eg. how easily can satellites retrieve
Leaf Area Index or Chlorophyll Context from an image of a forest), to allow the inversion of an image to obtain these parameters, to assess the potential of satellite sensors for specific applications, and to help design new satellite sensors. DART simulations have been used in the development of the SPOT and Pleadies series of sensors which have recently been launched.
DART is also designed to be used as part of the teaching of the physics of remote sensing, radiative transfer modelling and the radiation budget - although it is too complex to be used below MSc level, and would be quite complicated for MSc students to use. There are also licensing issues with using it for teaching, as mentioned above.
In many ways DART is an example of software sustainability best practice. The software is available for Windows and Linux in 32 and 64 bit versions. It is not fully parallelised, but does use multi-thread computation for certain operations. It is implemented as a number of separate executables, written in C++, each of which implement a certain module of the simulation, and which are combined in the correct order to run the entire simulation process. The model configuration can be set using a Java GUI, in which results can also be visualised, but the configuration is stored as XML files in a standard folder structure (NAME_OF_SIMULATION/input/*.xml, with results in NAME_OF_SIMULATION/output/BAND_X/...). These configuration files are perfect for storing in a version control function, and I would be tempted to suggest an integration with git (whenever you run the simulation DART would prompt for a commit message, commit and then run the simulations). The simulation programs themselves can be run through the GUI or maually - or through shell scripts or Python (although the Python interface is poorly documented at the moment).
The input and output formats are well documented, and the output images are in a standard image format that can be imported and processed by standard remote sensing software tools, including the GDAL library. Each simulation is stored in a separate folder, although simulations can share standard data such as spectral reflectance definitions. During the workshop I requested a 'Save As' option for a simulation, which would copy the simulation folder with all of its input configuration (but not the outputs) and rename it,
before automatically switching to the new simulation - allowing alterations to a simulation to be easily saved under a new name. I requested this on the first day of the workshop, and it was implemented and released by the second day - an example of their quick release cycle. Similarly, a very large extra feature (the ability to simulate a spatially-variable atmosphere) that I requested two months before the workshop was implemented by the time I arrived, and a tutorial had been written to show me how to use it.
DART has been under continuous development since 1992, and its functionality has significantly expanded during that time. A wide range of people have contributed to the code including PhD students, professors, summer interns, and permanent employees. The entire modelling code was re-written around three years ago, as they decided that the original C code had become an unmaintainable mess. They spent a long time developing detailed automatic regression tests, before rewriting everything in C++, and doing a full model validation. These regression tests are run before every release - although as many changes increase the model accuracy, it is difficult to decide what
differences from previous results are acceptable. Another testing method they use (for examples, for the air cells feature they implemented for me) is to configure a simulation in such a way that the results can be verified analytical from physical principles.
Computational efficiency is a big part of DART, and many design decisions have been taken based upon testing of the computational complexity of different approaches. One example of this is that infinite multiple scattering effects are taken into account through an innovative extrapolation algorithm, allowing accurate 'iteration infinity' results to be gained by simply running 4-5 iterations. Furthermore, there are a number of ways of running simulations for multiple wavelengths (either through defining multiple bands, or by using the powerful sequencer function - which allows modification of almost any configuration parameter through a sequence of simulations) depending whether the user wishes to optimise the memory usage (important for simulations of large images) or the CPU time (better for small images).
The maintainers of DART are very responsive to user requests, and try to implement features if a) they are possible and b) more than one person will find it useful. For example, my 'air cells' feature was implemented within two months, and they are currently working on a full energy balance system. LiDAR simulation was implemented at the request of CNES, and the basic model has been adapted for various 'unusual' uses including street-light design for EDF and monitoring of fires using ground-based thermal infra-red cameras.
In summary, DART is a very good example of software sustainability best practice, in a state-of-the-art and continuously developing software system. Unfortunately the model is not open source, but that is the only real sustainability problem - and even without open-sourcing, they seem to be able to sustain development over multiple decades, thanks mainly to the support from CNES.