input starting values

[mgreg]

Hello,

I'm running multi-session models (described in my last post) with high levels of variation between sessions (near trap saturation in summer, very low densities in winter) and need to include starting values. I've tried using a previously fitted model but always recieve the error message

Error: length(start) == NP is not TRUE

I then moved on to trying the starting values as an object. I used "start1<- c(log(77),logit(0.14),log(7.7),.....)" . When printed the values were transformed and everything looked fine. But when run in the model (myCH, model = list(D ~ session, g0 ~ session, sigma ~ session), start = "start1",...), I received the same error message. Finally I was able to get the model to run by entering the transformed values directly (myCH, model = list(D ~ session, g0 ~ session, sigma ~ session), start = c(1.9,-0.85, 0.88,...), even though input was the exact same as the object. Any idea why this might be?

Also, while I believe I understand how to input values for a simple model like above, I'm having trouble finding examples of proper syntax for more complicated ones. What if I want to try a learned or Markov trap response (D ~ session, g0 ~ b, sigma ~ session)? Would it be right to assume that now I require a 4th parameter and my model should look like this :(myCH, model = list(D ~ session, g0 ~ b, sigma ~ session), start = c(1.9,-0.85, 0.88,-1,...)? Just as important, how would this change if i wanted to look at just sigma (D ~ session, g0 ~ session, sigma ~ b) or both?

Thanks in advance for any help, it's always greatly appreciated!

Greg

[murray.efford]

I'm running multi-session models (described in my last post) with high levels of variation between sessions (near trap saturation in summer, very low densities in winter) and need to include starting values. I've tried using a previously fitted model but always recieve the error message

Error: length(start) == NP is not TRUE

I then moved on to trying the starting values as an object. I used "start1<- c(log(77),logit(0.14),log(7.7),.....)" . When printed the values were transformed and everything looked fine. But when run in the model (myCH, model = list(D ~ session, g0 ~ session, sigma ~ session), start = "start1",...), I received the same error message. Finally I was able to get the model to run by entering the transformed values directly (myCH, model = list(D ~ session, g0 ~ session, sigma ~ session), start = c(1.9,-0.85, 0.88,...), even though input was the exact same as the object. Any idea why this might be?

Also, while I believe I understand how to input values for a simple model like above, I'm having trouble finding examples of proper syntax for more complicated ones. What if I want to try a learned or Markov trap response (D ~ session, g0 ~ b, sigma ~ session)? Would it be right to assume that now I require a 4th parameter and my model should look like this myCH, model = list(D ~ session, g0 ~ b, sigma ~ session), start = c(1.9,-0.85, 0.88,-1,...)? Just as important, how would this change if i wanted to look at just sigma (D ~ session, g0 ~ session, sigma ~ b) or both?

1. The algorithm for automatic starting values uses only the first session in a multisession dataset, and will fail if this is very sparse: this is presumably what you encountered, and the correct response is to provide start values manually, as you are attempting (I haven't referred to your previous post).

2. What you say implies there is a bug in the mechanism for passing an old model to secr.fit() in the argument 'start'. I'm not aware of any problem, but that doesn't mean there isn't one. If the problem persists please post more detail or send me details offline.

3. Do not use quotes when passing an object as the value of an argument.

4. Yes, the start vector must include one value for each beta parameter. In the case of a non-constant model for a particular real parameter, the additional beta parameters follow the intercept for the particular model. Usually it is enough to set these to zero - in your example c(1.9,-0.85, 0, 0.88) for g0~b, c(1.9,-0.85, 0.88, 0) for sigma~b, and c(1.9,-0.85, 0, 0.88, 0) for both. The rule is that the vector of beta parameters is cut into sections, one for each modelled real parameter (D, g0, sigma), and the intercept comes first in each section. This is clear enough from the output once you get a model to fit - I can't remember where else it is documented!

Murray

[Pranav]

Dear Dr Efford,

I am posting my query here because it it is related to a problem that has been discussed previously on this thread.

I am running an analysis to estimate density, using the 'hcov' function to incorporate sex effects into the models. At the end of all the likelihood iterations, the models fail to converge and the following error is displayed : probable maximization error: optim returned convergence 1. See ?optim

It appears that specifying starting values may be the way forward. However when I do so, the following error appears: Error: length(start) == NP is not TRUE. Following some of the solutions prescribed previously on this forum, I tried plugging the transformed values directly into the start vector. I don't think data limitations are cause for worry in this case (I have over 200 captures for some 15 marked animals).

I believe that this complication may be on account of incorrect specification of of the start values for a model that includes covariates in the hcov format. Perhaps I am not entering values in the correct sequence, relative to the beta parameters. In the vector for "init" provided below, I also tried including a starting value for D, but the previously mentioned error "length(start) == NP is not TRUE still appears.

Sample code is provided below for your perusal:
init=c(logit(0.02),log(3000))

Dot_model_Hcov = secr.fit (2013_580_hcov, hcov="sex", start =init, mask = mask_15km, method = "Nelder-Mead", detectfn =0, verify=FALSE)

In addition I am also interested in building models with heterogeneity and behavior effects on the detection parameters. For example:

2013_sex_model_Hcov = secr.fit (2013_580_hcov, hcov ="sex", model = list (g0~h2, sigma~h2), start = init, mask = mask_15km, method = "Nelder-Mead", detectfn = 0, verify=FALSE)


I would really appreciate your feedback on the following:
(1) How should start values be entered for the dot model, and other model variants
(2) Does it matter how the start values are entered, based on whether I specify CL=TRUE or CL=FALSE

Thank you very much for your time.

Pranav

[murray.efford]

Hi Pranav

I would be surprised if your problem is just with starting values, but it's hard to tell. I'm guessing there is something more fundamentally wrong. If you want to send me the dataset offline (captures, trap locations, mask specification) then I may be able to diagnose it.

As stated previously, there should be one value in the start vector for each 'beta' parameter, in the order they are reported by 'secr' (you can also see this at each iteration when running with trace = T). In your model there are three beta parameters (one for each of D, g0 and sigma) so your start vector should be of length 3, not 2. If you use CL = TRUE then it drops to 2 because you are not estimating D. If you fit more complex models of course the number increases.

If you have fitted any other model to the same dataset then you can provide that as a value of 'start'. The next version of secr, due in a few weeks, will have a more flexible option for specifying start values (just provide a value for any of the 'real' parameters).

Murray

[murray.efford]

I counted wrong in my first reply - I had forgotten that with hcov models there is a further 'real' parameter (sex ratio in this case), so one extra beta.
Murray

[murray.efford]

My hunch that Pranav's problem was more fundamental turned out to be correct. I found a bug in secr.fit() that causes mixture models (including hcov) to fail when the first trap/camera is not used on the first occasion. If you cannot be bothered reordering traps or occasions in the input, I suggest simply changing the first 'usage' value with

Code: Select all

usage(traps(CH))[1,1] <- 1

That should have no perceptible effect on the results if you have a reasonable number of detectors and occasions. Another solution with its own merits is to collapse the multiple Bernoulli trials (occasions) of a 'proximity' detector into a single-occasion (binomial count) detector with usage equal to the number of occasions each detector was operated. This should do it:

Code: Select all

CH2 <- reduce(CH, by = 'ALL', outputdetector = 'count')
fit2 <- secr.fit (CH2, binomN = 1, etc.)

(Note that 'binomN = 1' tells secr.fit to treat the 'usage' value as the size of the binomial sample).
Murray

[Pranav]

Hi Murray,

The estimates are just fine now. As you had initially guessed, it wasn't a problem with the starting values after all!

Thank you very much for your prompt reply -- and your help is greatly appreciated.

Pranav