pdf: 600KB - Potsdam Institute for Climate Impact Research

65
Restriction to scientific freedom
It may be considered that the development of a standard modelling language restricts scientific
freedom: researchers should be free to adopt whatever method they choose for implementing their
models.
There are several issues here. First, as presented in Section 3, numerous groups are now
developing integrating modelling frameworks. By their very nature, these require standards on
how modules (components) are interfaced, and thus also serve to constrain the methods that
modellers can adopt.
Second, there are already several examples of standards-development within ecosystem research,
and many examples in other disciplines. For example, there are many initiatives to develop
metadata standards (such as the LTER metadata initiative [see URLs]), and these are seen as
fundamental to the progress of ecosystem research in the internet age. It certainly restricts the
types of data and metadata that can be captured, but is being adopted because of the huge benefits
in shareability that it brings about.
Third, there will always be some models that cannot be implemented in a declarative language,
regardless of how expressive it is. No-one, I think, would argue that the conceptual design of a
model - a genuine scientific issue - should forcibly be changed to fit into some standard
framework. However, the situation is rather different if the model could been expressed within a
standard declarative language. In this case, it is much harder to argue that scientific freedom is
being compromised.
Fourth, the existence of a standard does not mean that everyone is obliged to use it. It could still
be up to each group to decide to implement a model through programming, even if the model was
capable of being represented in a standard language, and even if this took much longer and meant
that they couldn't use widely-available submodels and tools. People should want to use a
standard because of the benefits it brings.
Fifth, there is an issue of value-for-money for the taxpayer. Certainly, one would hope that
researchers would want to use a standard, rather than be forced to. But funding bodies have a
legitimate concern with 'bang-for-buck': the return they get in return for the funding they put in.
If a group insists on using time-consuming methods, which fail to make use of existing resources
(models and tools), and which produce a product that is much less shareable with the rest of the
community, then they surely need to justify this to the funding body. This justification should be
more than just a claim to scientific freedom, or the fact that the research assistant employed
happens to be familiar with a certain programming language.
The problem of legacy code
There are already many ecosystem or part-ecosystem models in use, for example, in forest
science, agronomy, or hydrology. Researchers are familiar with their code, and unwilling to
contemplate re-casting the models in some other notation. This is one of the main drivers behind
the current development of a component-based modelling framework by several groups: such
frameworks enable (in principle) existing legacy code to be wrapped up as a component and
integrated with other components, perhaps even implemented in other programming languages.
This is a valid concern. However, it is worth making two points. First, I believe (having
investigated the conversion of several programmed models into Simile) that the effort required to
convert a programmed model into a declarative format is less than supposed. This is especially the
case if the model was well programmed in the first place, particularly with clear separation of rate
and state calculations, and sound implementation of numerical integration procedures. Second,
legacy models can be wrapped up as a DLL, and embedded within a declaratively-represented
model, as discussed below.