Creating input landscapes in gen3sis
09.07.2020
This vignette aims at showing how to use the function create_input_landscape that creates input landscape objects necessary to run gen3sis. These objects are:
a rds file containing a landscape list of raster stacks for environmental variables;
a series of rds files, one for each time-step, including distance matrices between sites.
To create these files, the function requires as arguments:
a named list of environmental rasters containing layers for the different time steps, with each raster layer representing the spatial distribution of an environmental variable;
a cost function defining how dispersal between particular types of sites is penalized (to be used for the calculation of the distance matrices).
Below, we will generate the R objects required by the function create_input_landscape step by step. For this exercise, we will use the simple center of the world landscape that we used in the introduction vignette and in the main text of the package manuscript as case study 1.
The first step is to load the necessary packages and set the working directory:
# first we load the required packages
library(gen3sis)
library(raster)
# next we set the working directory to the package path
datapath <- system.file("extdata", package = "gen3sis")
setwd(datapath)
Creating the environmental data frames
In this step, the user needs to create the data frames containing the spatiotemporal distribution of the environmental variables of interest. Here, we will use the temperature, aridity and area rasters of the 4d sample world that has been used in the introduction vignette. We first load the three corresponding raster bricks from the hard drive.
temperature_brick <- brick("InputRasters/WorldCenter/temp_rasters.grd")
aridity_brick <- brick("InputRasters/WorldCenter/aridity_rasters.grd")
area_brick <- brick("InputRasters/WorldCenter/area_rasters.grd")
If you want to learn how you can create a virtual dynamic landscape from scratch, please refer to the design_landscape vignette.
Creating a list with the environmental data frames
To create the input landscape for gen3sis, all environmental variables have to be stored as raster files in a named list. It is important to add the name of the environmental variable you want to use in the list, which will be used when specifying the config file. Alternatively, you can also create a list which contains all of the raster file paths on your hard drive.
We will now create a list that contains all of the layers of our raster bricks for temperature, aridity and area.
landscapes_list <- list(temp = NULL, arid = NULL, area = NULL)
for (i in 1:nlayers(temperature_brick)) {
landscapes_list$temp <- c(landscapes_list$temp, temperature_brick[[i]])
landscapes_list$arid <- c(landscapes_list$arid, aridity_brick[[i]])
landscapes_list$area <- c(landscapes_list$area, area_brick[[i]])
}
Defining a cost function
The second argument we need to define is a cost function. This function should define the connection cost between sites. The species dispersal ability will determine if sites are reachable (i.e. if the dispersal event is higher than the connection cost).
First, let’s look at a very simple case, where no cost is added to the geographical distances, meaning that connections costs equal geographic distance. The costs have to be defined in meters because the coordinate system is in meters for real landscapes. Hence, we can define a simple cost function in which the dispersal is not penalized:
cost_function_null <- function(source, habitable_src, dest, habitable_dest) {
return(1)
}
Now, let’s look at a slightly more sophisticated cost function. Only sites which have environmental values (no NAs) are considered habitable. Here, suitable terrestrial sites should have a cost penalty of one dispersal, but dispersal over water sites should double the cost of dispersal.
cost_function_water <- function(source, habitable_src, dest, habitable_dest) {
if (!all(habitable_src, habitable_dest)) {
return(2)
} else {
return(1)
}
}
Whether a specific site can be reached or not depends on the properties of the population or species.
Further useful arguments
Besides the landscape list, the cost function and the experiment folder, we can define further arguments: directions, timesteps and calculate_full_distance_matrices.
The argument ‘directions’ requires an integer providing the amount of directions used to calculate distances. It can take 4, 8 or 16 as values to consider the four, eigth or 16 neighboring sites. This is the same homonimous argument used by the function transition in the gdistance package (gdistance::transition).
The argument ‘timesteps’ requires a vector of strings and is used to name the files and to name the timesteps in the .rds landscape object created by the create_input_landscape function. It is not necessary to define this argument, but it helps readibility when manipulating the object.
The argument ‘calculate_full_distance_matrices’ defines whether the create_input_landscape function will create one large distance matrix for all suitable sites (calculate_full_distance_matrices=TRUE) or a list of small distance matrices for the neigboring sites specified in ‘directions’ around each suitable site (calculate_full_distance_matrices=FALSE). The full distance matrix confers faster computing speed for the model, but requires a larger storage. The local distance matrices cause a slower computing speed, but require smaller storage. The slower speed emerges form the fact that a full distance matrix is then reconstructed by concatenating local distances matrices each timestep during a simulation run.
The real geographic coordinate system can be provided which allows for the global spherical distance correction. For real landscapes, the distance unit is in meters (m). If you would use hypothetical landscapes, such as in the design_landscape vignette, geographic distance would be measured in units of sites.
