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 create 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. See rgdal for the underlying functionality.

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


[Package tripEstimation version 0.0-24 Index]