Sebastian Ostberg edited this page Jul 21, 2023 · 3 revisions

Output

[[TOC]]

Output files

There are three different types of output files:

  • annual outputs, one value per pixel or CFT/PFT specific (61 files)
  • monthly outputs (54 files)
  • daily outputs (43 files)

You find information in

  • source:trunk/include/conf.h listing the variables
  • source:trunk/par/outputvars.par giving the variables, units and description

File format of the main outputs

file namedata type[size]contentdata unit[scaled]dimensioncomment
general
grid.binshort [2 bytes]coordinatesdeg*1002(lon,lat)*grid cells
vegc.binfloat [4 bytes]vegetation carbon poolgC/m²c(grid cells, nyears)
litc.binfloat [4 bytes]litter carbon poolgC/m²c(grid cells, nyears)
soilc.binfloat [4 bytes]soil carbon poolgC/m²c(grid cells, nyears)
firec.binfloat [4 bytes]carbon released by firegC/m²c(grid cells, nyears)
mprec.binfloat [4 bytes]monthly precipitationmmc(grid cells, 12, nyears)valid for all output files starting with “m”
mnpp.binfloat [4 bytes]monthly net primary productiongC/m²c(grid cells, 12, nyears)
mrh.binfloat [4 bytes]monthly respirationgC/m²c(grid cells, 12, nyears)
natural vegetation
fpc.binfloat [4 bytes]foliage projected cover of natural vegetation in grid cell%c(ncell, ncft*2+91.band in (npft+1): total fraction of natural vegetation, 2. to last band: pfts follow in the order they occur in pft.par
firef.bin (?)float [4 bytes]fire return interval1/fraction of grid cell burned this year
agricultural vegetation
sdates.binshort [2 bytes]sowing datedayofyear [1:365]c(grid cells, 24, nyears)12 crops irrigated/rainfed
hdates.binshort [2 bytes]harvest datedayofyear [1:365]c(grid cells, 24, nyears)12 crops irrigated/rainfed
growing_period.binfloat [4 bytes]length of growing periodlength of growing period in daysc(grid cells, 28, nyears)(12 ncfts + grass) *2
pft_harvest.pft.binfloat [4 bytes]crop yieldgC/m²c(ncell, [[Cropsncft]]*2 , nyears)
pft_rharvest.pft.binfloat [4 bytes]crop residue yieldgC/m²c(ncell, ncft*2, nyears)cfts: rainfed/irrigated
pft_npp.binfloat [4 bytes]gC/m²c(ncell, ncft*2+9, nyears)cfts: rainfed/irrigated

all output files in plain binary (BSQ)

Grid-based vs. PFT-based

Some PFT/CFT-specific outputs (see list below for examples) are available as output per grid cell (grid-based) or per pft (pft-based). The grid-based output is internally multiplied with the stand fraction in a grid cell and will be generated if WITH_GRIDBASED is defined in lpjml.conf. If this line is not enabled (the default setting) the output will be pft_based. To convert back, multiply with stand_frac and cellarea.

  • pft_harvest
  • pft_npp
  • cft_nir
  • cft_airrig
  • cft_consump_water_g

How to handle output files

a) if lpj has been run in distributed mode, use output_bsq.ksh to join the output parts to one file
all following steps will be the same
b) creating a rectangular binary image from the output
use the program grd2bsq (call it with [-h] to get help)
don’t forget to use the output grid, not input grid … ;-)
c) see next point on how to read binary data

Reading binary files

- quite simple with any programming language, once you know how the data is stored (as described under point 8b, but see below for byte order issues)

- most image processing programs have an option to import binary data (but they usually need it in a rectangular grid, see point 9 b)

- R can read binary data. We now offer the lpjmlkit R package to help with reading both LPJmL input and output files. If you want to use lpjmlkit consider changing the output format from RAW to CLM in lpjml.conf/lpjml.js so that the necessary metadata about number of cells, number of bands etc. are included in files.

- ArcView / ArcGIS: they DO read binary input data, but the online help system will not tell you … You need to specify a header with data type, coordinates etc, there should be information on the web about the specifications for the version you are using. It seems to cause problems to read negative values, though.
- if you have problems importing binary data to the software you are using for analysis, you might need to write a program that converts the output data to ASCII (or use the respective function of a different software package)

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 - just bad luck - 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. Things get more complicated if you look at floating point data types: additionally to byte order issues the internal representation of the number might be different. You are on the safe side if you avoid reading binary floating point data from a different architecture. However, most systems seem to follow the IEEE floating point standard, so you might be lucky using the integer byte swapping functions.

Adding new output

In order to add new outputs, you’ll have to take care of several things. There are in principle 4 different output types available.

  • annual outputs per pixel
  • annual outputs per PFT/CFT
  • monthly outputs per pixel
  • daily outputs per pixel for 1 single CFT

There are currently 158 different outputs defined in LPJmL, see include/conf.h. Additional output — even if not written away during the run, will increase the memory requirements of the model. Please consider this, when adding new outputs. You can search the code for existing outputs (e.g. ‘MIRRIG’ AND ‘mirrig’) and use this as a guideline. Unless you plan to implement a new type of output, you can copy/paste existing structures and functions.

  • Create a unique identifier in include/conf.h
    (!) Daily outputs need to be IN BETWEEN D_LAI and D_PET. Keep order as in include/output.h
  • Increment NOUT in include/conf.h by the number of new outputs created
  • Define units, scale, description of new output in outputvars.par
  • Add new elements to the structure Output in include/output.h
    (!) Monthly outputs need to be added to the structure Output and also to the structure Outputmonth.
    (!) Daily outputs have to be added to the structure Daily_outputs only, they need to be IN BETWEEN D_LAI and D_PET
    (!) Daily outputs should be in the order of daily output identifiers in include/conf.h
  • Add output variable (including: id, name, variable(NetCDF), description, unit, scale) to list of files in par/outputvars.par
    (!) Daily outputs should be in the same order as in include/conf.h and include/output.h.
  • For PFT/CFT-specific outputs: allocate memory to element in src/lpj/initoutput.c
  • For PFT/CFT-specific outputs: free memory of element in src/lpj/freeoutput.c
  • Initialize new output elements in corresponding init function (e.g. initoutput_monthly.c)
  • MONTHLY outputs only: Add output identifier to function that checks type of output (i.e. src/lpj/ismonthlyoutput.c)
  • MONTHLY outputs only: Add new output structure element(s) to function that allocates memory: src/lpj/newoutputmonthly.c
  • Add output identifier to src/lpj/outputbuffersize.c (mind the correct position!)
  • Write away output in corresponding fwriteoutput_* function (e.g. fwriteoutput_monthly.c & fwriteoutput_monthly2.c)
    (!) There are 2 functions for monthly and daily outputs, both are needed (one for with river routing, the other for without)
  • Fill output structure with values wanted at the appropriate place in the code. Pay attention to the difference between + and += and that the output works for all options (e.g. with and without river routing) and land use types.
  • MONTHLY outputs only: add new output to src/lpj/update_outputmonthly.c and free output memory after it is written to file at end of year in src/lpj/freeoutputmonthly.c
  • Finally, call new output variable in lpjml.conf in order to write it to file

Clone this wiki locally

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Add copy buttons to all
 blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks");
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '
Skip to content
Sebastian Ostberg edited this page Jul 21, 2023 · 3 revisions

Output

[[TOC]]

Output files

There are three different types of output files:

  • annual outputs, one value per pixel or CFT/PFT specific (61 files)
  • monthly outputs (54 files)
  • daily outputs (43 files)

You find information in

  • source:trunk/include/conf.h listing the variables
  • source:trunk/par/outputvars.par giving the variables, units and description

File format of the main outputs

file namedata type[size]contentdata unit[scaled]dimensioncomment
general
grid.binshort [2 bytes]coordinatesdeg*1002(lon,lat)*grid cells
vegc.binfloat [4 bytes]vegetation carbon poolgC/m²c(grid cells, nyears)
litc.binfloat [4 bytes]litter carbon poolgC/m²c(grid cells, nyears)
soilc.binfloat [4 bytes]soil carbon poolgC/m²c(grid cells, nyears)
firec.binfloat [4 bytes]carbon released by firegC/m²c(grid cells, nyears)
mprec.binfloat [4 bytes]monthly precipitationmmc(grid cells, 12, nyears)valid for all output files starting with “m”
mnpp.binfloat [4 bytes]monthly net primary productiongC/m²c(grid cells, 12, nyears)
mrh.binfloat [4 bytes]monthly respirationgC/m²c(grid cells, 12, nyears)
natural vegetation
fpc.binfloat [4 bytes]foliage projected cover of natural vegetation in grid cell%c(ncell, ncft*2+91.band in (npft+1): total fraction of natural vegetation, 2. to last band: pfts follow in the order they occur in pft.par
firef.bin (?)float [4 bytes]fire return interval1/fraction of grid cell burned this year
agricultural vegetation
sdates.binshort [2 bytes]sowing datedayofyear [1:365]c(grid cells, 24, nyears)12 crops irrigated/rainfed
hdates.binshort [2 bytes]harvest datedayofyear [1:365]c(grid cells, 24, nyears)12 crops irrigated/rainfed
growing_period.binfloat [4 bytes]length of growing periodlength of growing period in daysc(grid cells, 28, nyears)(12 ncfts + grass) *2
pft_harvest.pft.binfloat [4 bytes]crop yieldgC/m²c(ncell, [[Cropsncft]]*2 , nyears)
pft_rharvest.pft.binfloat [4 bytes]crop residue yieldgC/m²c(ncell, ncft*2, nyears)cfts: rainfed/irrigated
pft_npp.binfloat [4 bytes]gC/m²c(ncell, ncft*2+9, nyears)cfts: rainfed/irrigated

all output files in plain binary (BSQ)

Grid-based vs. PFT-based

Some PFT/CFT-specific outputs (see list below for examples) are available as output per grid cell (grid-based) or per pft (pft-based). The grid-based output is internally multiplied with the stand fraction in a grid cell and will be generated if WITH_GRIDBASED is defined in lpjml.conf. If this line is not enabled (the default setting) the output will be pft_based. To convert back, multiply with stand_frac and cellarea.

  • pft_harvest
  • pft_npp
  • cft_nir
  • cft_airrig
  • cft_consump_water_g

How to handle output files

a) if lpj has been run in distributed mode, use output_bsq.ksh to join the output parts to one file
all following steps will be the same
b) creating a rectangular binary image from the output
use the program grd2bsq (call it with [-h] to get help)
don’t forget to use the output grid, not input grid … ;-)
c) see next point on how to read binary data

Reading binary files

- quite simple with any programming language, once you know how the data is stored (as described under point 8b, but see below for byte order issues)

- most image processing programs have an option to import binary data (but they usually need it in a rectangular grid, see point 9 b)

- R can read binary data. We now offer the lpjmlkit R package to help with reading both LPJmL input and output files. If you want to use lpjmlkit consider changing the output format from RAW to CLM in lpjml.conf/lpjml.js so that the necessary metadata about number of cells, number of bands etc. are included in files.

- ArcView / ArcGIS: they DO read binary input data, but the online help system will not tell you … You need to specify a header with data type, coordinates etc, there should be information on the web about the specifications for the version you are using. It seems to cause problems to read negative values, though.
- if you have problems importing binary data to the software you are using for analysis, you might need to write a program that converts the output data to ASCII (or use the respective function of a different software package)

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 - just bad luck - 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. Things get more complicated if you look at floating point data types: additionally to byte order issues the internal representation of the number might be different. You are on the safe side if you avoid reading binary floating point data from a different architecture. However, most systems seem to follow the IEEE floating point standard, so you might be lucky using the integer byte swapping functions.

Adding new output

In order to add new outputs, you’ll have to take care of several things. There are in principle 4 different output types available.

  • annual outputs per pixel
  • annual outputs per PFT/CFT
  • monthly outputs per pixel
  • daily outputs per pixel for 1 single CFT

There are currently 158 different outputs defined in LPJmL, see include/conf.h. Additional output — even if not written away during the run, will increase the memory requirements of the model. Please consider this, when adding new outputs. You can search the code for existing outputs (e.g. ‘MIRRIG’ AND ‘mirrig’) and use this as a guideline. Unless you plan to implement a new type of output, you can copy/paste existing structures and functions.

  • Create a unique identifier in include/conf.h
    (!) Daily outputs need to be IN BETWEEN D_LAI and D_PET. Keep order as in include/output.h
  • Increment NOUT in include/conf.h by the number of new outputs created
  • Define units, scale, description of new output in outputvars.par
  • Add new elements to the structure Output in include/output.h
    (!) Monthly outputs need to be added to the structure Output and also to the structure Outputmonth.
    (!) Daily outputs have to be added to the structure Daily_outputs only, they need to be IN BETWEEN D_LAI and D_PET
    (!) Daily outputs should be in the order of daily output identifiers in include/conf.h
  • Add output variable (including: id, name, variable(NetCDF), description, unit, scale) to list of files in par/outputvars.par
    (!) Daily outputs should be in the same order as in include/conf.h and include/output.h.
  • For PFT/CFT-specific outputs: allocate memory to element in src/lpj/initoutput.c
  • For PFT/CFT-specific outputs: free memory of element in src/lpj/freeoutput.c
  • Initialize new output elements in corresponding init function (e.g. initoutput_monthly.c)
  • MONTHLY outputs only: Add output identifier to function that checks type of output (i.e. src/lpj/ismonthlyoutput.c)
  • MONTHLY outputs only: Add new output structure element(s) to function that allocates memory: src/lpj/newoutputmonthly.c
  • Add output identifier to src/lpj/outputbuffersize.c (mind the correct position!)
  • Write away output in corresponding fwriteoutput_* function (e.g. fwriteoutput_monthly.c & fwriteoutput_monthly2.c)
    (!) There are 2 functions for monthly and daily outputs, both are needed (one for with river routing, the other for without)
  • Fill output structure with values wanted at the appropriate place in the code. Pay attention to the difference between + and += and that the output works for all options (e.g. with and without river routing) and land use types.
  • MONTHLY outputs only: add new output to src/lpj/update_outputmonthly.c and free output memory after it is written to file at end of year in src/lpj/freeoutputmonthly.c
  • Finally, call new output variable in lpjml.conf in order to write it to file

Clone this wiki locally

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix"); } } catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content
Sebastian Ostberg edited this page Jul 21, 2023 · 3 revisions

Output

[[TOC]]

Output files

There are three different types of output files:

  • annual outputs, one value per pixel or CFT/PFT specific (61 files)
  • monthly outputs (54 files)
  • daily outputs (43 files)

You find information in

  • source:trunk/include/conf.h listing the variables
  • source:trunk/par/outputvars.par giving the variables, units and description

File format of the main outputs

file namedata type[size]contentdata unit[scaled]dimensioncomment
general
grid.binshort [2 bytes]coordinatesdeg*1002(lon,lat)*grid cells
vegc.binfloat [4 bytes]vegetation carbon poolgC/m²c(grid cells, nyears)
litc.binfloat [4 bytes]litter carbon poolgC/m²c(grid cells, nyears)
soilc.binfloat [4 bytes]soil carbon poolgC/m²c(grid cells, nyears)
firec.binfloat [4 bytes]carbon released by firegC/m²c(grid cells, nyears)
mprec.binfloat [4 bytes]monthly precipitationmmc(grid cells, 12, nyears)valid for all output files starting with “m”
mnpp.binfloat [4 bytes]monthly net primary productiongC/m²c(grid cells, 12, nyears)
mrh.binfloat [4 bytes]monthly respirationgC/m²c(grid cells, 12, nyears)
natural vegetation
fpc.binfloat [4 bytes]foliage projected cover of natural vegetation in grid cell%c(ncell, ncft*2+91.band in (npft+1): total fraction of natural vegetation, 2. to last band: pfts follow in the order they occur in pft.par
firef.bin (?)float [4 bytes]fire return interval1/fraction of grid cell burned this year
agricultural vegetation
sdates.binshort [2 bytes]sowing datedayofyear [1:365]c(grid cells, 24, nyears)12 crops irrigated/rainfed
hdates.binshort [2 bytes]harvest datedayofyear [1:365]c(grid cells, 24, nyears)12 crops irrigated/rainfed
growing_period.binfloat [4 bytes]length of growing periodlength of growing period in daysc(grid cells, 28, nyears)(12 ncfts + grass) *2
pft_harvest.pft.binfloat [4 bytes]crop yieldgC/m²c(ncell, [[Cropsncft]]*2 , nyears)
pft_rharvest.pft.binfloat [4 bytes]crop residue yieldgC/m²c(ncell, ncft*2, nyears)cfts: rainfed/irrigated
pft_npp.binfloat [4 bytes]gC/m²c(ncell, ncft*2+9, nyears)cfts: rainfed/irrigated

all output files in plain binary (BSQ)

Grid-based vs. PFT-based

Some PFT/CFT-specific outputs (see list below for examples) are available as output per grid cell (grid-based) or per pft (pft-based). The grid-based output is internally multiplied with the stand fraction in a grid cell and will be generated if WITH_GRIDBASED is defined in lpjml.conf. If this line is not enabled (the default setting) the output will be pft_based. To convert back, multiply with stand_frac and cellarea.

  • pft_harvest
  • pft_npp
  • cft_nir
  • cft_airrig
  • cft_consump_water_g

How to handle output files

a) if lpj has been run in distributed mode, use output_bsq.ksh to join the output parts to one file
all following steps will be the same
b) creating a rectangular binary image from the output
use the program grd2bsq (call it with [-h] to get help)
don’t forget to use the output grid, not input grid … ;-)
c) see next point on how to read binary data

Reading binary files

- quite simple with any programming language, once you know how the data is stored (as described under point 8b, but see below for byte order issues)

- most image processing programs have an option to import binary data (but they usually need it in a rectangular grid, see point 9 b)

- R can read binary data. We now offer the lpjmlkit R package to help with reading both LPJmL input and output files. If you want to use lpjmlkit consider changing the output format from RAW to CLM in lpjml.conf/lpjml.js so that the necessary metadata about number of cells, number of bands etc. are included in files.

- ArcView / ArcGIS: they DO read binary input data, but the online help system will not tell you … You need to specify a header with data type, coordinates etc, there should be information on the web about the specifications for the version you are using. It seems to cause problems to read negative values, though.
- if you have problems importing binary data to the software you are using for analysis, you might need to write a program that converts the output data to ASCII (or use the respective function of a different software package)

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 - just bad luck - 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. Things get more complicated if you look at floating point data types: additionally to byte order issues the internal representation of the number might be different. You are on the safe side if you avoid reading binary floating point data from a different architecture. However, most systems seem to follow the IEEE floating point standard, so you might be lucky using the integer byte swapping functions.

Adding new output

In order to add new outputs, you’ll have to take care of several things. There are in principle 4 different output types available.

  • annual outputs per pixel
  • annual outputs per PFT/CFT
  • monthly outputs per pixel
  • daily outputs per pixel for 1 single CFT

There are currently 158 different outputs defined in LPJmL, see include/conf.h. Additional output — even if not written away during the run, will increase the memory requirements of the model. Please consider this, when adding new outputs. You can search the code for existing outputs (e.g. ‘MIRRIG’ AND ‘mirrig’) and use this as a guideline. Unless you plan to implement a new type of output, you can copy/paste existing structures and functions.

  • Create a unique identifier in include/conf.h
    (!) Daily outputs need to be IN BETWEEN D_LAI and D_PET. Keep order as in include/output.h
  • Increment NOUT in include/conf.h by the number of new outputs created
  • Define units, scale, description of new output in outputvars.par
  • Add new elements to the structure Output in include/output.h
    (!) Monthly outputs need to be added to the structure Output and also to the structure Outputmonth.
    (!) Daily outputs have to be added to the structure Daily_outputs only, they need to be IN BETWEEN D_LAI and D_PET
    (!) Daily outputs should be in the order of daily output identifiers in include/conf.h
  • Add output variable (including: id, name, variable(NetCDF), description, unit, scale) to list of files in par/outputvars.par
    (!) Daily outputs should be in the same order as in include/conf.h and include/output.h.
  • For PFT/CFT-specific outputs: allocate memory to element in src/lpj/initoutput.c
  • For PFT/CFT-specific outputs: free memory of element in src/lpj/freeoutput.c
  • Initialize new output elements in corresponding init function (e.g. initoutput_monthly.c)
  • MONTHLY outputs only: Add output identifier to function that checks type of output (i.e. src/lpj/ismonthlyoutput.c)
  • MONTHLY outputs only: Add new output structure element(s) to function that allocates memory: src/lpj/newoutputmonthly.c
  • Add output identifier to src/lpj/outputbuffersize.c (mind the correct position!)
  • Write away output in corresponding fwriteoutput_* function (e.g. fwriteoutput_monthly.c & fwriteoutput_monthly2.c)
    (!) There are 2 functions for monthly and daily outputs, both are needed (one for with river routing, the other for without)
  • Fill output structure with values wanted at the appropriate place in the code. Pay attention to the difference between + and += and that the output works for all options (e.g. with and without river routing) and land use types.
  • MONTHLY outputs only: add new output to src/lpj/update_outputmonthly.c and free output memory after it is written to file at end of year in src/lpj/freeoutputmonthly.c
  • Finally, call new output variable in lpjml.conf in order to write it to file

Clone this wiki locally

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length > 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms"); } } catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content
Sebastian Ostberg edited this page Jul 21, 2023 · 3 revisions

Output

[[TOC]]

Output files

There are three different types of output files:

  • annual outputs, one value per pixel or CFT/PFT specific (61 files)
  • monthly outputs (54 files)
  • daily outputs (43 files)

You find information in

  • source:trunk/include/conf.h listing the variables
  • source:trunk/par/outputvars.par giving the variables, units and description

File format of the main outputs

file namedata type[size]contentdata unit[scaled]dimensioncomment
general
grid.binshort [2 bytes]coordinatesdeg*1002(lon,lat)*grid cells
vegc.binfloat [4 bytes]vegetation carbon poolgC/m²c(grid cells, nyears)
litc.binfloat [4 bytes]litter carbon poolgC/m²c(grid cells, nyears)
soilc.binfloat [4 bytes]soil carbon poolgC/m²c(grid cells, nyears)
firec.binfloat [4 bytes]carbon released by firegC/m²c(grid cells, nyears)
mprec.binfloat [4 bytes]monthly precipitationmmc(grid cells, 12, nyears)valid for all output files starting with “m”
mnpp.binfloat [4 bytes]monthly net primary productiongC/m²c(grid cells, 12, nyears)
mrh.binfloat [4 bytes]monthly respirationgC/m²c(grid cells, 12, nyears)
natural vegetation
fpc.binfloat [4 bytes]foliage projected cover of natural vegetation in grid cell%c(ncell, ncft*2+91.band in (npft+1): total fraction of natural vegetation, 2. to last band: pfts follow in the order they occur in pft.par
firef.bin (?)float [4 bytes]fire return interval1/fraction of grid cell burned this year
agricultural vegetation
sdates.binshort [2 bytes]sowing datedayofyear [1:365]c(grid cells, 24, nyears)12 crops irrigated/rainfed
hdates.binshort [2 bytes]harvest datedayofyear [1:365]c(grid cells, 24, nyears)12 crops irrigated/rainfed
growing_period.binfloat [4 bytes]length of growing periodlength of growing period in daysc(grid cells, 28, nyears)(12 ncfts + grass) *2
pft_harvest.pft.binfloat [4 bytes]crop yieldgC/m²c(ncell, [[Cropsncft]]*2 , nyears)
pft_rharvest.pft.binfloat [4 bytes]crop residue yieldgC/m²c(ncell, ncft*2, nyears)cfts: rainfed/irrigated
pft_npp.binfloat [4 bytes]gC/m²c(ncell, ncft*2+9, nyears)cfts: rainfed/irrigated

all output files in plain binary (BSQ)

Grid-based vs. PFT-based

Some PFT/CFT-specific outputs (see list below for examples) are available as output per grid cell (grid-based) or per pft (pft-based). The grid-based output is internally multiplied with the stand fraction in a grid cell and will be generated if WITH_GRIDBASED is defined in lpjml.conf. If this line is not enabled (the default setting) the output will be pft_based. To convert back, multiply with stand_frac and cellarea.

  • pft_harvest
  • pft_npp
  • cft_nir
  • cft_airrig
  • cft_consump_water_g

How to handle output files

a) if lpj has been run in distributed mode, use output_bsq.ksh to join the output parts to one file
all following steps will be the same
b) creating a rectangular binary image from the output
use the program grd2bsq (call it with [-h] to get help)
don’t forget to use the output grid, not input grid … ;-)
c) see next point on how to read binary data

Reading binary files

- quite simple with any programming language, once you know how the data is stored (as described under point 8b, but see below for byte order issues)

- most image processing programs have an option to import binary data (but they usually need it in a rectangular grid, see point 9 b)

- R can read binary data. We now offer the lpjmlkit R package to help with reading both LPJmL input and output files. If you want to use lpjmlkit consider changing the output format from RAW to CLM in lpjml.conf/lpjml.js so that the necessary metadata about number of cells, number of bands etc. are included in files.

- ArcView / ArcGIS: they DO read binary input data, but the online help system will not tell you … You need to specify a header with data type, coordinates etc, there should be information on the web about the specifications for the version you are using. It seems to cause problems to read negative values, though.
- if you have problems importing binary data to the software you are using for analysis, you might need to write a program that converts the output data to ASCII (or use the respective function of a different software package)

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 - just bad luck - 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. Things get more complicated if you look at floating point data types: additionally to byte order issues the internal representation of the number might be different. You are on the safe side if you avoid reading binary floating point data from a different architecture. However, most systems seem to follow the IEEE floating point standard, so you might be lucky using the integer byte swapping functions.

Adding new output

In order to add new outputs, you’ll have to take care of several things. There are in principle 4 different output types available.

  • annual outputs per pixel
  • annual outputs per PFT/CFT
  • monthly outputs per pixel
  • daily outputs per pixel for 1 single CFT

There are currently 158 different outputs defined in LPJmL, see include/conf.h. Additional output — even if not written away during the run, will increase the memory requirements of the model. Please consider this, when adding new outputs. You can search the code for existing outputs (e.g. ‘MIRRIG’ AND ‘mirrig’) and use this as a guideline. Unless you plan to implement a new type of output, you can copy/paste existing structures and functions.

  • Create a unique identifier in include/conf.h
    (!) Daily outputs need to be IN BETWEEN D_LAI and D_PET. Keep order as in include/output.h
  • Increment NOUT in include/conf.h by the number of new outputs created
  • Define units, scale, description of new output in outputvars.par
  • Add new elements to the structure Output in include/output.h
    (!) Monthly outputs need to be added to the structure Output and also to the structure Outputmonth.
    (!) Daily outputs have to be added to the structure Daily_outputs only, they need to be IN BETWEEN D_LAI and D_PET
    (!) Daily outputs should be in the order of daily output identifiers in include/conf.h
  • Add output variable (including: id, name, variable(NetCDF), description, unit, scale) to list of files in par/outputvars.par
    (!) Daily outputs should be in the same order as in include/conf.h and include/output.h.
  • For PFT/CFT-specific outputs: allocate memory to element in src/lpj/initoutput.c
  • For PFT/CFT-specific outputs: free memory of element in src/lpj/freeoutput.c
  • Initialize new output elements in corresponding init function (e.g. initoutput_monthly.c)
  • MONTHLY outputs only: Add output identifier to function that checks type of output (i.e. src/lpj/ismonthlyoutput.c)
  • MONTHLY outputs only: Add new output structure element(s) to function that allocates memory: src/lpj/newoutputmonthly.c
  • Add output identifier to src/lpj/outputbuffersize.c (mind the correct position!)
  • Write away output in corresponding fwriteoutput_* function (e.g. fwriteoutput_monthly.c & fwriteoutput_monthly2.c)
    (!) There are 2 functions for monthly and daily outputs, both are needed (one for with river routing, the other for without)
  • Fill output structure with values wanted at the appropriate place in the code. Pay attention to the difference between + and += and that the output works for all options (e.g. with and without river routing) and land use types.
  • MONTHLY outputs only: add new output to src/lpj/update_outputmonthly.c and free output memory after it is written to file at end of year in src/lpj/freeoutputmonthly.c
  • Finally, call new output variable in lpjml.conf in order to write it to file

Clone this wiki locally

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links"); } } catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); } })(); (function(){ try { var __m = "youtube.com"; var __re = new RegExp('^' + "youtube\\.com" + '
Skip to content
Sebastian Ostberg edited this page Jul 21, 2023 · 3 revisions

Output

[[TOC]]

Output files

There are three different types of output files:

  • annual outputs, one value per pixel or CFT/PFT specific (61 files)
  • monthly outputs (54 files)
  • daily outputs (43 files)

You find information in

  • source:trunk/include/conf.h listing the variables
  • source:trunk/par/outputvars.par giving the variables, units and description

File format of the main outputs

file namedata type[size]contentdata unit[scaled]dimensioncomment
general
grid.binshort [2 bytes]coordinatesdeg*1002(lon,lat)*grid cells
vegc.binfloat [4 bytes]vegetation carbon poolgC/m²c(grid cells, nyears)
litc.binfloat [4 bytes]litter carbon poolgC/m²c(grid cells, nyears)
soilc.binfloat [4 bytes]soil carbon poolgC/m²c(grid cells, nyears)
firec.binfloat [4 bytes]carbon released by firegC/m²c(grid cells, nyears)
mprec.binfloat [4 bytes]monthly precipitationmmc(grid cells, 12, nyears)valid for all output files starting with “m”
mnpp.binfloat [4 bytes]monthly net primary productiongC/m²c(grid cells, 12, nyears)
mrh.binfloat [4 bytes]monthly respirationgC/m²c(grid cells, 12, nyears)
natural vegetation
fpc.binfloat [4 bytes]foliage projected cover of natural vegetation in grid cell%c(ncell, ncft*2+91.band in (npft+1): total fraction of natural vegetation, 2. to last band: pfts follow in the order they occur in pft.par
firef.bin (?)float [4 bytes]fire return interval1/fraction of grid cell burned this year
agricultural vegetation
sdates.binshort [2 bytes]sowing datedayofyear [1:365]c(grid cells, 24, nyears)12 crops irrigated/rainfed
hdates.binshort [2 bytes]harvest datedayofyear [1:365]c(grid cells, 24, nyears)12 crops irrigated/rainfed
growing_period.binfloat [4 bytes]length of growing periodlength of growing period in daysc(grid cells, 28, nyears)(12 ncfts + grass) *2
pft_harvest.pft.binfloat [4 bytes]crop yieldgC/m²c(ncell, [[Cropsncft]]*2 , nyears)
pft_rharvest.pft.binfloat [4 bytes]crop residue yieldgC/m²c(ncell, ncft*2, nyears)cfts: rainfed/irrigated
pft_npp.binfloat [4 bytes]gC/m²c(ncell, ncft*2+9, nyears)cfts: rainfed/irrigated

all output files in plain binary (BSQ)

Grid-based vs. PFT-based

Some PFT/CFT-specific outputs (see list below for examples) are available as output per grid cell (grid-based) or per pft (pft-based). The grid-based output is internally multiplied with the stand fraction in a grid cell and will be generated if WITH_GRIDBASED is defined in lpjml.conf. If this line is not enabled (the default setting) the output will be pft_based. To convert back, multiply with stand_frac and cellarea.

  • pft_harvest
  • pft_npp
  • cft_nir
  • cft_airrig
  • cft_consump_water_g

How to handle output files

a) if lpj has been run in distributed mode, use output_bsq.ksh to join the output parts to one file
all following steps will be the same
b) creating a rectangular binary image from the output
use the program grd2bsq (call it with [-h] to get help)
don’t forget to use the output grid, not input grid … ;-)
c) see next point on how to read binary data

Reading binary files

- quite simple with any programming language, once you know how the data is stored (as described under point 8b, but see below for byte order issues)

- most image processing programs have an option to import binary data (but they usually need it in a rectangular grid, see point 9 b)

- R can read binary data. We now offer the lpjmlkit R package to help with reading both LPJmL input and output files. If you want to use lpjmlkit consider changing the output format from RAW to CLM in lpjml.conf/lpjml.js so that the necessary metadata about number of cells, number of bands etc. are included in files.

- ArcView / ArcGIS: they DO read binary input data, but the online help system will not tell you … You need to specify a header with data type, coordinates etc, there should be information on the web about the specifications for the version you are using. It seems to cause problems to read negative values, though.
- if you have problems importing binary data to the software you are using for analysis, you might need to write a program that converts the output data to ASCII (or use the respective function of a different software package)

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 - just bad luck - 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. Things get more complicated if you look at floating point data types: additionally to byte order issues the internal representation of the number might be different. You are on the safe side if you avoid reading binary floating point data from a different architecture. However, most systems seem to follow the IEEE floating point standard, so you might be lucky using the integer byte swapping functions.

Adding new output

In order to add new outputs, you’ll have to take care of several things. There are in principle 4 different output types available.

  • annual outputs per pixel
  • annual outputs per PFT/CFT
  • monthly outputs per pixel
  • daily outputs per pixel for 1 single CFT

There are currently 158 different outputs defined in LPJmL, see include/conf.h. Additional output — even if not written away during the run, will increase the memory requirements of the model. Please consider this, when adding new outputs. You can search the code for existing outputs (e.g. ‘MIRRIG’ AND ‘mirrig’) and use this as a guideline. Unless you plan to implement a new type of output, you can copy/paste existing structures and functions.

  • Create a unique identifier in include/conf.h
    (!) Daily outputs need to be IN BETWEEN D_LAI and D_PET. Keep order as in include/output.h
  • Increment NOUT in include/conf.h by the number of new outputs created
  • Define units, scale, description of new output in outputvars.par
  • Add new elements to the structure Output in include/output.h
    (!) Monthly outputs need to be added to the structure Output and also to the structure Outputmonth.
    (!) Daily outputs have to be added to the structure Daily_outputs only, they need to be IN BETWEEN D_LAI and D_PET
    (!) Daily outputs should be in the order of daily output identifiers in include/conf.h
  • Add output variable (including: id, name, variable(NetCDF), description, unit, scale) to list of files in par/outputvars.par
    (!) Daily outputs should be in the same order as in include/conf.h and include/output.h.
  • For PFT/CFT-specific outputs: allocate memory to element in src/lpj/initoutput.c
  • For PFT/CFT-specific outputs: free memory of element in src/lpj/freeoutput.c
  • Initialize new output elements in corresponding init function (e.g. initoutput_monthly.c)
  • MONTHLY outputs only: Add output identifier to function that checks type of output (i.e. src/lpj/ismonthlyoutput.c)
  • MONTHLY outputs only: Add new output structure element(s) to function that allocates memory: src/lpj/newoutputmonthly.c
  • Add output identifier to src/lpj/outputbuffersize.c (mind the correct position!)
  • Write away output in corresponding fwriteoutput_* function (e.g. fwriteoutput_monthly.c & fwriteoutput_monthly2.c)
    (!) There are 2 functions for monthly and daily outputs, both are needed (one for with river routing, the other for without)
  • Fill output structure with values wanted at the appropriate place in the code. Pay attention to the difference between + and += and that the output works for all options (e.g. with and without river routing) and land use types.
  • MONTHLY outputs only: add new output to src/lpj/update_outputmonthly.c and free output memory after it is written to file at end of year in src/lpj/freeoutputmonthly.c
  • Finally, call new output variable in lpjml.conf in order to write it to file

Clone this wiki locally

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default"); } } catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content
Sebastian Ostberg edited this page Jul 21, 2023 · 3 revisions

Output

[[TOC]]

Output files

There are three different types of output files:

  • annual outputs, one value per pixel or CFT/PFT specific (61 files)
  • monthly outputs (54 files)
  • daily outputs (43 files)

You find information in

  • source:trunk/include/conf.h listing the variables
  • source:trunk/par/outputvars.par giving the variables, units and description

File format of the main outputs

file namedata type[size]contentdata unit[scaled]dimensioncomment
general
grid.binshort [2 bytes]coordinatesdeg*1002(lon,lat)*grid cells
vegc.binfloat [4 bytes]vegetation carbon poolgC/m²c(grid cells, nyears)
litc.binfloat [4 bytes]litter carbon poolgC/m²c(grid cells, nyears)
soilc.binfloat [4 bytes]soil carbon poolgC/m²c(grid cells, nyears)
firec.binfloat [4 bytes]carbon released by firegC/m²c(grid cells, nyears)
mprec.binfloat [4 bytes]monthly precipitationmmc(grid cells, 12, nyears)valid for all output files starting with “m”
mnpp.binfloat [4 bytes]monthly net primary productiongC/m²c(grid cells, 12, nyears)
mrh.binfloat [4 bytes]monthly respirationgC/m²c(grid cells, 12, nyears)
natural vegetation
fpc.binfloat [4 bytes]foliage projected cover of natural vegetation in grid cell%c(ncell, ncft*2+91.band in (npft+1): total fraction of natural vegetation, 2. to last band: pfts follow in the order they occur in pft.par
firef.bin (?)float [4 bytes]fire return interval1/fraction of grid cell burned this year
agricultural vegetation
sdates.binshort [2 bytes]sowing datedayofyear [1:365]c(grid cells, 24, nyears)12 crops irrigated/rainfed
hdates.binshort [2 bytes]harvest datedayofyear [1:365]c(grid cells, 24, nyears)12 crops irrigated/rainfed
growing_period.binfloat [4 bytes]length of growing periodlength of growing period in daysc(grid cells, 28, nyears)(12 ncfts + grass) *2
pft_harvest.pft.binfloat [4 bytes]crop yieldgC/m²c(ncell, [[Cropsncft]]*2 , nyears)
pft_rharvest.pft.binfloat [4 bytes]crop residue yieldgC/m²c(ncell, ncft*2, nyears)cfts: rainfed/irrigated
pft_npp.binfloat [4 bytes]gC/m²c(ncell, ncft*2+9, nyears)cfts: rainfed/irrigated

all output files in plain binary (BSQ)

Grid-based vs. PFT-based

Some PFT/CFT-specific outputs (see list below for examples) are available as output per grid cell (grid-based) or per pft (pft-based). The grid-based output is internally multiplied with the stand fraction in a grid cell and will be generated if WITH_GRIDBASED is defined in lpjml.conf. If this line is not enabled (the default setting) the output will be pft_based. To convert back, multiply with stand_frac and cellarea.

  • pft_harvest
  • pft_npp
  • cft_nir
  • cft_airrig
  • cft_consump_water_g

How to handle output files

a) if lpj has been run in distributed mode, use output_bsq.ksh to join the output parts to one file
all following steps will be the same
b) creating a rectangular binary image from the output
use the program grd2bsq (call it with [-h] to get help)
don’t forget to use the output grid, not input grid … ;-)
c) see next point on how to read binary data

Reading binary files

- quite simple with any programming language, once you know how the data is stored (as described under point 8b, but see below for byte order issues)

- most image processing programs have an option to import binary data (but they usually need it in a rectangular grid, see point 9 b)

- R can read binary data. We now offer the lpjmlkit R package to help with reading both LPJmL input and output files. If you want to use lpjmlkit consider changing the output format from RAW to CLM in lpjml.conf/lpjml.js so that the necessary metadata about number of cells, number of bands etc. are included in files.

- ArcView / ArcGIS: they DO read binary input data, but the online help system will not tell you … You need to specify a header with data type, coordinates etc, there should be information on the web about the specifications for the version you are using. It seems to cause problems to read negative values, though.
- if you have problems importing binary data to the software you are using for analysis, you might need to write a program that converts the output data to ASCII (or use the respective function of a different software package)

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 - just bad luck - 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. Things get more complicated if you look at floating point data types: additionally to byte order issues the internal representation of the number might be different. You are on the safe side if you avoid reading binary floating point data from a different architecture. However, most systems seem to follow the IEEE floating point standard, so you might be lucky using the integer byte swapping functions.

Adding new output

In order to add new outputs, you’ll have to take care of several things. There are in principle 4 different output types available.

  • annual outputs per pixel
  • annual outputs per PFT/CFT
  • monthly outputs per pixel
  • daily outputs per pixel for 1 single CFT

There are currently 158 different outputs defined in LPJmL, see include/conf.h. Additional output — even if not written away during the run, will increase the memory requirements of the model. Please consider this, when adding new outputs. You can search the code for existing outputs (e.g. ‘MIRRIG’ AND ‘mirrig’) and use this as a guideline. Unless you plan to implement a new type of output, you can copy/paste existing structures and functions.

  • Create a unique identifier in include/conf.h
    (!) Daily outputs need to be IN BETWEEN D_LAI and D_PET. Keep order as in include/output.h
  • Increment NOUT in include/conf.h by the number of new outputs created
  • Define units, scale, description of new output in outputvars.par
  • Add new elements to the structure Output in include/output.h
    (!) Monthly outputs need to be added to the structure Output and also to the structure Outputmonth.
    (!) Daily outputs have to be added to the structure Daily_outputs only, they need to be IN BETWEEN D_LAI and D_PET
    (!) Daily outputs should be in the order of daily output identifiers in include/conf.h
  • Add output variable (including: id, name, variable(NetCDF), description, unit, scale) to list of files in par/outputvars.par
    (!) Daily outputs should be in the same order as in include/conf.h and include/output.h.
  • For PFT/CFT-specific outputs: allocate memory to element in src/lpj/initoutput.c
  • For PFT/CFT-specific outputs: free memory of element in src/lpj/freeoutput.c
  • Initialize new output elements in corresponding init function (e.g. initoutput_monthly.c)
  • MONTHLY outputs only: Add output identifier to function that checks type of output (i.e. src/lpj/ismonthlyoutput.c)
  • MONTHLY outputs only: Add new output structure element(s) to function that allocates memory: src/lpj/newoutputmonthly.c
  • Add output identifier to src/lpj/outputbuffersize.c (mind the correct position!)
  • Write away output in corresponding fwriteoutput_* function (e.g. fwriteoutput_monthly.c & fwriteoutput_monthly2.c)
    (!) There are 2 functions for monthly and daily outputs, both are needed (one for with river routing, the other for without)
  • Fill output structure with values wanted at the appropriate place in the code. Pay attention to the difference between + and += and that the output works for all options (e.g. with and without river routing) and land use types.
  • MONTHLY outputs only: add new output to src/lpj/update_outputmonthly.c and free output memory after it is written to file at end of year in src/lpj/freeoutputmonthly.c
  • Finally, call new output variable in lpjml.conf in order to write it to file

Clone this wiki locally

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers"); } } catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content
Sebastian Ostberg edited this page Jul 21, 2023 · 3 revisions

Output

[[TOC]]

Output files

There are three different types of output files:

  • annual outputs, one value per pixel or CFT/PFT specific (61 files)
  • monthly outputs (54 files)
  • daily outputs (43 files)

You find information in

  • source:trunk/include/conf.h listing the variables
  • source:trunk/par/outputvars.par giving the variables, units and description

File format of the main outputs

file namedata type[size]contentdata unit[scaled]dimensioncomment
general
grid.binshort [2 bytes]coordinatesdeg*1002(lon,lat)*grid cells
vegc.binfloat [4 bytes]vegetation carbon poolgC/m²c(grid cells, nyears)
litc.binfloat [4 bytes]litter carbon poolgC/m²c(grid cells, nyears)
soilc.binfloat [4 bytes]soil carbon poolgC/m²c(grid cells, nyears)
firec.binfloat [4 bytes]carbon released by firegC/m²c(grid cells, nyears)
mprec.binfloat [4 bytes]monthly precipitationmmc(grid cells, 12, nyears)valid for all output files starting with “m”
mnpp.binfloat [4 bytes]monthly net primary productiongC/m²c(grid cells, 12, nyears)
mrh.binfloat [4 bytes]monthly respirationgC/m²c(grid cells, 12, nyears)
natural vegetation
fpc.binfloat [4 bytes]foliage projected cover of natural vegetation in grid cell%c(ncell, ncft*2+91.band in (npft+1): total fraction of natural vegetation, 2. to last band: pfts follow in the order they occur in pft.par
firef.bin (?)float [4 bytes]fire return interval1/fraction of grid cell burned this year
agricultural vegetation
sdates.binshort [2 bytes]sowing datedayofyear [1:365]c(grid cells, 24, nyears)12 crops irrigated/rainfed
hdates.binshort [2 bytes]harvest datedayofyear [1:365]c(grid cells, 24, nyears)12 crops irrigated/rainfed
growing_period.binfloat [4 bytes]length of growing periodlength of growing period in daysc(grid cells, 28, nyears)(12 ncfts + grass) *2
pft_harvest.pft.binfloat [4 bytes]crop yieldgC/m²c(ncell, [[Cropsncft]]*2 , nyears)
pft_rharvest.pft.binfloat [4 bytes]crop residue yieldgC/m²c(ncell, ncft*2, nyears)cfts: rainfed/irrigated
pft_npp.binfloat [4 bytes]gC/m²c(ncell, ncft*2+9, nyears)cfts: rainfed/irrigated

all output files in plain binary (BSQ)

Grid-based vs. PFT-based

Some PFT/CFT-specific outputs (see list below for examples) are available as output per grid cell (grid-based) or per pft (pft-based). The grid-based output is internally multiplied with the stand fraction in a grid cell and will be generated if WITH_GRIDBASED is defined in lpjml.conf. If this line is not enabled (the default setting) the output will be pft_based. To convert back, multiply with stand_frac and cellarea.

  • pft_harvest
  • pft_npp
  • cft_nir
  • cft_airrig
  • cft_consump_water_g

How to handle output files

a) if lpj has been run in distributed mode, use output_bsq.ksh to join the output parts to one file
all following steps will be the same
b) creating a rectangular binary image from the output
use the program grd2bsq (call it with [-h] to get help)
don’t forget to use the output grid, not input grid … ;-)
c) see next point on how to read binary data

Reading binary files

- quite simple with any programming language, once you know how the data is stored (as described under point 8b, but see below for byte order issues)

- most image processing programs have an option to import binary data (but they usually need it in a rectangular grid, see point 9 b)

- R can read binary data. We now offer the lpjmlkit R package to help with reading both LPJmL input and output files. If you want to use lpjmlkit consider changing the output format from RAW to CLM in lpjml.conf/lpjml.js so that the necessary metadata about number of cells, number of bands etc. are included in files.

- ArcView / ArcGIS: they DO read binary input data, but the online help system will not tell you … You need to specify a header with data type, coordinates etc, there should be information on the web about the specifications for the version you are using. It seems to cause problems to read negative values, though.
- if you have problems importing binary data to the software you are using for analysis, you might need to write a program that converts the output data to ASCII (or use the respective function of a different software package)

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 - just bad luck - 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. Things get more complicated if you look at floating point data types: additionally to byte order issues the internal representation of the number might be different. You are on the safe side if you avoid reading binary floating point data from a different architecture. However, most systems seem to follow the IEEE floating point standard, so you might be lucky using the integer byte swapping functions.

Adding new output

In order to add new outputs, you’ll have to take care of several things. There are in principle 4 different output types available.

  • annual outputs per pixel
  • annual outputs per PFT/CFT
  • monthly outputs per pixel
  • daily outputs per pixel for 1 single CFT

There are currently 158 different outputs defined in LPJmL, see include/conf.h. Additional output — even if not written away during the run, will increase the memory requirements of the model. Please consider this, when adding new outputs. You can search the code for existing outputs (e.g. ‘MIRRIG’ AND ‘mirrig’) and use this as a guideline. Unless you plan to implement a new type of output, you can copy/paste existing structures and functions.

  • Create a unique identifier in include/conf.h
    (!) Daily outputs need to be IN BETWEEN D_LAI and D_PET. Keep order as in include/output.h
  • Increment NOUT in include/conf.h by the number of new outputs created
  • Define units, scale, description of new output in outputvars.par
  • Add new elements to the structure Output in include/output.h
    (!) Monthly outputs need to be added to the structure Output and also to the structure Outputmonth.
    (!) Daily outputs have to be added to the structure Daily_outputs only, they need to be IN BETWEEN D_LAI and D_PET
    (!) Daily outputs should be in the order of daily output identifiers in include/conf.h
  • Add output variable (including: id, name, variable(NetCDF), description, unit, scale) to list of files in par/outputvars.par
    (!) Daily outputs should be in the same order as in include/conf.h and include/output.h.
  • For PFT/CFT-specific outputs: allocate memory to element in src/lpj/initoutput.c
  • For PFT/CFT-specific outputs: free memory of element in src/lpj/freeoutput.c
  • Initialize new output elements in corresponding init function (e.g. initoutput_monthly.c)
  • MONTHLY outputs only: Add output identifier to function that checks type of output (i.e. src/lpj/ismonthlyoutput.c)
  • MONTHLY outputs only: Add new output structure element(s) to function that allocates memory: src/lpj/newoutputmonthly.c
  • Add output identifier to src/lpj/outputbuffersize.c (mind the correct position!)
  • Write away output in corresponding fwriteoutput_* function (e.g. fwriteoutput_monthly.c & fwriteoutput_monthly2.c)
    (!) There are 2 functions for monthly and daily outputs, both are needed (one for with river routing, the other for without)
  • Fill output structure with values wanted at the appropriate place in the code. Pay attention to the difference between + and += and that the output works for all options (e.g. with and without river routing) and land use types.
  • MONTHLY outputs only: add new output to src/lpj/update_outputmonthly.c and free output memory after it is written to file at end of year in src/lpj/freeoutputmonthly.c
  • Finally, call new output variable in lpjml.conf in order to write it to file

Clone this wiki locally

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode"); } } catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); } })(); })();
Skip to content
Sebastian Ostberg edited this page Jul 21, 2023 · 3 revisions

Output

[[TOC]]

Output files

There are three different types of output files:

  • annual outputs, one value per pixel or CFT/PFT specific (61 files)
  • monthly outputs (54 files)
  • daily outputs (43 files)

You find information in

  • source:trunk/include/conf.h listing the variables
  • source:trunk/par/outputvars.par giving the variables, units and description

File format of the main outputs

file namedata type[size]contentdata unit[scaled]dimensioncomment
general
grid.binshort [2 bytes]coordinatesdeg*1002(lon,lat)*grid cells
vegc.binfloat [4 bytes]vegetation carbon poolgC/m²c(grid cells, nyears)
litc.binfloat [4 bytes]litter carbon poolgC/m²c(grid cells, nyears)
soilc.binfloat [4 bytes]soil carbon poolgC/m²c(grid cells, nyears)
firec.binfloat [4 bytes]carbon released by firegC/m²c(grid cells, nyears)
mprec.binfloat [4 bytes]monthly precipitationmmc(grid cells, 12, nyears)valid for all output files starting with “m”
mnpp.binfloat [4 bytes]monthly net primary productiongC/m²c(grid cells, 12, nyears)
mrh.binfloat [4 bytes]monthly respirationgC/m²c(grid cells, 12, nyears)
natural vegetation
fpc.binfloat [4 bytes]foliage projected cover of natural vegetation in grid cell%c(ncell, ncft*2+91.band in (npft+1): total fraction of natural vegetation, 2. to last band: pfts follow in the order they occur in pft.par
firef.bin (?)float [4 bytes]fire return interval1/fraction of grid cell burned this year
agricultural vegetation
sdates.binshort [2 bytes]sowing datedayofyear [1:365]c(grid cells, 24, nyears)12 crops irrigated/rainfed
hdates.binshort [2 bytes]harvest datedayofyear [1:365]c(grid cells, 24, nyears)12 crops irrigated/rainfed
growing_period.binfloat [4 bytes]length of growing periodlength of growing period in daysc(grid cells, 28, nyears)(12 ncfts + grass) *2
pft_harvest.pft.binfloat [4 bytes]crop yieldgC/m²c(ncell, [[Cropsncft]]*2 , nyears)
pft_rharvest.pft.binfloat [4 bytes]crop residue yieldgC/m²c(ncell, ncft*2, nyears)cfts: rainfed/irrigated
pft_npp.binfloat [4 bytes]gC/m²c(ncell, ncft*2+9, nyears)cfts: rainfed/irrigated

all output files in plain binary (BSQ)

Grid-based vs. PFT-based

Some PFT/CFT-specific outputs (see list below for examples) are available as output per grid cell (grid-based) or per pft (pft-based). The grid-based output is internally multiplied with the stand fraction in a grid cell and will be generated if WITH_GRIDBASED is defined in lpjml.conf. If this line is not enabled (the default setting) the output will be pft_based. To convert back, multiply with stand_frac and cellarea.

  • pft_harvest
  • pft_npp
  • cft_nir
  • cft_airrig
  • cft_consump_water_g

How to handle output files

a) if lpj has been run in distributed mode, use output_bsq.ksh to join the output parts to one file
all following steps will be the same
b) creating a rectangular binary image from the output
use the program grd2bsq (call it with [-h] to get help)
don’t forget to use the output grid, not input grid … ;-)
c) see next point on how to read binary data

Reading binary files

- quite simple with any programming language, once you know how the data is stored (as described under point 8b, but see below for byte order issues)

- most image processing programs have an option to import binary data (but they usually need it in a rectangular grid, see point 9 b)

- R can read binary data. We now offer the lpjmlkit R package to help with reading both LPJmL input and output files. If you want to use lpjmlkit consider changing the output format from RAW to CLM in lpjml.conf/lpjml.js so that the necessary metadata about number of cells, number of bands etc. are included in files.

- ArcView / ArcGIS: they DO read binary input data, but the online help system will not tell you … You need to specify a header with data type, coordinates etc, there should be information on the web about the specifications for the version you are using. It seems to cause problems to read negative values, though.
- if you have problems importing binary data to the software you are using for analysis, you might need to write a program that converts the output data to ASCII (or use the respective function of a different software package)

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 - just bad luck - 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. Things get more complicated if you look at floating point data types: additionally to byte order issues the internal representation of the number might be different. You are on the safe side if you avoid reading binary floating point data from a different architecture. However, most systems seem to follow the IEEE floating point standard, so you might be lucky using the integer byte swapping functions.

Adding new output

In order to add new outputs, you’ll have to take care of several things. There are in principle 4 different output types available.

  • annual outputs per pixel
  • annual outputs per PFT/CFT
  • monthly outputs per pixel
  • daily outputs per pixel for 1 single CFT

There are currently 158 different outputs defined in LPJmL, see include/conf.h. Additional output — even if not written away during the run, will increase the memory requirements of the model. Please consider this, when adding new outputs. You can search the code for existing outputs (e.g. ‘MIRRIG’ AND ‘mirrig’) and use this as a guideline. Unless you plan to implement a new type of output, you can copy/paste existing structures and functions.

  • Create a unique identifier in include/conf.h
    (!) Daily outputs need to be IN BETWEEN D_LAI and D_PET. Keep order as in include/output.h
  • Increment NOUT in include/conf.h by the number of new outputs created
  • Define units, scale, description of new output in outputvars.par
  • Add new elements to the structure Output in include/output.h
    (!) Monthly outputs need to be added to the structure Output and also to the structure Outputmonth.
    (!) Daily outputs have to be added to the structure Daily_outputs only, they need to be IN BETWEEN D_LAI and D_PET
    (!) Daily outputs should be in the order of daily output identifiers in include/conf.h
  • Add output variable (including: id, name, variable(NetCDF), description, unit, scale) to list of files in par/outputvars.par
    (!) Daily outputs should be in the same order as in include/conf.h and include/output.h.
  • For PFT/CFT-specific outputs: allocate memory to element in src/lpj/initoutput.c
  • For PFT/CFT-specific outputs: free memory of element in src/lpj/freeoutput.c
  • Initialize new output elements in corresponding init function (e.g. initoutput_monthly.c)
  • MONTHLY outputs only: Add output identifier to function that checks type of output (i.e. src/lpj/ismonthlyoutput.c)
  • MONTHLY outputs only: Add new output structure element(s) to function that allocates memory: src/lpj/newoutputmonthly.c
  • Add output identifier to src/lpj/outputbuffersize.c (mind the correct position!)
  • Write away output in corresponding fwriteoutput_* function (e.g. fwriteoutput_monthly.c & fwriteoutput_monthly2.c)
    (!) There are 2 functions for monthly and daily outputs, both are needed (one for with river routing, the other for without)
  • Fill output structure with values wanted at the appropriate place in the code. Pay attention to the difference between + and += and that the output works for all options (e.g. with and without river routing) and land use types.
  • MONTHLY outputs only: add new output to src/lpj/update_outputmonthly.c and free output memory after it is written to file at end of year in src/lpj/freeoutputmonthly.c
  • Finally, call new output variable in lpjml.conf in order to write it to file

Clone this wiki locally