701 lines
32 KiB
Plaintext
701 lines
32 KiB
Plaintext
<!--
|
||
%\VignetteIndexEntry{vegan FAQ}
|
||
%\VignetteEngine{knitr::knitr}
|
||
%\VignetteEncoding{UTF-8}
|
||
-->
|
||
|
||
**vegan** FAQ
|
||
=============
|
||
|
||
This document contains answers to some of the most frequently asked
|
||
questions about R package **vegan**.
|
||
|
||
> This work is licensed under the Creative Commons Attribution 3.0
|
||
> License. To view a copy of this license, visit
|
||
> <https://creativecommons.org/licenses/by/3.0/> or send a letter to
|
||
> Creative Commons, 543 Howard Street, 5th Floor, San Francisco,
|
||
> California, 94105, USA.
|
||
>
|
||
> Copyright © 2008-2016 vegan development team
|
||
|
||
------------------------------------------------------------------------
|
||
|
||
Introduction
|
||
------------
|
||
|
||
------------------------------------------------------------------------
|
||
|
||
### What is **vegan**?
|
||
|
||
**Vegan** is an R package for community ecologists. It contains the most
|
||
popular methods of multivariate analysis needed in analysing ecological
|
||
communities, and tools for diversity analysis, and other potentially
|
||
useful functions. **Vegan** is not self-contained but it must be run
|
||
under R statistical environment, and it also depends on many other R
|
||
packages. **Vegan** is [free
|
||
software](https://www.gnu.org/philosophy/free-sw.html) and distributed
|
||
under [GPL2 license](https://www.gnu.org/licenses/gpl.html).
|
||
|
||
------------------------------------------------------------------------
|
||
|
||
### What is R?
|
||
|
||
R is a system for statistical computation and graphics. It consists of a
|
||
language plus a run-time environment with graphics, a debugger, access
|
||
to certain system functions, and the ability to run programs stored in
|
||
script files.
|
||
|
||
R has a home page at <https://www.R-project.org/>. It is [free
|
||
software](https://www.gnu.org/philosophy/free-sw.html) distributed under
|
||
a GNU-style [copyleft](https://www.gnu.org/copyleft/copyleft.html), and
|
||
an official part of the [GNU](https://www.gnu.org/) project (“GNU S”).
|
||
|
||
------------------------------------------------------------------------
|
||
|
||
### How to obtain **vegan** and R?
|
||
|
||
Both R and latest release version of **vegan** can be obtained through
|
||
[CRAN](https://cran.r-project.org). Unstable development version of
|
||
**vegan** can be obtained through
|
||
[GitHub](https://github.com/vegandevs/vegan). The github page gives
|
||
further instructions for obtaining and installing development versions
|
||
of **vegan**.
|
||
|
||
------------------------------------------------------------------------
|
||
|
||
### What R packages **vegan** depends on?
|
||
|
||
**Vegan** depends on the **permute** package which will provide advanced
|
||
and flexible permutation routines for **vegan**. The **permute** package
|
||
is developed together with **vegan** in
|
||
[GitHub](https://github.com/gavinsimpson/permute).
|
||
|
||
Some individual **vegan** functions depend on packages **MASS**,
|
||
**mgcv**, **parallel**, **cluster** and **lattice**. **Vegan**
|
||
dependence on **tcltk** is deprecated and will be removed in future
|
||
releases. These all are base or recommended R packages that should be
|
||
available in every R installation. **Vegan** declares these as
|
||
suggested or imported packages, and you can install **vegan** and use
|
||
most of its functions without these packages.
|
||
|
||
**Vegan** is accompanied with a supporting package **vegan3d** for
|
||
three-dimensional and dynamic plotting. The **vegan3d** package needs
|
||
**tcltk** and non-standard packages **rgl** and **scatterplot3d**.
|
||
|
||
------------------------------------------------------------------------
|
||
|
||
### What other packages are available for ecologists?
|
||
|
||
CRAN [Task Views](https://cran.r-project.org/web/views/) include
|
||
entries like `Environmetrics`, `Multivariate` and `Spatial` that
|
||
describe several useful packages and functions. If you install R package
|
||
**ctv**, you can inspect Task Views from your R session, and
|
||
automatically install sets of most important packages.
|
||
|
||
------------------------------------------------------------------------
|
||
|
||
### What other documentation is available for **vegan**?
|
||
|
||
**Vegan** is a fully documented R package with standard help pages.
|
||
These are the most authoritative sources of documentation (and as a
|
||
last resource you can use the force and the read the source, as
|
||
**vegan** is open source). **Vegan** package ships with other
|
||
documents which can be read with `browseVignettes("vegan")`
|
||
command. The documents included in the **vegan** package are
|
||
|
||
- **Vegan** `NEWS` that can be accessed via `news()` command.
|
||
- This document (`FAQ-vegan`).
|
||
- Short introduction to basic ordination methods in **vegan**
|
||
(`intro-vegan`).
|
||
- Introduction to diversity methods in **vegan**
|
||
(`diversity-vegan`).
|
||
- Discussion on design decisions in **vegan** (`decision-vegan`).
|
||
- Description of variance partition procedures in function `varpart`
|
||
(`partitioning`).
|
||
|
||
Web documents outside the package include:
|
||
|
||
- <https://github.com/vegandevs/vegan>: development page.
|
||
- <https://vegandevs.github.io/vegan/>: **vegan** homepage.
|
||
|
||
------------------------------------------------------------------------
|
||
|
||
### Is there a Graphical User Interface (GUI) for **vegan**?
|
||
|
||
Roeland Kindt has made package **BiodiversityR** which provides a GUI
|
||
for **vegan**. The package is available at
|
||
[CRAN](https://cran.r-project.org/package=BiodiversityR).
|
||
It is not a mere GUI for **vegan**, but adds some new functions and
|
||
complements **vegan** functions in order to provide a workbench for
|
||
biodiversity analysis. You can install **BiodiversityR** using
|
||
`install.packages("BiodiversityR")` or graphical package management menu
|
||
in R. The GUI works on Windows, MacOS X and Linux.
|
||
|
||
------------------------------------------------------------------------
|
||
|
||
### How to cite **vegan**?
|
||
|
||
Use command `citation("vegan")` in R to see the recommended citation to
|
||
be used in publications.
|
||
|
||
------------------------------------------------------------------------
|
||
|
||
### How to build **vegan** from sources?
|
||
|
||
In general, you do not need to build **vegan** from sources, but binary
|
||
builds of release versions are available through
|
||
[CRAN](https://cran.r-project.org/) for Windows and MacOS X. If you use
|
||
some other operating systems, you may have to use source packages.
|
||
**Vegan** is a standard R package, and can be built like instructed in R
|
||
documentation. **Vegan** contains source files in C and FORTRAN, and you
|
||
need appropriate compilers (which may need more work in Windows and
|
||
MacOS X).
|
||
|
||
------------------------------------------------------------------------
|
||
|
||
### Are there binaries for devel versions?
|
||
|
||
Binaries can be available from R Universe: see
|
||
<https://github.com/vegandevs/vegan> for instructions.
|
||
|
||
------------------------------------------------------------------------
|
||
|
||
### How to report a bug in **vegan**?
|
||
|
||
If you think you have found a bug in **vegan**, you should report it to
|
||
**vegan** maintainers or developers. The preferred forum to report bugs
|
||
is [GitHub](https://github.com/vegandevs/vegan/issues). The bug report
|
||
should be so detailed that the bug can be replicated and corrected.
|
||
Preferably, you should send an example that causes a bug. If it needs a
|
||
data set that is not available in R, you should send a minimal data set
|
||
as well. You also should paste the output or error message in your
|
||
message. You also should specify which version of **vegan** you used.
|
||
|
||
Bug reports are welcome: they are the only way to make **vegan**
|
||
non-buggy.
|
||
|
||
Please note that you shall not send bug reports to R mailing lists,
|
||
since **vegan** is not a standard R package.
|
||
|
||
------------------------------------------------------------------------
|
||
|
||
### Is it a bug or a feature?
|
||
|
||
It is not necessarily a bug if some function gives different results
|
||
than you expect: That may be a deliberate design decision. It may be
|
||
useful to check the documentation of the function to see what was the
|
||
intended behaviour. It may also happen that function has an argument to
|
||
switch the behaviour to match your expectation. For instance, function
|
||
`vegdist` always calculates quantitative indices (when this is
|
||
possible). If you expect it to calculate a binary index, you should use
|
||
argument `binary = TRUE`.
|
||
|
||
------------------------------------------------------------------------
|
||
|
||
### Can I contribute to **vegan**?
|
||
|
||
**Vegan** is dependent on user contribution. All feedback is welcome. If
|
||
you have problems with **vegan**, it may be as simple as incomplete
|
||
documentation, and we shall do our best to improve the documents.
|
||
|
||
Feature requests also are welcome, but they are not necessarily
|
||
fulfilled. A new feature will be added if it is easy to do and it looks
|
||
useful, or if you submit code.
|
||
|
||
If you can write code yourself, the best forum to contribute to vegan is
|
||
[GitHub](https://github.com/vegandevs/vegan).
|
||
|
||
------------------------------------------------------------------------
|
||
|
||
Ordination
|
||
----------
|
||
|
||
------------------------------------------------------------------------
|
||
|
||
### I have only numeric and positive data but **vegan** still complains
|
||
|
||
You are wrong! Computers are painfully pedantic, and if they find
|
||
non-numeric or negative data entries, you really have them. Check your
|
||
data! Most common reasons for non-numeric data are that row names were
|
||
read as a non-numeric variable instead of being used as row names (check
|
||
argument `row.names` in reading the data), or that the column names were
|
||
interpreted as data (check argument `header = TRUE` in reading the
|
||
data). Another common reason is that you had empty cells in your input
|
||
data, and these were interpreted as missing values.
|
||
|
||
------------------------------------------------------------------------
|
||
|
||
### Can I analyse binary or cover class data?
|
||
|
||
Yes. Most **vegan** methods can handle binary data or cover abundance
|
||
data. Most statistical tests are based on permutation, and do not make
|
||
distributional assumptions. There are some methods (mainly in diversity
|
||
analysis) that need count data. These methods check that input data are
|
||
integers, but they may be fooled by cover class data.
|
||
|
||
------------------------------------------------------------------------
|
||
|
||
### Why dissimilarities in **vegan** differ from other sources?
|
||
|
||
Most commonly the reason is that other software use presence–absence
|
||
data whereas **vegan** used quantitative data. Usually **vegan** indices
|
||
are quantitative, but you can use argument `binary = TRUE` to make them
|
||
presence–absence. However, the index name is the same in both cases,
|
||
although different names usually occur in literature. For instance,
|
||
Jaccard index actually refers to the binary index, but **vegan** uses
|
||
name `"jaccard"` for the quantitative index, too.
|
||
|
||
Another reason may be that indices indeed are defined differently,
|
||
because people use same names for different indices.
|
||
|
||
------------------------------------------------------------------------
|
||
|
||
### Why NMDS stress is sometimes 0.1 and sometimes 10?
|
||
|
||
Stress is a proportional measure of badness of fit. The proportions can
|
||
be expressed either as parts of one or as percents. Function `isoMDS`
|
||
(**MASS** package) uses percents, and function `monoMDS` (**vegan**
|
||
package) uses proportions, and therefore the same stress is 100 times
|
||
higher in `isoMDS`. The results of `goodness` function also depend on
|
||
the definition of stress, and the same `goodness` is 100 times higher in
|
||
`isoMDS` than in `monoMDS`. Both of these conventions are equally
|
||
correct.
|
||
|
||
------------------------------------------------------------------------
|
||
|
||
### I get zero stress but no repeated solutions in `metaMDS`
|
||
|
||
The first (try 0) run of `metaMDS` starts from the metric scaling
|
||
solution and is usually good, and most sofware only return that
|
||
solution. However, `metaMDS` tries to see if that standard solution
|
||
can be repeated, or improved and the improved solution still
|
||
repeated. In all cases, it will return the best solution found, and
|
||
there is no burning need to do anything if you get the message tha the
|
||
solution could not be repeated. If you are keen to know that the
|
||
solution really is the global optimum, you may follow the instructions
|
||
in the `metaMDS` help section "Results Could Not Be Repeated" and try
|
||
more.
|
||
|
||
Most common reason is that you have too few observations for your NMDS.
|
||
For `n` observations (points) and `k` dimensions you need to estimate
|
||
`n*k` parameters (ordination scores) using `n*(n-1)/2` dissimilarities.
|
||
For `k` dimensions you must have `n > 2*k + 1`, or for two dimensions at
|
||
least six points. In some degenerate situations you may need even a
|
||
larger number of points. If you have a lower number of points, you can
|
||
find an undefined number of perfect (stress is zero) but different
|
||
solutions. Conventional wisdom due to Kruskal is that you should have
|
||
`n > 4*k + 1` points for `k` dimensions. A typical symptom of
|
||
insufficient data is that you have (nearly) zero stress but no two
|
||
convergent solutions. In those cases you should reduce the number of
|
||
dimensions (`k`) and with very small data sets you should not use
|
||
`NMDS`, but rely on metric methods.
|
||
|
||
It seems that local and hybrid scaling with `monoMDS` have similar lower
|
||
limits in practice (although theoretically they could differ). However,
|
||
higher number of dimensions can be used in metric scaling, both with
|
||
`monoMDS` and in principal coordinates analysis (`cmdscale` in
|
||
**stats**, `wcmdscale` in **vegan**).
|
||
|
||
------------------------------------------------------------------------
|
||
|
||
### Zero dissimilarities in isoMDS
|
||
|
||
Function `metaMDS` uses function `monoMDS` as its default method for
|
||
NMDS, and this function can handle zero dissimilarities. Alternative
|
||
function `isoMDS` cannot handle zero dissimilarities. If you want to use
|
||
`isoMDS`, you can use argument `zerodist = "add"` in `metaMDS` to handle
|
||
zero dissimilarities. With this argument, zero dissimilarities are
|
||
replaced with a small positive value, and they can be handled in
|
||
`isoMDS`. This is a kluge, and some people do not like this. A more
|
||
principal solution is to remove duplicate sites using R command
|
||
`unique`. However, after some standardizations or with some
|
||
dissimilarity indices, originally non-unique sites can have zero
|
||
dissimilarity, and you have to resort to the kluge (or work harder with
|
||
your data). Usually it is better to use `monoMDS`.
|
||
|
||
------------------------------------------------------------------------
|
||
|
||
### I have heard that you cannot fit environmental vectors or surfaces to NMDS results which only have rank-order scores
|
||
|
||
Claims like this have indeed been at large in the Internet, but they are
|
||
based on grave misunderstanding and are plainly wrong. NMDS ordination
|
||
results are strictly metric, and in **vegan** `metaMDS` and `monoMDS`
|
||
they are even strictly Euclidean. The method is called “non-metric”
|
||
because the Euclidean distances in ordination space have a non-metric
|
||
rank-order relationship to community dissimilarities. You can inspect
|
||
this non-linear step curve using function `stressplot` in **vegan**.
|
||
Because the ordination scores are strictly Euclidean, it is correct to
|
||
use **vegan** functions `envfit` and `ordisurf` with NMDS results.
|
||
|
||
------------------------------------------------------------------------
|
||
|
||
### Where can I find numerical scores of ordination axes?
|
||
|
||
Normally you can use function `scores` to extract ordination scores for
|
||
any ordination method. The `scores` function can also find ordination
|
||
scores for many non-**vegan** functions such as for `prcomp` and
|
||
`princomp` and for some **ade4** functions.
|
||
|
||
In some cases the ordination result object stores raw scores, and the
|
||
axes are also scaled appropriate when you access them with `scores`. For
|
||
instance, in `cca` and `rda` the ordination object has only so-called
|
||
normalized scores, and they are scaled for ordination plots or for other
|
||
use when they are accessed with `scores`.
|
||
|
||
------------------------------------------------------------------------
|
||
|
||
### How the RDA results are scaled?
|
||
|
||
The scaling or RDA results indeed differ from most other software
|
||
packages. The scaling of RDA is such a complicated issue that it cannot
|
||
be explained in this FAQ, but it is explained in a separate pdf document
|
||
on “Design decision and implementation details in vegan” that you can
|
||
read with command `browseVignettes("vegan")`.
|
||
|
||
------------------------------------------------------------------------
|
||
|
||
### I cannot print and plot RDA results properly
|
||
|
||
If the RDA ordination results have a weird format or you cannot plot
|
||
them properly, you probably have a name clash with **klaR** package
|
||
which also has function `rda`, and the **klaR** `print`, `plot` or
|
||
`predict` functions are used for **vegan** RDA results. You can choose
|
||
between `rda` functions using `vegan::rda()` or `klaR::rda()`: you
|
||
will get obscure error messages if you use the wrong function. In
|
||
general, **vegan** should be able to work normally if **vegan** was
|
||
loaded after **klaR**, but if **klaR** was loaded later, its functions
|
||
will take precedence over **vegan**. Sometimes **vegan** namespace is
|
||
loaded automatically when restoring a previously stored workspace at
|
||
the start-up, and then **klaR** methods will always take precedence
|
||
over **vegan**. You should check your loaded packages. **klaR** may be
|
||
also loaded indirectly via other packages (in the reported cases it
|
||
was most often loaded via **agricolae** package). **Vegan** and
|
||
**klaR** both have the same function name (`rda`), and it may not be
|
||
possible to use these packages simultaneously, and the safest choice
|
||
is to unload one of the packages if only possible. See discussion in
|
||
[vegan github issues](https://github.com/vegandevs/vegan/issues/277).
|
||
|
||
------------------------------------------------------------------------
|
||
|
||
### Ordination fails with “Error in La.svd”
|
||
|
||
Constrained ordination (`cca`, `rda`, `dbrda`, `capscale`) will
|
||
sometimes fail with error message
|
||
`Error in La.svd(x, nu, nv): error code 1 from Lapack routine 'dgesdd'.`
|
||
|
||
It seems that the basic problem is in the `svd` function of `LAPACK`
|
||
that is used for numerical analysis in R. `LAPACK` is an external
|
||
library that is beyond the control of package developers and R core team
|
||
so that these problems may be unsolvable.
|
||
|
||
Reducing the range of constraints (environmental variables) helps
|
||
sometimes. For instance, multiplying constraints by a constant \< 1.
|
||
This rescaling does not influence the numerical results of constrained
|
||
ordination, but it can complicate further analyses when values of
|
||
constraints are needed, because the same scaling must be applied
|
||
there. The reports on the problems are getting rare and it may that
|
||
this problem is fixed in R and `LAPACK`.
|
||
|
||
------------------------------------------------------------------------
|
||
|
||
### Variance explained by ordination axes.
|
||
|
||
In general, **vegan** does not directly give any statistics on the
|
||
“variance explained” by ordination axes or by the constrained axes. This
|
||
is a design decision: I think this information is normally useless and
|
||
often misleading. In community ordination, the goal typically is not to
|
||
explain the variance, but to find the “gradients” or main trends in the
|
||
data. The “total variation” often is meaningless, and all proportions of
|
||
meaningless values also are meaningless. Often a better solution
|
||
explains a smaller part of “total variation”. For instance, in
|
||
unstandardized principal components analysis most of the variance is
|
||
generated by a small number of most abundant species, and they are easy
|
||
to “explain” because data really are not very multivariate. If you
|
||
standardize your data, all species are equally important. The first axes
|
||
explains much less of the “total variation”, but now they explain all
|
||
species equally, and results typically are much more useful for the
|
||
whole community. Correspondence analysis uses another measure of
|
||
variation (which is not variance), and again it typically explains a
|
||
“smaller proportion” than principal components but with a better result.
|
||
Detrended correspondence analysis and nonmetric multidimensional scaling
|
||
even do not try to “explain” the variation, but use other criteria. All
|
||
methods are incommensurable, and it is impossible to compare methods
|
||
using “explanation of variation”.
|
||
|
||
If you still want to get “explanation of variation” (or a deranged
|
||
editor requests that from you), it is possible to get this information
|
||
for some methods:
|
||
|
||
- Eigenvector methods: Functions `rda`, `cca`, `dbrda` and `capscale`
|
||
give the variation of conditional (partialled), constrained
|
||
(canonical) and residual components. Function `eigenvals` extracts
|
||
the eigenvalues, and `summary(eigenvals(ord))` reports the
|
||
proportions explained in the result object `ord`, and also works
|
||
with `decorana` and `wcmdscale`. Function `RsquareAdj` gives the
|
||
R-squared and adjusted R-squared (if available) for constrained
|
||
components. Function `goodness` gives the same statistics for
|
||
individual species or sites. In addition, there is a special
|
||
function `varpart` for unbiased partitioning of variance between up
|
||
to four separate components in redundancy analysis.
|
||
|
||
- Nonmetric multidimensional scaling. NMDS is a method for
|
||
nonlinear mapping, and the concept of of variation explained does
|
||
not make sense. However, 1 - stress\^2 transforms nonlinear stress
|
||
into quantity analogous to squared correlation coefficient. Function
|
||
`stressplot` displays the nonlinear fit and gives this statistic.
|
||
|
||
------------------------------------------------------------------------
|
||
|
||
### Can I have random effects in constrained ordination or in `adonis`?
|
||
|
||
No. Strictly speaking, this is impossible. However, you can define
|
||
models that respond to similar goals as random effects models, although
|
||
they strictly speaking use only fixed effects.
|
||
|
||
Constrained ordination functions `cca`, `rda` and `dbrda` can have
|
||
`Condition()` terms in their formula. The `Condition()` define partial
|
||
terms that are fitted before other constraints and can be used to remove
|
||
the effects of background variables, and their contribution to
|
||
decomposing inertia (variance) is reported separately. These partial
|
||
terms are often regarded as similar to random effects, but they are
|
||
still fitted in the same way as other terms and strictly speaking they
|
||
are fixed terms.
|
||
|
||
Function `adonis2` can evaluate terms sequentially. In a model with
|
||
right-hand-side `~ A + B` the effects of `A` are evaluated first, and
|
||
the effects of `B` after removing the effects of `A`. Sequential tests
|
||
are also available in `anova` function for constrained ordination
|
||
results by setting argument `by = "term"`. In this way, the first terms
|
||
can serve in a similar role as random effects, although they are fitted
|
||
in the same way as all other terms, and strictly speaking they are fixed
|
||
terms.
|
||
|
||
All permutation tests in **vegan** are based on the **permute** package
|
||
that allows constructing various restricted permutation schemes. For
|
||
instance, you can set levels of `plots` or `blocks` for a factor
|
||
regarded as a random term.
|
||
|
||
A major reason why real random effects models are impossible in most
|
||
**vegan** functions is that their tests are based on the permutation of
|
||
the data. The data are given, that is fixed, and therefore permutation
|
||
tests are basically tests of fixed terms on fixed data. Random effect
|
||
terms would require permutations of data with a random component instead
|
||
of the given, fixed data, and such tests are not available in **vegan**.
|
||
|
||
------------------------------------------------------------------------
|
||
|
||
### Is it possible to have passive points in ordination?
|
||
|
||
**Vegan** does not have a concept of passive points, or a point that
|
||
should only little influence the ordination results. However, you can
|
||
add points to eigenvector methods using `predict` functions with
|
||
`newdata`. You can first perform an ordination without some species or
|
||
sites, and then you can find scores for all points using your complete
|
||
data as `newdata`. The `predict` functions are available for basic
|
||
eigenvector methods in **vegan** (`cca`, `rda`, `decorana`, for an
|
||
up-to-date list, use command `methods("predict")`).
|
||
|
||
------------------------------------------------------------------------
|
||
|
||
### Class variables and dummies
|
||
|
||
You should define a class variable as an R `factor`, and **vegan** will
|
||
automatically handle them.
|
||
|
||
R (and **vegan**) knows both unordered and ordered factors. Unordered
|
||
factors are internally coded as dummy variables, but one redundant level
|
||
is removed or aliased. With default contrasts, the removed level is the
|
||
first one. Ordered factors are expressed as polynomial contrasts. Both
|
||
of these contrasts explained in standard R documentation.
|
||
|
||
------------------------------------------------------------------------
|
||
|
||
### How are environmental arrows scaled?
|
||
|
||
The printed output of `envfit` gives the direction cosines which are the
|
||
coordinates of unit length arrows. For plotting, these are scaled by
|
||
their correlation (square roots of column `r2`). You can see the scaled
|
||
lengths of `envfit` arrows using command `scores`.
|
||
|
||
The scaled environmental vectors from `envfit` and the arrows for
|
||
continuous environmental variables in constrained ordination (`cca`,
|
||
`rda`, `dbrda`) are adjusted to fill the current graph. The lengths
|
||
of arrows do not have fixed meaning with respect to the points (species,
|
||
sites), but they can only compared against each other, and therefore
|
||
only their relative lengths are important.
|
||
|
||
If you want change the scaling of the arrows, you can use `text`
|
||
(plotting arrows and text) or `points` (plotting only arrows) functions
|
||
for constrained ordination. These functions have argument `arrow.mul`
|
||
which sets the multiplier. The `plot` function for `envfit` also has the
|
||
`arrow.mul` argument to set the arrow multiplier. If you save the
|
||
invisible result of the constrained ordination `plot` command, you can
|
||
see the value of the currently used `arrow.mul` which is saved as an
|
||
attribute of `biplot` scores.
|
||
|
||
Function `ordiArrowMul` is used to find the scaling for the current
|
||
plot. You can use this function to see how arrows would be scaled:
|
||
|
||
|
||
```{r eval=FALSE}
|
||
sol <- cca(varespec)
|
||
ef <- envfit(sol ~ ., varechem)
|
||
plot(sol)
|
||
ordiArrowMul(scores(ef, display="vectors"))
|
||
```
|
||
|
||
------------------------------------------------------------------------
|
||
|
||
### I want to use Helmert or sum contrasts
|
||
|
||
`vegan` uses standard R utilities for defining contrasts. The default in
|
||
standard installations is to use treatment contrasts, but you can change
|
||
the behaviour globally setting `options` or locally by using keyword
|
||
`contrasts`. Please check the R help pages and user manuals for details.
|
||
|
||
------------------------------------------------------------------------
|
||
|
||
### What are aliased variables and how to see them?
|
||
|
||
Aliased variable has no information because it can be expressed with the
|
||
help of other variables. Such variables are automatically removed in
|
||
constrained ordination in **vegan**. The aliased variables can be
|
||
redundant levels of factors or whole variables.
|
||
|
||
**Vegan** function `alias` gives the defining equations for aliased
|
||
variables. If you only want to see the names of aliased variables or
|
||
levels in solution `sol`, use `alias(sol, names.only=TRUE)`.
|
||
|
||
------------------------------------------------------------------------
|
||
|
||
### Plotting aliased variables
|
||
|
||
You can fit vectors or class centroids for aliased variables using
|
||
`envfit` function. The `envfit` function uses weighted fitting, and the
|
||
fitted vectors are identical to the vectors in correspondence analysis.
|
||
|
||
------------------------------------------------------------------------
|
||
|
||
### Restricted permutations in **vegan**
|
||
|
||
**Vegan** uses **permute** package in all its permutation tests. The
|
||
**permute** package will allow restricted permutation designs for time
|
||
series, line transects, spatial grids and blocking factors. The
|
||
construction of restricted permutation schemes is explained in the
|
||
manual page `permutations` in **vegan** and in the documentation of the
|
||
**permute** package.
|
||
|
||
------------------------------------------------------------------------
|
||
|
||
### How to use different plotting symbols in ordination graphics?
|
||
|
||
The default ordination `plot` function is intended for fast plotting and
|
||
it is not very configurable. To use different plotting symbols, you
|
||
should first create and empty ordination plot with
|
||
`plot(..., type="n")`, and then add `points` or `text` to the created
|
||
empty frame (here `...` means other arguments you want to give to your
|
||
`plot` command). The `points` and `text` commands are fully
|
||
configurable, and allow different plotting symbols and characters.
|
||
|
||
------------------------------------------------------------------------
|
||
|
||
### How to avoid cluttered ordination graphs?
|
||
|
||
If there is a really high number of species or sites, the graphs often
|
||
are congested and many labels are overwritten. It may be impossible to
|
||
have complete readable graphics with some data sets. Below we give a
|
||
brief overview of tricks you can use. Gavin Simpson’s blog [From the
|
||
bottom of the heap](https://fromthebottomoftheheap.net) has a series
|
||
of articles on “decluttering ordination plots” with more detailed
|
||
discussion and examples.
|
||
|
||
- Use only points, possibly with different types if you do not need to
|
||
see the labels. You may need to first create an empty plot using
|
||
`plot(..., type="n")`, if you are not satisfied with the default
|
||
graph. (Here and below `...` means other arguments you want to give
|
||
to your `plot` command.)
|
||
- Use points and add labels to desired points using interactive
|
||
`identify` command if you do not need to see all labels.
|
||
- Add labels using function `ordilabel` which uses non-transparent
|
||
background to the text. The labels still shadow each other, but the
|
||
uppermost labels are readable. Argument `priority` will help in
|
||
displaying the most interesting labels (see [Decluttering blog, part
|
||
1](https://fromthebottomoftheheap.net/2013/01/12/decluttering-ordination-plots-in-vegan-part-1-ordilabel/)).
|
||
- Use `orditorp` function that uses labels only if these can be added
|
||
to a graph without overwriting other labels, and points otherwise,
|
||
if you do not need to see all labels. You must first create an empty
|
||
plot using `plot(..., type="n")`, and then add labels or points with
|
||
`orditorp` (see [Decluttering
|
||
blog](https://fromthebottomoftheheap.net/2013/01/13/decluttering-ordination-plots-in-vegan-part-2-orditorp/)).
|
||
- Use `ordipointlabel` which uses points and text labels to the
|
||
points, and tries to optimize the location of the text to minimize
|
||
the overlap (see [Decluttering
|
||
blog](https://fromthebottomoftheheap.net/2013/06/27/decluttering-ordination-plots-in-vegan-part-3-ordipointlabel/)).
|
||
- Ordination `text` and `points` functions have argument `select` that
|
||
can be used for full control of selecting items plotted as text or
|
||
points.
|
||
- Use interactive `orditkplot` function (**vegan3d** package)
|
||
that lets you drag labels of points to better positions if you need to see
|
||
all labels. Only one set of points can be used
|
||
(see [Decluttering blog](https://fromthebottomoftheheap.net/2013/12/31/decluttering-ordination-in-vegan-part-4-orditkplot/)).
|
||
- Most `plot` functions allow you to zoom to a part of the graph using
|
||
`xlim` and `ylim` arguments to reduce clutter in congested areas.
|
||
|
||
------------------------------------------------------------------------
|
||
|
||
### Can I flip an axis in ordination diagram?
|
||
|
||
Use `xlim` or `ylim` with flipped limits. If you have model
|
||
`mod <- cca(dune)` you can flip the first axis with
|
||
`plot(mod, xlim = c(3, -2))`.
|
||
|
||
------------------------------------------------------------------------
|
||
|
||
### Can I zoom into an ordination plot?
|
||
|
||
You can use `xlim` and `ylim` arguments in `plot` or `ordiplot` to zoom
|
||
into ordination diagrams. Normally you must set both `xlim` and `ylim`
|
||
because ordination plots will keep the equal aspect ratio of axes, and
|
||
they will fill the graph so that the longer axis will fit.
|
||
|
||
Dynamic zooming can be done with function `orditkplot` in CRAN package
|
||
**vegan3d**. You can directly save the edited `orditkplot` graph in
|
||
various graphic formats, or you can export the graph object back to R
|
||
session and use `plot` to display the results.
|
||
|
||
------------------------------------------------------------------------
|
||
|
||
Other analysis methods
|
||
----------------------
|
||
|
||
------------------------------------------------------------------------
|
||
|
||
### Is there TWINSPAN?
|
||
|
||
TWINSPAN for R is available in
|
||
[github](https://github.com/jarioksa/twinspan).
|
||
|
||
------------------------------------------------------------------------
|
||
|
||
### Why restricted permutation does not influence adonis results?
|
||
|
||
The permutation scheme influences the permutation distribution of the
|
||
statistics and probably the significance levels, but does not influence
|
||
the calculation of the statistics.
|
||
|
||
------------------------------------------------------------------------
|
||
|
||
### How is deviance calculated?
|
||
|
||
Some **vegan** functions, such as `radfit` use base R facility of
|
||
`family` in maximum likelihood estimation. This allows use of several
|
||
alternative error distributions, among them `"poisson"` and
|
||
`"gaussian"`. The R `family` also defines the deviance. You can see the
|
||
equations for deviance with commands like `poisson()$dev` or
|
||
`gaussian()$dev`.
|
||
|
||
In general, deviance is 2 times log.likelihood shifted so that models
|
||
with exact fit have zero deviance.
|
||
|
||
------------------------------------------------------------------------
|