Page 1 of 1

Unreliable estimates using 'derived' function

PostPosted: Sat Jul 25, 2020 6:40 am
by jchrpi
Hi all,

Just to give a proper background I will briefly explain what I am working on. I am running currently analysing the data from a project that aims to estimate lizard density on several sites, over a 5-month period. I have 14 sites (grouped in 3 main study areas), which I have visited twice per month (5 sessions, 2 occasions). Half of these sites correspond to capture locations within the area of an invasive predator, the other half are control sites. Within the invaded sites, I have an extremely low number of lizard captures. Therefore, to ensure model convergence I ran separate models for each area, indicating that each site was a separate session. To reduce computational burden, and work with 'closed' populations, I further subdivided data in sessions, so that I finally ran 3x5 models (for each study area and session combination). I ran all models maximizing conditional likelihood (CL=T) to save some time, and finally retrieved site-specific density using 'derived' function, and that's where my problem begins.

When I look at the estimates from derived function, I get some extremely odd results. Density looks like a really huge number (something like 9.402571e+15), whereas the esa is extremely small (3.349110e-08). At first glance, I thought this could mean that results are on the link scale and needed to be back-transformed. After that I started wondering if there could be any chance that the derived function changed the units (lizard/km^2, for instance). Another alternative (likely the most plausible) is that my model is wrong. After reading some papers I noticed secr models require a certain amount of recaptures to attain reliable results. I have 40-50 recaptures in the overall study, but after breaking up my dataset I am clearly below the safe minimum for secr models (10 recaptures per model). In spite of that, my CVD looks really good, with an average value of 9.02 for all models. Furthermore, when I run the models mximizing the full likelihood (CL=F) density estimates look much more decent (around 20 lizard/ha), although density in invaded sites is below zero, which is really weird. Right now I am struggling to understand whether the model is ok and I just missed something, or if should just migrate to non-spatial open-population models in openCR. Any feedback would be really helpful.

Thanks in advance!

Re: Unreliable estimates using 'derived' function

PostPosted: Tue Jul 28, 2020 4:55 pm
by murray.efford
Hi Julien
Sorry I didn't pick this up sooner - sometimes phidot fails to notify me of incoming messages.

It's hard to diagnose the problem and offer advice, but
-- If you are running out of recaptures then you can share information across units by modeling detection parameters as constant, or differing only with respect to the invasive/no invasive treatment (tip: specify a session covariate for this).
-- There is no way the relative SE (CV) should be that low if you have only 10 recaptures.
-- The estimated detection parameters(g0, lambda0, sigma) should be the same for CV=F, CV=T given a Poisson model for n (the default in 'secr'). If not then there is something wrong with one or other model fit.
It's always possible there is a bug in derived.secr(); make sure you have the latest version secr 4.3.0.
Murray

Re: Unreliable estimates using 'derived' function

PostPosted: Wed Jul 29, 2020 12:51 am
by murray.efford
Of course I meant CL=T, CL=F

Re: Unreliable estimates using 'derived' function

PostPosted: Thu Jul 30, 2020 9:33 am
by jchrpi
Hi Murray,

Thank you for your suggestions, I will try that. Just to clarify:

1) Should I model sharing detection parameters across sites maximizing conditional likelihood and extract density via 'derived' (provided the function is ok)?

2) Regardind CV(D), it looked rather suspicious to me considering the low capture rate I have, but I do not know if there is any mistake. Do I have to do anything with these numbers (e.g. multiply by 100 to make a percentage, etc.)?

3) I will take a look to that.

Again, thank you very much for your feedback. I'll let you know about my findings.

Julien

Re: Unreliable estimates using 'derived' function

PostPosted: Thu Jul 30, 2020 3:40 pm
by murray.efford
1) You can use CL = TRUE + derived() if you like, or CL = FALSE that includes density in the model. A model with session covariates for detection parameters works either way.
2) OK. The figures for CVD etc from derived() are not percentages, so yes, multiply by 100 to make a percentage.

Re: Unreliable estimates using 'derived' function

PostPosted: Sat Aug 08, 2020 2:23 pm
by jchrpi
Dear Murray,

Thank you very much for your help. I tried few days ago what you suggested and it apparently works. I must say though I have around 40% CV(D), which seems a bit much. Nonetheless, I assume that comes from the data. Any suggestion on this? Thank you again.

Julien

Re: Unreliable estimates using 'derived' function

PostPosted: Sat Aug 08, 2020 6:23 pm
by murray.efford
How many recaptures* r are there in your dataset? I'm guessing less than 10, which is definitely not enough. (Very roughly, RSE(D-hat) = 1/sqrt(r), and models are generally unstable with small r).

* difference between Detections and Animals in e.g., for multi-session data
Code: Select all
apply(summary (ovenCHp, terse = TRUE),1,sum)
# Occasions Detections    Animals  Detectors
#        49        215        103        220

Re: Unreliable estimates using 'derived' function

PostPosted: Mon Aug 31, 2020 9:51 am
by jchrpi
Hi Murray,

I was in the field, sorry I couldn't reply sooner. I have 43 recaptures, although most of these recaptures were made across sessions. When summarizing the dataset as you did in your message, only 10 appear. Is that a problem?

Julien

Re: Unreliable estimates using 'derived' function

PostPosted: Mon Aug 31, 2020 6:31 pm
by murray.efford
Unfortunately 'secr' is blind to recaptures between sessions, which leaves you with inadequate data for a closed population analysis. The alternative is an open population analysis, perhaps using 'openCR'. I'm not promising this will work, but it's worth a try.