MesoRD has been designed to have a number of features. Whether we have succeeded or not in our mission is not entirely clear.
MesoRD should be useful for scientist who wants to simulate reaction diffusion kinetics. It should be more convenient, but equally reliable, to use MesoRD as compared to writing your own code. To reach this goal the source code is freely exchanged so that is can be independently validated.
MesoRD should be well-defined in terms of the physical constraints that are imposed on the simulated systems.
User-friendliness was interpreted to mean that one should not have to recompile the code in order to run a simulation with different parameters or different reactions. (This goal was met already in version 0.1)
The code should be readable and understandable by people who were not involved in the early stages of development. This is one of the reason for choosing C++ as the implementation language, because it is a common denominator of everybody currently involved in development. We try to follow good coding practise as advertised in [GNU Coding Standards] and [Stroustrup 1997]. We use source-level documentation which can be transformed to a number of useful formats using doxygen.
The implementation should run on as many different platforms
as possible. Where possible, we want to be able to use
compilers optimised for the platform in question. In
particular, this means we want to follow standards and we do
not want to critically rely on platform specific features
such as DirectX™ on
Windows™, or the
fork()
call on Unices.
The implementation should make the best use of whatever resources available. This may actually clash with the previous design goals. This is also really difficult.