www.phidot.org

Dear all,
I’m analyzing a robust design data type.
The “process.data” ran well but I have some problems with “make.design.data”.
Have someone gotten the following message by running the “make.design.data”?

Error in names(design.data) = dd.names :
attribute 'names' [4] should have the same length of vector [3]

It would be very appreciate some advice where I can look for and fix the error.
Thank very much,
Carlos

This is an untrapped error. I'll need to know more details to help. In particular I need to know the specific model (Robust,RDOccupancy or what), number of primary and secondary occasions. Some parameters are not defined without a sufficient number of primary occasions and I believe that is what causes this error to occur. I need to add specific traps to provide a more useful error message.

--jeff

Dear Jeff,
Thanks for your reply.
The dates came from two different studies of the same rodent population. Both sutudies were set up for a robust design with monthly capture-recapture effort.
The research efforts were:
(a) abril/2004 to june/2005 ----> 15 months
(b) November/2007 to November/2009 ----> 25 months
Thus, we had 40 months effort (number of primary occasion) with a interval of 30 months (or 875 days) between them.
The number of secondary occasion varied between 3-6 per month, with a total of 215 days.
The total of individual capture history were 246.
Below it was pasted some summary of the data.process to make clearer.
It would be very helpful if you could advise me where my wrong is.
Thanks,
Carlos

Code: Select all

> cavia.process$model
[1] "RDHFHet"
> cavia.process$nocc
[1] 40
> cavia.process$nocc.secondary
 [1] 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 3 6 6 6 6 6 4 6 5 6 6 6 6 6 6 6 5 6 5 6 5 5 6 6 6
> cavia.process$time.intervals
  [1]   0   0   0   0  20   0   0   0   0  28   0   0   0   0  21   0   0   0
 [19]   0  33   0   0   0   0  22   0   0   0   0  21   0   0   0   0  27   0
 [37]   0   0   0  30   0   0   0   0  25   0   0   0   0  19   0   0   0   0
 [55]  32   0   0   0   0  17   0   0   0   0  32   0   0   0   0  22   0   0
 [73]   0   0 874   0   0  27   0   0   0   0   0  23   0   0   0   0   0  24
 [91]   0   0   0   0   0  26   0   0   0   0   0  22   0   0   0   0   0  56
[109]   0   0   0  26   0   0   0   0   0  22   0   0   0   0  26   0   0   0
[127]   0   0  23   0   0   0   0   0  27   0   0   0   0   0  24   0   0   0
[145]   0   0  22   0   0   0   0   0  26   0   0   0   0   0  27   0   0   0
[163]   0   0  18   0   0   0   0  29   0   0   0   0   0  28   0   0   0   0
[181]  18   0   0   0   0   0  27   0   0   0   0  24   0   0   0   0  24   0
[199]   0   0   0   0  25   0   0   0   0   0  25   0   0   0   0   0

Please send me offlist (Jeff.laake@noaa.gov) all or a portion of your data and the R code you are using. I can't tell what the problem is from looking at what you have sent. It isn't what I thought it might be. I just tried this model with data(robust) and it worked fine. So either there is something specific with your example or the code your are using. Did you set mixtures to 1?

We resolved this offlist. In the process.data step he set initial.ages=NULL and age.unit=NULL to overide the defaults of 0 and 1 respectively. This didn't allow ages to be constructed in the design data because they would have all been NULL and this created the untrapped error where R was reporting that it was trying to put something of length 3 into something of length 4. This interchange has made me realize that if a certain basic amount of information is posted I could resolve these problems more quickly. In particular, please include the following in posts if you are getting an error.

1) R version (type R.Version()$version in R) and RMark version (reported after library(RMark))
2) Your code including calls to import data, process.data and make.design.data. More if error occus later
3) Few lines of your data

Typically with that info I can resolve most problems. This interchange also helped me identify a few places where I need to add error traps in RMark.

--jeff

Dear Jeff,
Thanks for your reply.
It made much clear now and was very helpful, thanks!
Best regards,
Carlos