LPJmL Documentation


CONTENTS

Installation
Input data
How to run it - first steps
Flags for running LPJ
Compiler flags
Running and compiling LPJ under Windows
Running it in parallel
Running it with land use
Running it in river-routing mode
Running it coupled to IMAGE
Malloc debugging
Removing list elements
What is the output?
How to handle output files?
Reading binary files
How to add new output
About byte ordering/endianess
Memory shortages (XLC compiler)
Structure of the Code

INSTALLATION

- see INSTALL file in the LPJ distribution
TOP

INPUT DATA

LPJ is driven by monthly fields of temperature, precipitation, cloudiness and number of days with rain. Additionally static information on soil properties, geographic coordinates of climate and soil data, and mean annual atmospheric CO2 concentration are required. Except for CO2 all files are binary data including a header (except for the soil data).

Overview of LPJ input data

file

exemplary name

file format

data type [size]

data unit [scaled]

header [size]

coordinates

grid.bin

binary

short [2 bytes]

degree [*100]

yes [35 byte]

soil

soil.bin

binary

char [1 byte]

0-9

no

temperature

tmp1901-2003.clm

binary

short [2 bytes]

deg celsius [*10]

yes [38 byte]

precipitation

pre1901-2003.clm

binary

short [2 bytes]

mm/month

yes [38 byte]

cloudiness

cld1901-2003.clm

binary

short [2 bytes]

percent

yes [38 byte]

wet days

wet1901-2003.clm

binary

short [2 bytes]

number of rain days

yes [38 byte]

CO2

co2_1901-2003.dat

ascii

char [1 byte]

ppmv

no

country code (new version) cow_mg_2006.bin binary short [2 bytes] yes [39 bytes]
landuse luc2003_gmia4.clm binary short [2bytes] fraction [*1000] yes [38 bytes]

Structure of the header

- header name (1 byte char array, LPJCLIMATE (10 bytes) for temp,precip,wet days and cloudiness, LPJGRID (7 bytes) for coordinate data, LPJLANDUSE (10 bytes) for landuse data, LPJ_COUNTRY (11 bytes) for country codes)
- header version (4 byte integer, currently set to 1, also used to determine if input data needs byte swapping)
- order (4 byte integer, values are either 1 (cellyear) or 2 (yearcell))
- firstyear (4 byte integer, first year of data record)
- nyear (4 byte integer, total number of years) 
- firstcell (4 byte integer)
- ncell (4 byte integer, number of grid cells represented)
- nbands (4 byte integer) 

Sorting of the climate data

The sorting of the monthly climate data and of the landuse data does not correspond to a standard file format but is a mixture of BSQ (band sequential) and BIP (band interleaved by pixel). You start with 12 monthly values (or with 24 landuse-fractions) of the first year and first grid cell. After that, the first twelve monthly values of the second cell follow and so on. Once you are done with all grid cells, you continue with the first grid cell's monthly data of the second year. This format is called „cellyear“ in the LPJ vocabulary and is the only format that is supported from LPJ-version 3.2 and above ("YEARCELL" = BIP has been used in previous LPJ-versions).
Once you have a data set that you want to apply, you use any programming language, to write the header to a file. In C, you can use the function "fwriteheader(..)" in  src/tools/header.c to write headers (or freadheader(...) to read it)
Datasets can be converted to LPJ-format (including headers) from plain binary input files (BIP) with the executable cru2clm that has been provided with the LPJ distribution.
Data needs to be stored in the same order as the input grid.

coordinate data (1 file)

-----------------------------------
gridfile [scaled: degree*100]
  in C data type short (2 bytes), lon lat for each pixel
  defines the extent of your input data
  size of header: 35 bytes
-----------------------------------

soil data (1 file)

-----------------------------------
soil input
  data type char (1 byte), the grid needs to be the same as your input
  grid / climate data
  values are currently ranging from 0 to 9
  corresponding soil parameters can be found in par/soil.par
  no header 
-----------------------------------

climate data (all monthly values, 4 files + 1 file with atmospheric CO2 concentrations)

-----------------------------------

- temperature [scaled: degree celsius*10]
  size of header: 38 bytes

- precipitation [mm/month]
  size of header: 38 bytes

- cloudiness [%]
  for internal computation of radiation
  size of header: 38 bytes

- wet days
  number of wet days per month (needed only, if your are using the
  "weather generator", that distributes rain within month randomly)
  size of header: 38 bytes

- atmospheric carbon dioxide [ppmv]
  global annual mean CO2 concentration as ASCII file
  format: year concentration
  Example
    1990 354.19
    1991 355.59
    1992 356.37
    1993 357.04
    1994 358.88
-----------------------------------

Land use data

- land use:
  in C data type short (2 bytes), grid needs to be the same as your input grid / climate data
  values range between 0 and 1000 (fraction *1000)
  each grid cell and year has 24 entries: 12 for rain-fed crops, 12 for irrigated crops
  crop oder is as follows:
  1: temperate cereals, 2: rice, 3: maize, 4: tropical cereals, 5: pulses,
  6: temperate roots, 7: tropical roots, 8: oil crops sunflower, 9: oil crops soybean,
  10: oil crops groundnut, 11: oil crops rapeseed, 12: pasture (C3/C4 mix left to LPJmL to determine)
- country codes:
  in C data type short (2 bytes)
  for each cell two values: countrycodes (n=197) and regioncodes (n=433)
- river routing:
  in C data type short (2 bytes), the grid needs to be the same as your input grid / climate data
  for each cell two values: one in which cell to rout the water  
                            one with the distance [km] between the midpoints of the two cells
  -9: inland sink or outflow to the ocean

Model parameters

- parameter files
  a) pft parameters
  b) soil parameters
  c) management parameters (countries)
  d) management parameters (regions)
  see sample files provided with LPJ source code
TOP

HOW TO RUN IT - FIRST STEPS

change lpj.conf to specify
change cru*.conf to specify the location of most of the input data (climate / grid / management / landuse/ routing)
ATTENTION: running LPJ without river routing also needs a name (only name, no data) for the input-file for routing
TOP

FLAGS FOR RUNNING LPJ

switch flags by calling lpj -DFLAG, e.g lpj -DISRANDOM
ISRANDOM: switches on the weather generator
RIVER_ROUTING: without flag: no routing, potential irrigation
               with flag: routing, irrigation depends on available water in the rivers
FROM_RESTART: a restart-file is generated at the end of each LPJ run. Set this flag to restart from this point (which might be useful e.g. to start multiple runs from the same spin-up run)
TOP

COMPILER FLAGS

compiler flags need to be set in Makefile.inc, and you have to call "make clean all" to recompile afterwards
add -D"FLAG" to the line specifying CFLAGS

LPJ specific

RIVER_ROUTING for reading input for routing and for river routing itself
NAT_VEG quick fix to run LPJmL with natural vegetation only
USE_CPP
DEBUGEFENCE needed only to run LPJmL in a degugging environment (DDD on linux or dbx on UNIX): here, uninitialized variables are not allowed, although they are no problem in the normal running mode
DEBUG include lots of print statements in the code
LANDUSE so far only in the LPJ_SPEEDY branch. Includes all land-use specific routines, especially the memory allocation to the cropdates and the landuse structure.
SAFE Check LPJ variables and data, traps errors (such as negative soil moisture)

Compiler specific

Option
Comment
g Produce debugging information in the operating system's native format
O3
Optimize yet more. -O3 turns on all optimizations specified by -O2 and also turns on the -finline-functions, -funswitch-loops and -fgcse-after-reload options.
Wall This enables all the warnings.
USE_CPP Enable preprocessing
USE_UNAME Include /sys/utsname.h for system informations
USE_RAND48 Use seed uniformly distributed double-precision pseudo-random number generator
DEBUGEFENCE needed only to run LPJmL in a degugging environment (DDD on linux or dbx on UNIX):here, uninitialized variables are not allowed, although they are no problem in the normal running mode

TOP

RUNNING AND COMPILING LPJ UNDER WINDOWS

Windows requires some specific adjustments to make LPJ compile and run. Here's a first overview of what to do:

General

CVS

Visual C++ 2005

TOP

RUNNING IT IN PARALLEL

use distribute.sh to create command files for the PIK cluster and *.conf files for each package
the matrix is split into packages of pixels; each package can be run separately
If you are using PIK's cluster, change the parameters for the command file and the lines of the *.conf files as necessary. If you run LPJ outside PIK, adapt the script accordingly.
You need a different script if you want to use river routing
TOP

RUNNING IT WITH LAND USE

If you want to account for croplands in LPJmL simulations, in some CVS branches (e.g. LPJ_SPEEDY) you need to compile the code with the -DLANDUSE (or LANDUSE under windows) option. If this is compiler switch is turned on, please make sure that
- the path to the land-use file is specified in the cru_*.conf file and
- the pft.par file includes the line 11 /* number of cfts */ after the line 9 /* number of pfts */
TOP

RUNNING IT IN RIVER-ROUTING MODE

for a global run packages for input are already generated
see /data/biosx02/input_clm/input_river/README for more informations
use distribute_river.sh to send it to the cluster
TOP

RUNNING IT COUPLED TO IMAGE

If coupled to IMAGE, the code needs to be compiled with the -DIMAGE (or IMAGE under windows) option. If this switch is activated, you need to include the correct TDT libraries (see TDT coupling). Also, you need to call the program with the -DIMAGE option in the command line (such as lpj -DIMAGE lpj.conf or lpj.exe -DIMAGE lpj.conf). Otherwise the conf files are not read in correctly.
TOP

MALLOC DEBUGGING

How to

TOP

REMOVING LIST ELEMENTS

If you delete an element of a list (e.g., pftlist, standlist) the last element is moved to the position of the deleted element
TOP

WHAT IS THE OUTPUT?

how to add/remove output files

output file formats

grid.out:
short (2 bytes) plain binary, lon lat [deg*100]; this may be different from the input grid, as it only contains those pixels with a soilcode > 0

all other output files
:
plain binary (BSQ), data type float (4 bytes) , cell number and order are the same as in the gridfile
output files that start with "m" are monthly output and have thus 12 bands per year
fpc is calculated for each pft from the natural vegetation, the first band contains the fraction of natural vegetation, pfts follow in the order they occur in pft.par. If you have 9 pfts, you'll have 10 bands output per year.

some common output variables:

TOP

HOW TO HANDLE OUTPUT FILES?

TOP

READING BINARY FILES

TOP

HOW TO ADD NEW OUTPUT

TOP

ABOUT BYTE ORDERING / ENDIANNESS

   If you get strange errors (such as really unsensible values for your output data) when reading binary data, one reason might be that the data has been written on a different system architecture than the one you are using for reading it, and that those systems  store data internally in a different byte order. You might use the functions in src/tools/swap.c to change the byte order if you are programming in C, and there are many examples in other languages on the web. Those functions should work fine for all integer data types (i.e. short/int/long in C/C++), and you don't need to think about char data, as it is one byte only. On most systems, the integer swapping fuctions should work for float data types as well.
TOP

MEMORY SHORTAGES (XLC COMPILER)

TOP

STRUCTURE OF THE CODE

Folders / files and functions

LPJmL is a modular program: to keep it simple, the general rule is to have ONE function per file (exceptions are several functions for one topic e.g. output.c)

include/*.h: include files
par/*.par: parameter files
lib/*.a: compiled modules from each source code folder

source code folders (src/*):
each of the source code folders has its own Makefile (which is called from the folder above). If you want to add a new module, create a folder for it, write a Makefile following the template of any other module and link the library in src/Makefile

Spatial organization of LPJ (cell / stand / pft)

Cell

A cell is the base unit of LPJ. The input and parameter data (climate, soil, landuse and country codes) are read in for each cell. An array of cells is called grid

Stand

A stand is a subunit of a cell, it is defined by a common soil, atmosphere and water budget; a cell can contain several stands; all natural pfts share one stand, while each cft has its own stand. The fraction of the gridcell which is covered by this particular stand, is stored in the variable "frac" of the stand structure.
standtypes are: NATURAL, SETASIDE (collection of harvested areas from all crops; pool of area for next year's crops), AGRICULTURE (currently growing crops), MANAGED_FOREST (not used at the moment), GRASSLAND (managed grasslands), KILL (initializes harvest of crops, intermediate step between AGRICULTURE and SETASIDE)

Pft

a pft is a plant functional type. It is the functional unit of LPJ. All plant physiological process run on the unit of average individuals of those pfts. They are distinguished by a set of parameters (see pft.par). The nomenclature in LPJ is a bit confusing: sometimes, "pft" is used just for natural vegetation (e.g. npft), sometimes for both natural and human managed types. "cft" refers to crops only, ncft is the number of crops. If you want to loop over all pfts / cfts and managed grasses, you have to use npft+2*(ncft+NGRASS) (the factor 2 includes irrigated and non-irrigated crops/grasses) 

Organization of variables: parameters vs. cell-based values

LPJ follows a hierarchical structure with respect to variable storage. Any parameter that can be grouped on a higher level (such as soil type, pft, country) and that does not change during the runtime of the program, is stored in parameter structures (Soilpar, Pftpar, etc.). Each cell/stand/pft contains just a pointer to those parameter structures, which is far more memory efficient than if it would contain the complete structure. Variables that change spatially / over time have to be cell specific and have to be included into the correct structures (e.g. Soil, Pft, Cell, Stand).  

Pft-specific functions / structures

There are - at the moment - three types of pft: tree, grass and crop. They share many parameters and variables, but differ in others (a tree, for example, needs a sapwood and heartwood carbon pool, the other types do not). Those type-specific parameters / variables can be accessed with the "data" pointer of the Pftpar / Pft structure.
Similarly, some of the functions need to be type-specific: npp of trees, for example, needs to take sapwood-respiration into account, and is hence a distinct function (npp_tree). To keep the code simple and modular, LPJ works with function pointers in this case: each Pftpar structure contains such pointers, which are set in the fscanpft-functions. To call them - pft-independently - from the code, there are macros (called npp in this example), which call the correct function automatically.
TOP

Last updated: 17.12.2007