Release notes for JULES releases prior to v3.1
The major change in version 3.0 is the introduction of IMOGEN impacts tool. IMOGEN is a system where JULES is gridded on to surface land points, and is forced with an emulation of climate change using “pattern-scaling” calibrated against the Hadley Centre GCM. This climate change - impacts system has the advantage that:
- The pattern-scaling allows estimates of climate change for a broad range of emissions scenarios
- New process understanding can be tested for its global implications
- New process understanding can also be checked for stability before full inclusion in a GCM
- By adding climate change anomalies to datasets such as the CRU dataset, then GCM biases can be removed
It must be recognised that the system is “off-line”, and so if major changes to the land surface occur, there might be local and regional feedbacks that can only be predicted using a fully coupled GCM. Hence IMOGEN doesn’t replace GCMs, but it does give a very powerful first-look as to potential land surface changes in an anthropogenically forced varying climate. This was accomplished with help from Mark Lomas at the University of Sheffield and Chris Huntingford at CEH.
There are also several small bug fixes:
- A fix effecting fluxes in sf_stom from Lina Mercado at CEH. This bug fix was announced on the JULES mailing list
- Small fixes for potential evaporation and canopy snow depth from the UM
- A small issue with some memory not being deallocated at the end of a run
Along with fixes for known bugs, the changes made for version 2.2 mostly consist of several small additions to the science code. Changes to the control code have mostly been limited to bug-fixes.
- New options for treatment of urban tiles - inclusion of the Met Office Reading Urban Surface Exchange Scheme (MORUSES) and a simple two tile urban scheme
- Effects of ozone damage on stomata from Stephen Sitch at the University of Leeds
- New treatment of direct/diffuse radiation in the canopy from Lina Mercado at CEH
- A new switch allows the competing vegetation portion of TRIFFID to be switched on and off independently of the rest of TRIFFID (i.e. it is now possible to use the RothC soil carbon without having changing vegetation fractions)
There have also been changes made to the way JULES is compiled, due to the re-integration with the Met Office Unified Model. The Unified Model uses pre-processor directives to compile different versions of routines depending on the selected science options. For compatibility with this system, JULES now requires a compiler with a pre-processor. This should not be noticed by the majority of users – most modern compilers include a pre-processor and the Makefile deals with setting up the appropriate pre-compiler options.
Versions 2.1.1 and 2.1.2 were released to fix major bugs found in v2.1 - they contain no new features.
Version 2.1 of JULES includes extensive modifications to the descriptions of the processes and to the control-level code (such as input and output). These are covered briefly below. Several bug fixes and minor changes to make the code more robust have also been applied. All files are now technically FORTRAN90 (.f90) although many are simply reformatted FORTRAN77 files in which continuation lines are now indicated by the use of the ‘&’ character.
The main change is that a new multi-layer snow scheme is available. This scheme was developed by Richard Essery at the University of Edinburgh and co-workers. The older, simple scheme represents the snowpack as a single layer with prescribed properties such as density, whereas the new scheme has a variable number of layers according to the depth of snow present, and each layer has prognostic temperature, density, grain size, and solid and liquid water content. The new scheme reverts to the previous, simpler scheme when the snowpack becomes very thin.
A four-pool soil carbon model based on the RothC model now replaces the single pool model when dynamic vegetation (TRIFFID) is selected.
There have been several major changes that most users will not notice or need be concerned about. These include:
- A change in the linearization procedure that is used in the calculation of surface energy fluxes (described in the technical documentation)
- A standard interface is now used to calculate fluxes over land, sea and sea ice
- Each surface tile now has an elevation relative to the gridbox mean
These changes mean that, even with the new snow scheme switched off (nsmax=0), results from v2.1 will generally not be identical to those from v2.0.
The major change at v2.1 to the control-level code is that NetCDF output is now supported. Both diagnostic and restart files (dumps) can be in netCDF format. There have been several changes to the run control file, partly to reflect new science but also in an attempt to organise the file better. These changes mean that run control and restart files from JULES v2.0 are not compatible with v2.1 (although they could be reformatted without too much difficulty).
The physical processes and their representation in version 2.0 have not changed from version 1. However, version 2.0 is much more flexible in terms of input and output, and allows JULES to be run on a grid of points. New features include:
- Ability to run on a grid
- Choice of ASCII or binary formats for input and output files (also limited support of NetCDF input)
- More flexible surface types – number and types can vary
- Optional time-varying, prescribed vegetation properties
- More choice of meteorological input variables
- Optional automatic spin-up
- Enhanced diagnostics – large choice of variables, frequency of output, sampling frequency, etc.
Initial public release of the JULES code. JULES v1.0 will only run for a single point and only supports ASCII data.