Click on a question below to jump to the response.
• Why is it called the L-Range family of models?
The first model developed was called G-Range, for "Global Rangeland" model. As the name suggests, that model
was specifically applied to the entire world. Soon after, a version that could be run locally was created and
was called L-Range, for "Local Rangeland" model.
• How do I cite the L-Range family of models?
Please cite one or more of the papers that introduce the tools (e.g., Boone et al. (2018); Sircely et al. (2019))
when using the tools. An L-Range product that describes the tool is accepted for publication that may be cited (i.e., Boone et al., In press).
• When were the models created and where?
G-Range was created in the early-to-mid 2010s at Colorado State University in Fort Collins, Colorado, with support
from the International Livestock Research Institute and CCAFS.
The developers of Century kindly provided permission to include aspects of version 4 of that code in G-Range.
• What language are the L-Range family of models in?
FORTRAN 95, with syntax adjusted to accommodate the open-source Gnu FORTRAN compiler.
• Is the source code of G-Range and L-Range available?
Yes! The G-Range code is available from GitHub at rboone2020/g-range.
The L-Range code is also available from GitHub at rboone2020/l-range.
• How large may model applications be?
There is no limit to the size an L-Range application may be. The memory available on a computer may determine
the maximum size of a model. A large application may require that the dimension of the world be increased by adjusting
values for MAX_X_DIM and MAX_Y_DIM in the Parm_Vars_and_Vals.f95 file and the program recompiled using L_Make.bat or another
means. Large models may process slowly. To date the largest application to which we are aware includes 280,000 cells
simulated. That application requires about 20 minutes to simulate 5 years of dynamics on a third-generation AMD Threadripper
computer.
• Can there be multiple copies of the tools on a computer?
Yes. Multiple copies may be installed, each in a different folder. It is straightforward to install the software
on separate drives as well. Editing the G_Range.ini, L_Range.ini, or Af_Range.ini file in the corresponding "Bin"
folder (e.g., "G_Range_Bin") will point the program to the appropriate folder. For example, one may have an application
in "C:\L_Range" and "D:\L_Range". An application may also have multiple sites in the same L-Range folder, for example.
For example, one may have "D:\L_Range\L_Range_Site1" and "D:\L_Range\L_Range_Site2",
and editing the L_Range.ini file in the "Bin" folder will point the software to the desired site to be simulated.
• Will the software work on different systems?
Yes. The software should function on any common platform. G-Range and L-Range have been used on Windows, Macintosh,
and Linux systems. The models may require compilation for a given computer, however. An executable file for Windows
32-bit and 64-bit systems are distributed with G-Range, but they may not function on a given machine and a new
version may need to be compiled.
• Do the models run on multiple threads or processors?
Not at this time. The L-Range family of tools were designed to be simulated in a threaded fashion, with the main
looping structure designed to complete all procedures for a given landscape cell. Cells may then be processed in
groups by different threads.
Some compilers support straightforward adoption of threaded processing, as we understand. That option may be
persued by users. If you do have success, let us know!
• Why do the L-Range tools use binary output formats?
A binary format for output files is extremely compact and efficient for writing what can be very large files, with
potentially more than 100 data types produced every month as spatial layers in simulations. There are scientific
libraries that support compact data sharing (e.g., NetCDF, HDF) but data in those formats can be difficult to use; this
format has proved effective and straightforward. An exporting tool is available that converts the surfaces to GRIDASCII
format suitable for GIS analysis software. In addition, the logic may be incorporated into Python or R software for
custom extraction. See the "fill_array" procedure within the graphical user interface L_Range_GUI.py to see the
logic used to extract images.
• What is the GUI for the L-Range family?
The L_Range_GUI.py is a very simple Python Graphical User Interface that displays surfaces.
Click on the map in the GUI to create a graph of the change in a given location for the variable through time.
• Can G-Range or L-Range be joined with other models?
Yes! The tools - especially L-Range - are well suited to be joined with other tools. For example, L-Range has
been joined with several agent-based models that represent household decision making by pastoralists. L-Range
has been joined with the DECUMA model (Boone et al. 2011) to link ecosystem services simulated by L-Range to
the decision making by livestock owners in Kenya, and their decisions may in turn modify the ecosystem services
simulated by L-Range.
• What are the most common errors seen?
People often adopt long pathways to install a given model to (e.g., C:\Users\JaneDoe\Thesis_2023\Ecosystem_Model_Application\L_Range) and
those long paths may exceed the length allotted in the software. The fix to the error is likely straightforward, but it does
require adjustment. Instead, we recommend installing the software at the root of a drive (e.g., C:\L_Range).
A common (and embarrassing) problem is having the wrong multiplier on precipitation, minimum, and maximum temperature layers.
Producers of digital data often include a scaler on surfaces to store fractional (floating point) data in an efficient integer
format. In L-Range, precipitation is stored in mm but converted to cm in the code. Essentially precipitation is stored at 10 times
the cm units. The same is true for temperatures, with them stored at 10 times the actual temperature. When applying L-Range to
an area, use the GUI to look at the values for some landscape cells and ensure that reasonable temperatures and preciptiations are
shown. Recall that precipitation is monthly cm, and so may be summed to yield annual precipitation.
Also related to weather data, the L-Range family of models generate file names based on the month and year being simulated. A
prefix and suffix are provided to the files in "Sim_Parm.grg". A user may provide the prefix "p" and suffix "_1km.asc", and for
month May and year 2023, the software will look for the file "p202305_1km.asc" to read precipitation for that month.
Disagreements between the file name formed by L-Range and the names stored in the collection is a common error. Assuming
that the prefix and suffix are correctly indicated in "Sim_Parm.grg", it is most
straightforward to rename the weather data using a script to adopt the format expected by the software.
• Is training in the tools available?
No formal training session are planned at this time, but assistance is available.
Contact us for assistance.
