Fine-scale Data

[Jamie Kalla]

Hi Chris,

 

I’m a master’s student hoping to use ctmm for home range analysis in my thesis project.  I am interested in comparing the foraging home range size of several (14) different birds in different locations. The data was collected using an “encounternet” system, where an array of radio receivers tracks the tag signal on a bird and then each location fix is calculated from an algorithm afterwards. My data is more fine scale (5 second interval) than examples I’ve seen, so I’m wondering if the package is still appropriate for my data. Any guidance you could provide would be greatly appreciated. I have one additional question from what I’ve attempted so far:

• I don’t seem to be able to find a great fit using variogram.fit for my data. When I do save a reasonable looking fit to GUESS and create fitted models, the fine-scale graph is very off. Could a lack of error information cause that? Below I have included the manipulated variogram with GUESS values (red), and the OU fitted model (blue).

 

Thank you for your time!

 

Cheers,

Jamie

[Christen Fleming]

Hi Jamie,

When the present ctmm error models become very inappropriate for finely sampled data is when you start getting autocorrelation in the telemetry error. For GPS this happens somewhere in sub-second scale and is clearly visible in 60 Hz calibration data. I don't know where it happens for your data type, but if you have calibration data then you could look.

At 5 second intervals, you probably need an error model. Hopefully, your data comes with an error or HDOP column? Otherwise, you can try to fit homoscedastic errors. Your empirical variogram actually looks pretty good for the models presently in ctmm.

If your data is being collected approximately at 5 second intervals and not exactly 5 second intervals, you can also increase the res argument of variogram to clean up the empirical variogram at short lags.

Best,
Chris

[Jamie Kalla]

Hi Chris,

 

Thank you for taking the time to respond to my questions. I tried to implement some of your suggestions and have a couple follow-up questions:

1.  I misspoke earlier, as my data is in approximate 10 second intervals, with a couple seconds of variation. Because of this, I increased the res argument to res=10 in my variogram. I was wondering how the res value is determined? I just took a stab in the dark based on other discussions on this site. 
2. Unfortunately my data does not come with an error or HDOP column, so I tried to fit homoscedastic errors (although I need to still see if my data fits the assumptions for this). Firstly, I ran ctmm.select with the default variogram.fit values and errors=TRUE. The anisotropic OU model performed best:

> summary(fitted.mods)

                           dAICc DOF[mean]

OU anisotropic error     0.00000  37.88536

OU isotropic error      95.55237  37.93349

OUF isotropic error     97.56740  37.74227

 

> summary(OU)

$DOF

     mean      area

37.885361  2.540275

 

$CI

                              low        ML      high

area (hectares)         0.3198444  1.885281  4.811067

tau position (minutes)  0.0000000  3.190898 35.127284

error (meters)         11.2630561 15.289443 19.308351

 

I then I took the ML error value from the summary and then re-ran ctmm.select with GUESS$error= 15. When I try to plot the resulting OU model, I get some errors, and an odd looking plot. However my akde model runs no problem and seems to give a reasonable result:

Warning messages:

1: In stats::qchisq(Alpha/2, k, lower.tail = TRUE) : NaNs produced

2: In stats::qchisq(Alpha/2, k, lower.tail = TRUE) : NaNs produced

3: In stats::qchisq(Alpha/2, k, lower.tail = TRUE) : NaNs produced

I’m wondering if my approach here is correct, or if I’ve done something wrong to cause the graph errors. I sense that my problem is having a relatively high error for a small area, and no actual corresponding errors to correct with. 

Cheers,

Jamie

[Christen Fleming]

Hi Jamie,

The point estimate on that model-fit variogram looks very good. Can you try the GitHub version of ctmm and see if it fixes the confidence intervals? It has several related bug fixes.

The res option slices up the dt-width intervals res times before aggregating their individual semi-variances back together, kind of like a moving window on the lags. res=10 should be more than enough.

Best,
Chris

[Jamie Kalla]

Hi Chris,

I believe I've downloaded the GitHub version by this command in R:

library(devtools)

install_github("ctmm-initiative/ctmm")

Interestingly, when I change the res to 5 or change the error value, I no longer get the error on the variogram plot, but it looks not so great. Is this high variability to be expected by introducing an error value, or is it possible I'm experiencing some bug?

Thanks again,

Jamie

[Christen Fleming]

Hi Jamie,

I don't see a plot attached, just "Inline image 1", but the CI on your error parameter is fairly wide (10-20 meters), so you should expect the initial part of the variogram to go from zero uncertainty (without an error model included) to something proportional to (10-20 meters)^2 = 100-400 meters^2 (there's additionally a factor of sqrt(2) or something). As long as the point estimate still looks that good and the CIs reflect the uncertainty on the error parameter, then its probably okay. In older versions of ctmm, I don't think the variogram plots with error were fully coded to reflect that additional uncertainty (the error stuff is largely unpublished material for an upcoming paper and vignette).

Best,
Chris

[Jamie Kalla]

Hey Chris,

 

I think that the akde model I ran before must not have taken the properly fitted OU model into account because the CIs on the range estimation were so small. It also returns an error when I try to do summary(OU). This is the same bird on a different day with res=5, error=18.6 that did not return an error message, and it seems to have more appropriate CIs:

So it appears I’m getting errors in only some subsets of the data, but for the same res and error values. Here is my code and error message in case I’m doing something wrong there. I will try to re-install the package as well, in case it's something you've fixed but is not updated on my version. For the time being, I think fitting with the OU model without errors is at least better than not correcting any autocorrelation. Hopefully my explanation makes sense, thanks again for taking the time to look at this.

> telemetry1 <- as.telemetry(data1, timeformat = "%Y-%m-%d %H:%M:%S",

+                            timezone = "CEST", projection = CRS("+proj=utm +zone=31 +datum=WGS84"))

Maximum speed of 15.2 m/s observed in 011017707C

Minimum sampling interval of 5 seconds in 011017707C

> vg.1<-variogram(telemetry1, res=5)

> GUESS <- variogram.fit(vg.1, interactive = FALSE)

> GUESS$error=18.6

> fitted.mods<-ctmm.select(telemetry1,CTMM=GUESS, verbose=TRUE,level=1)  

Error in if (Q <= 0) { : missing value where TRUE/FALSE needed

In addition: Warning messages:

1: In sqrt(COV) : NaNs produced

2: In sqrt(COV/tau^4) : NaNs produced

3: In min(x) : no non-missing arguments to min; returning Inf

4: In max(x) : no non-missing arguments to max; returning -Inf

5: In sqrt(CTMM$COV[Q, Q]) : NaNs produced

Cheers,

Jamie

[Christen Fleming]

Hi Jamie,

Please message/email me the data and script if you are getting any errors with the GitHub version of the package. Your first individual should have wide confidence intervals on its home-range if you used the model fit with error (maybe not on the model fit without error). Also, there shouldn't be any problems with summary or ctmm.select.

Best,
Chris

[Christen Fleming]

Hi Jamie,

There were two issues working in combination: Your projection is half way around the world, which made my Kalman filter residual calculations more prone to numerical error. I fixed my code in the current 0.4.0 beta package to reduce this propensity for numerical error, but you should probably also choose a better projection. The SVF results look great now, even with the bad projection.

Best,
Chris

[Jamie Kalla]

Hey Chris,

Thank you so much for your help, I'll give the new code a shot! I'm using the projection that the coordinates were taken in, as I'm working in the Netherlands (unless I've made an error in my definitions). What would constitute a better projection?

Cheers,

Jamie

[Christen Fleming]

Hi Jamie,

A better projection would have the origin nearer to the animals.The default projection in ctmm does this in most cases, but rgdal wont let me preserve North. "aeqd" with "+lon_0=" the median longitude and "+lat_0=" the median latitude and "+datum=WGS84" is as good in most cases.

Just to let you know, I'm still hammering out new bugs in the new codebase, which I had to re-write to support some new features. If anything funny comes up, though please report it.

Best,
Chris

[Christen Fleming]

Hi Jamie,

I think I've fixed all of these new bugs now. Please tell me if something doesn't work right when using the latest Github version from a few minutes ago.

Best,
Chris

[Jamie Kalla]

Hey Chris,

 

Thanks again! I was experimenting with fitting different models yesterday and was able to set error=TRUE, but today I get the following warning:

Warning message:

In cov.loglike(hess, grad) : MLE is near a boundary or optim failed.

 

It seems to still work when I assign a set error value of 9.68 (which I got from my calibration data and the uere function).  The fit still seems good, but I had originally wanted to just set error=TRUE because error variation between my datasets seems high (different “nugget effects”). But it maybe it is better to just use the constant value. Also in terms of the projection, would a local projection such as Amersfoort New also provide more reliable results than UTM?

+proj=sterea +lat_0=52.15616055555555 +lon_0=5.38763888888889 +k=0.9999079 +x_0=155000 +y_0=463000 +ellps=bessel +towgs84=565.4171,50.3319,465.5524,1.9342,-1.6677,9.1019,4.0725 +units=m +no_defs

I haven’t worked with a custom projection before, and I’d like to keep the same projection for all my datasets.

Cheers,

Jamie

[Christen Fleming]

Hi Jamie,

I put that warning in recently. That message is probably warning you that you are trying to fit a model where the MLE of a parameter is zero. You can see if this is true with summary(). If your MLE is not near a boundary, you can run fit again from the best fit and see if any improvement is made. optim() sometimes has trouble with these more complicated models. Also, in these cases, ctmm.guess() can give you a better starting guess than variogram.fit(), because it estimates covariance eccentricity and orientation from the data.

So with the error fitting, setting GUESS$error=XX is just the initial guess and the precise value is estimated, which you can see from summary(). With variograms that are very discontinuous in the beginning, like yours, you can usually get a pretty good initial guess from the sliders. If you want fixed errors, then you need to give your CSV an HDOP column and run as.telemetry() with UERE=XX.

The error-modeling stuff you are using is not yet published (which is why these last bugs are being hammered out, with you guys being the beta testers). At the moment uere() on calibration data can give you a UERE point estimate to fix when running as.telemetry(), but in the future ctmm.fit() will use the full likelihood of the calibrated UERE as a prior, to take into account calibrated UERE uncertainty.

For projections, I am just familiar with a couple, like azimuthal equidistant, where you want the animal close to the origin where the projection becomes exact, and where "closeness" is relative to the scale of the Earth. I assume most others are similar. If UTM does not work this way, then I apologize and just ignore me.

Best,
Chris

[Jamie Kalla]

Hey Chris,

Thanks so much for the detailed explanation. I just want to make sure I’m interpreting and using the package correctly. When I look at the summary of my model which returned a warning, I don’t see any parameters that are 0 (area, tau, error, velocity). Though maybe I am getting the summary of the wrong thing? So far, I don’t get any warnings when I specific error=10, so maybe it’s just able to find a better fit with the initial guess rather than just error=TRUE?

It looks like most of the models are finding a decent fit by looking at the variograms (with a couple maybe having too high of an asymptote). I am curious though, because I am using ctmm.select to find the best model, sometimes it selects OU and sometimes its selects OUF. It seems that the OUF models tend to have a smaller area than OU, and I’m worried about this making my analysis inconsistent. Is there a way to just find a best fit for one type of model (only OU?). In general, my home range estimates seem to be quite conservative in relation to the point locations and quite small confidence intervals. I was just wondering if you think this makes sense and is all working correctly.

I’ve attached some of the output form my analysis. Each file is from one bird but multiple days (fitted models, home range plots, and model summaries). Thanks again for your help, and hopefully all these questions are also of use to you smoothing out the package!

Cheers,

Jamie

[Christen Fleming]

Hi Jamie,

If you get that warning, it could be that a parameter's MLE was zero or it could be that optim didn't find a solution. You can take the bad solution and use it as a guess to make optim try again, or you can try to start with a better initial guess. If this isn't the case, feel free to send me a minimal working example.

You don't want to use one model for all of your data. With different data qualities and different movement behaviors, different models will be appropriate. You get artificial scale dependency if you fix the model.

As far as smaller/larger areas, I would zoom the variograms out to see if there isn't some broader scale range shifting/expansion going on. That would be a more likely explanation.

The CIs for the AKDE summary and plot are with respect to the area's magnitude. They don't seem too small to me:

     low       ML     high
1779.107 2272.111 2824.495
3360.855 4343.486 5450.212
1816.775 2520.287 3337.144

Regarding the spread of the data, if your home ranges are 50-70 meters across and your telemetry error is 10-15 meters, then a fair bit less than 95% of the data will fall within the 95% contours of the location distribution because the telemetry error is a substantial contribution to the variance of the data.

Best,
Chris

[Jamie Kalla]

Hey Chris,

After taking the "bad solution" and re-entering it as a guess for fitting the model, I no longer get any warnings. Thanks so much for all of your detailed responses! I will let you know if I come across anything not working quite right.

Cheers,

Jamie

[Jamie Kalla]

Hi again Chris,

I have a bit of a follow-up question. We are interested in comparing the amount of space used (homerange size) by birds overnight (those that remain in relatively the same location vs. those maybe switching trees/locations). I am running into many convergence errors when trying to run the overnight analysis, which is not surprising because our number of fixes is drastically reduced when the bird is not moving. So I suspect the issue is just having a low number of location fixes spread out over inconsistent intervals, and a high amount of error (which I'm currently estimating with the model). I'm wondering if trying the analysis with a constant error (by setting UERE=XX) might be a sensible solution to help the model converge, or if you have any other suggestions?

Thanks again,

Jamie

[Christen Fleming]

Hi Jamie,

Fitting error & movement simultaneously is a last resort method. Fitting error & movement simultaneously with small amounts of data would not be something that I would trust.
Much better would be to take some calibration data, run it through the uere() function and then use that with as.telemetry(). Even salvaging some data from nesting/dead birds to use as calibration data (pooled together), would probably work better than nothing.

If you can, I would pool the night data for individuals together too, if you aren't, and assuming their range doesn't shift from night to night.

Best,
Chris

[Jamie Kalla]

Hey Chris,

Thanks for the advice. I'm still getting convergence errors using the eure setting, so I just wanted to confirm that I am doing it correctly: 

 #Set eure value when importing as telemetry. Data includes a "GPS.HDOP" column set to 1:

telemetry <- as.telemetry(data, timeformat = "%Y-%m-%d %H:%M:%S", 

                                 timezone = "CEST", projection = CRS(zone), UERE=9.68)

# initial guess with error set to true:

GUESS <- ctmm.guess(telemetry, interactive = FALSE, variogram = NULL)

GUESS$error <- TRUE

#fit models:

fitted.mods<-ctmm.select(telemetry,CTMM=GUESS, verbose=TRUE)

Cheers,

Jamie

[Christen Fleming]

Hi Jamie,

Looks good to me.

The warning can validly happen for two reason:
1) optim didn't finish finding the solution. You can test this by taking the output and fitting again, using it as a guess, and see if the estimate changes and the warning goes away.
2) The solution is near a boundary, which can permit odd shaped likelihood functions at the solution. You can check this with summary, seeing if some of the parameters like "tau velocity" are near zero. Usually when this happens, ctmm.select should select a model without that parameter, and the warning was for a non-selected model.

I will update the error message and man file to be more informative.

Best,
Chris