compute_network_measures_using_bipartite_package: Compute bipartite network measures using bipartite package

In langfob/bdpg: Package For Building and Testing Biodiversity Problem Generators

Compute bipartite network measures using bipartite package

Description

The bdpg package computes bipartite measures over the PU/spp network in two ways, one using the igraph package and the other using the bipartite package. This function computes values using the bipartite package.

Usage

compute_network_measures_using_bipartite_package(
  rsprob,
  exp_root_dir,
  bipartite_metrics_to_use,
  write_to_disk = TRUE
)

Arguments

rsprob	a reserve selection problem object, e.g., a Xu_bd_problem
exp_root_dir	character string path to root directory of an experiment, usually parameters$fullOutputDir_NO_slash
bipartite_metrics_to_use	character string
write_to_disk	boolean flag indicating whether metrics should be written to disk before being returned; TRUE implies write to disk, FALSE implies not

Value

Returns bipartite_metrics_from_bipartite_package

Cautions about metric name confusion

The bipartite package looks at bipartite networks through the lens of plant-pollinator or parasitoid-prey networks. Specifically, in the bipartite documentation, it breaks a web into 2 groups as follows:

"Web is a matrix representing the interactions observed between higher trophic level species (columns) and lower trophic level species (rows). Usually this will be number of pollinators on each species of plants or number of parasitoids on each species of prey."

• HL=PUs=columns

• LL=Spp=rows

• species=PUsAndSpp

This means that measures coming out of the bipartite package are named as if the graph was a plant-pollinator network. This, in turn, means that some metric names need to be re-interpreted for the reserve selection problem.

In bdpg, species are rows and planning units are columns, i.e., in bdpg, planning units correspond to the higher trophic level species and reserve selection "species" correspond to bipartite lower trophic level species. For example, when bipartite says something like "number of species", that means the total number of both plants and pollinators together (i.e., both groups/levels in the network, since plants and pollinators are both species. In the reserve selection problem, that means the total number of both planning units and species together, rather than just the species involved in the reserve selection problem.

Choice of metrics vs. speed of computation

Information about which indices are slow is taken from the R documentation for the networklevel function in the bipartite package in its section called "Reducting computation time". Here is that section to help understand the choices made in the compute_network_measures_using_bipartite_package() function.

Reducing computation time

Some indices require rather long computation times on large webs. If you want to increase the speed by omitting some indices, here a rough guide: Ask only for the indices you are interested in! Otherwise, here is the sequence of most time-consuming indices:

1. The slowest function is related to extinction slopes and robustness. Excluding both makes the function faster.

2. weighted cluster coefficient is also very time consuming (an exhaustive search for 4-loops in the one-mode projection of the network). Omitting it can dramatically boost speed.

3. Degree distributions are somewhat time consuming.

4. Fisher's alpha is computed iteratively and hence time consuming.

5. Nestedness and weighted nestedness are not the fastest of routines.

6. Number (and diversity) of compartments calls a recursive and hence relatively slow algorithm.

7. H2 and specialisation asymmetry require an iterative, heuristic search algorithm. Finally, excluding discrepancy can also moderately decrease computation time.

langfob/bdpg documentation built on Dec. 8, 2022, 5:33 a.m.