Ewing's Quantitative Population Ethology
Before installing the package, you may want to examine the interactive Shiny app https://data-viz.it.wisc.edu/ewing/, which provides web access to this package.
Change one of the simulation values on the Shiny app, say number or hosts or parasites, or number of simulation steps. Then click on Start Simulation button to start a simulation. You can redo a simulation with the same settings, or change the settings.
To install, first do
install.packages("devtools")
If on Windows, you will then need to install Rtools from http://cran.r-project.org/bin/windows/Rtools. This is an executable that will install some applications in c:\Rtools. You will also need pdflatex, which means you need a TeX distribution such as MikTeX or TeX Live.
library(devtools)
install_github("byandell/ewing")
If you have pandoc
, you can install with vignette:
install_github("byandell/ewing", build_vignettes = TRUE)
See vignettes/ewing.Rmd for example use of code. A simple example is below:
library(ewing) # attach package
mysim <- init.simulation() # initialize simulation
simres <- future.events(mysim, plotit = FALSE) # simulate future events
plot(simres) # plot populations by stage or substrate over time
plot_current(simres, "host") # plot current (last) individuals over space
To change the number of initial individuals, do something like:
mysim <- init.simulation(count = c(200, 100))
will simulate 200 hosts and 100 parasites. You can also change the name of simulation file results from "sim.out" to something like "sim_200_100.out" to reflect the conditions of the simulation. Note that this file is written into the directory where you are using R.
simres <- future.events(mysim, "mysim_200_100.out", plotit = FALSE)
Here are some commands to use tidyverse
for newer plots:
library(tidyverse)
ggplot_ewing(simres)
ggplot_current(simres, "host")
For more information, visit http://www.stat.wisc.edu/~yandell/ewing
Reference: B Ewing, BS Yandell, JF Barbieri, and RF Luck (2002) "Event-driven competing risks," Ecological Modelling 158: 35--50. http://doi.org/10.1016/S0304-3800(02)00218-1
The object community
has several elements that contain the current state of a simulation. This object is updated at every simulation step, which then changes the future event structure. Past events are removed and cannot be recovered, except in the sense that each individual has their current state and anticipated future state recorded.
pop
matrices for each species
of information (rows) by individual (columns)get.species/put.species
and get.individual/put.individual
org
structure with information about organisms, including interactionsgetOrgInfo
, getOrgInteract
and other routinestemp
structure about degree-day and temperature patternscount
structure of summary countscpu
CPU time used for various activitiesFor some reason, I set up community$pop
entries for each species as matrices by row rather than column, with each column being an individual. It may be useful to flip it. The row names for each individual provide a complete picture of their current and next potential future state. It will take more digging to explain each of these row labels.
dist
left
, right
, up
leftist tree linksdispersion
location
intensity
truncation
rejection
pos.a
, pos.b
, pos.c
position on substrate in triangular coordinatestime
stage
current stagefuture
future stageoffspring
sex
sexsub.stage
current substratesub.future
future substrateAt each time step, the individual at the top of the leftist tree is examined, and actions may be taken. This typically involves a change in the leftist tree affecting just a few individuals. It might involve scheduling a future
event for that individual, a death
, one or more birth
events. Events are either monadic, involving only that individual, or dyadic, involving two individuals, such as a parasite ovipositing (preying) on a host. In the case of a dyadic event, both individuals have altered futures.
At each time step where there is a change in the population structure, totals are written out with writeCount
to a file, which can be read by readCount
for instance to create plots over time using ggplot_ewing
or plot_ewing
. This file loses the individual information, which is only maintained in the community
object at the current step. That is, there is temporal information without individual information.
It might be possible to store the updates as the simulation goes along in such a way that one could construct intermediate snapshots of the community. One interesting question is how to capture the spatial migration of individuals over the substrates (see ggplot_current
).
These datafiles are in the package directory ewing/data and are hard-wired into the code through calls in community.R file to internal function mydata
.
If the objects already exist, say by user supplying them, then the provided versions will be used.
However, this is tricky, as one cannot at present provide user versions to the shiny app. In the future, these will be adapted more robustly to user input.
The file redscale.txt is an initial attempt to adapt to redscale-aphytis system. See https://github.com/byandell/redscale for more ideas on this system.
The primary summary plot is plot.ewing
, or ggplot_ewing
, in plot.R
.
This gives a summary over the whole simulation.
However, other plot routines were created, some being interactive:
The init.simulation
and future.events
are the high level routines to initialize and run a simulation. They draw on default settings pulled from global datafiles.
Plan is to make this more adaptable, of course.
ewing_ageclass
and ewing_substrate
objectsget.future
init.simulation # starts simulation with default info
Initialize Organism Population
Create data structure with n organisms distributed across life stages.
Includes leftist tree structure.
Does various initializations based in information in future.xxx
,
where xxx
is replaced by the name of the dataset. Normally,
init.population
is called by init.simulation
.
init.population # initialize populations by species
initOffspring( community, species )
getOffspring( community, species, offspring )
getOrgFeature
getOrgHosts
getOrgInteract
getOrgFuture( community, species, feature, current, future )
getOrgAlive( community, species, element )
getOrgAgeClass( community, species, stage, future)
getOrgMeanValue( community, species )
get.offspring( community, species )
initOrgInfo()
setOrgInfo()
getOrgInfo()
initCount() # simulation count object administration
initTemp( community, lo.hour, hi.hour ) # creates Temperature object
getTemp( community, element, sub )
getCount( community, species, "mintime")
setCount( community, species, elements )
get.species( community, species )
put.species( community, species, value )
get.individual( community, species, id )
put.individual( community, species, individual, id )
get.base( community, species )
setTemp( community, element, value )
init.timing( community )
set.timing( community, string, flag )
activeTemp( community, lo.hour, hi.hour ) # updates Temperature object
showTemp( community )
getDegreeDay( community, hour )
temp.spline( community, hour, temp, start = 0, mintemp, cumulative = TRUE, mult )
break.backSpline( tmp )
checkTime( ) # check if activeTemp needs updating to cover time interval
getTime( community, species, x )
Realize future events in quantitative population ethology simulation
This is the main routine for Ewing's Quantitative Population Ethology. It steps through future events for individuals starting with the next minimum future event time. Steps through future events for community with one or more species. Keeps track of counts by age classes and substrates in external file.
The routine future.events
builds the name of the event processor
function based on event type, which is established in the future.host
or future.parasite
data structure. The event.attack
uses
further information from organism.features
about the type of parasite
(endo
or ecto
) in conjunction with the current event
(feed
or ovip
) to determine the nature of attack.
A plot is created periodically unless plotit=FALSE
. An external
file
is written with simulation counts for re-plotting.
future.events( community )
Process immediate, pending and future events in quantitative population ethology simulation.
Process an event for next individual in a species. Events may be monadic (one individual) or dyadic (involving two individuals). These are the main event processors for Ewing's Quantitative Population Ethology. They all take the same arguments, but handle events in quite different ways.
event.future
is the generic routine for monadic
future events, such as progressing through life stages.event.death
handles all pending events of death of individuals.event.birth
handles immediate events of new births. It assumes at
present one birth at a time, leading ultimately to a starved state.
The future.host
data has the gravid adult returning to the fertile state
until it depletes its resources. The pending event "starved" then triggers
the pending event "death".event.attack
is an example of a dyadic event processor, in this case
host-parasite interaction. The parasite locates a host based on life stages
and relative position in the simulation space. Ectoparasites kill their
hosts, hence realizing a pending death event (to be processed immediately by
event.death
in the next step). Endoparasites merely incapacitate
their hosts.At present, the search strategies of parasites and health consequences of
hosts are crude. However, search is over substrates and depends on the stage
of hosts. A crude sex determination strategy is in place, with smaller
(younger) hosts more likely to get male parasite eggs.
The external file community.out
is written with simulation counts
following each event that changes the number or stage of individuals.
User-supplied event.blah
functions can be specified in user-supplied
libraries. Note that user code needs to comply with the arguments and
values, and needs to process future events for individuals as they progress
through life. Further, user routines need to properly update counts to the
external file. This is at present an advanced topic, but can be figured out
by examining the above routines.
event.future(community, species) # process immediate, pending and future events
event.death(community, species, id)
get.future # Get birth and future event
set.birth( community, species, neworg )
update.mintime( object, species, ... )
event.birth(community, species)
event.attack(community, species) # Interaction Events (only attack for now)
set.future( community, species, stage )
get.birth( community, species, offspring )
get.deplete( community, species )
get.attack( community, species, individual )
event.parsed( community, species, host, found ) # created by get() of function
This function is dynamically created in multiple places
event.move( community, species, individual )
is.move( community, species, individual )
event.find( community, species, host, event )
updateCount( community, species, individual, is.death = FALSE, step )
rtri()
Add the following code to your website.
For more information on customizing the embed code, read Embedding Snippets.