solar.model {tripEstimation} | R Documentation |
Function to create a solar model object for metropolis location sampler
Description
A solar model to manage likelihood functions, environmental masks and behavioural likelihood functions. There are several options for configuring the model, and this may be considered a template for any given model. The model function exists simply to make the object construction simple.
Usage
solar.model(segments, day, light,
proposal.x, proposal.z, mask.x, mask.z,
fix.release = TRUE, fix.recapture = TRUE,
calibration,
light.sigma = 7, k.sigma = 10,
behav = "speed", behav.dist = "gamma",
behav.mean, behav.sd,
proj.string = "+proj=longlat",
ekstrom = c(-5, 3, light.sigma),
ekstrom.limit = "light")
Arguments
segments |
vector identifying twilight segment |
day |
vector of date-times for each light level |
light |
vector of light levels |
proposal.x |
function from object managing X proposals |
proposal.z |
function from object managing Z proposals |
mask.x |
lookup function for X's against masks |
mask.z |
lookup function for Z's against masks |
fix.release |
logical - is the release point known? |
fix.recapture |
logical - is the recapture point known? |
calibration |
calibration function for predicted light level for solar elevation |
light.sigma |
variance for light data |
k.sigma |
variance for light attenuation |
behav |
model distributions to be used for behaviour - defaults to "speed" |
behav.dist |
distribution to be used for behaviour |
behav.mean |
mean for behavioural distribution |
behav.sd |
variance for behavioural distribution |
proj.string |
PROJ.4 string for coordinate system used |
ekstrom |
parameters to use for ekstrom limit - min elevation, max elevation, sigma for outside that range |
ekstrom.limit |
mode of ekstrom limit to impose - defaults to "light" |
Details
The vectors of segments
, day
and light
are expected to
be of the same length.
Fixed recapture and release points are treated specially for ease of sampling, but the sampling is written to be general for any fixed locations.
Behavioural models may be specified either as lognormal or log-gamma. By editing the
function created as logp.behavioural
this may be specified differently.
Transformation of coordinates is supported via a simple function that only performs coordinate
transforms if proj.string
is not longlat.
Value
proposal.x(x) - generates new proposals for the x from the current x. Generates all x at once.
proposal.z(z) - generates new proposals for the x from the current z. Generates all z at once.
mask.x(x) - mask function for the x. Simultaneously tests all x and returns a vector of booleans indicating which are acceptable.
mask.z(z) - mask function for the z. Simultaneously tests all z and returns a vector of booleans indicating which are acceptable.
logp.position(x) - Given the set of x, returns a vector that gives the contribution each x make to the log posterior based on position alone.
logp.behavourial(k,xa,z,xb) - Computes the contribution to the log posterior from the behavioural model on a subset of segments that make up the path. Here k is a vector of the segment numbers, where the segments pass from xa to z to xb, and the function returns the contribution to the log posterior from each segment. This is the only function expected to work with only a subset of the x and z.
start.x - suggested starting points for the x
start.z - suggested starting points for the z
The only function that must operate on a subset of the x/z is logp.behavourial. All the other functions operate on all x or z simultaneously, simplifying the implementation for the user.
Note that x can consist of several parameters, not just the locations, but we assume the first two components of each x specify the location. For example, in the light level models each x is (lon,lat,k) where k is the attenuation of the light level.
Some details of this implementation are not as nice as they could be. First, it would be better if did not calculate the contributions to the posterior for points the mask rejects. Also, it may be better to separate the specification of the functions that generate proposals from the other functions, so that we can tune the proposal distributions without re-generating the whole model specification.
Author(s)
Simon Wotherspoon and Michael Sumner