 |
 |
))) For the extended transects, it sounds like separating the transects into 'old' and 'new' parts is a good idea. Do you have separate count data for the 'old' and 'new' parts? ))) Temporal autoregression can be very complex. First, if you were to include such an effect, you would want to make reference to # of hits at previous times. I can't tell if this is what you have done or not. You made reference to a term like beta((t-1)-fixedyear). Is this what you are using as an autoregressive term? FYI, what you would want for an autoregressive term is beta*hits[transect j, time t-1]. Second, and more importantly, models which include both temporal autoregression effects (terms related to hits[t-1]) and direct time effects (terms related to t or t^2), can have identifiability issues. Both types of terms can explain temporal trends, and so when a model includes both types of terms, that model can use either or both terms to explain temporal trends. I think it is a bad idea to include both types of terms in one model, because it can make interpretation of model results very difficult. Note that I say this from personal experience. For example, you may know that there is a steady increase in hits over time, and yet you may have a fitted model in which the the year coefficient is indistinguishable from zero. In this case, the model is explaining the change over time using the autoregression term rather than the year term. Thus, in this type of model, the value and statistical significance of the year term are not a good measure of actual change over time. ))) For any given model, there are a variety of mathematically equivalent ways to describe your model in the BUGS language. The particular way which you use to describe your model can have a big effect on the speed with which you can run the model. In particular, using a centered model description can result in significant speed up. If you reorganize your model code in this way, it should make a big difference. See, for example, D. Lunn et al. 2009. The BUGS project: Evolution, critique and future directions. See section 5.1, third and fourth bullets. Also see the very last paragraph. ))) If you're having trouble fitting the model, and you're not sure where the difficulty lies, I suggest a slow, methodical approach. Start with a minimal model (few fixed effects, no random effects), and slowly add different types of terms. For example, try a model with no autocorrelation, no quadratic effects, but with the overdispersion term. You can also try it on a subset of your data. For example, randomly select half your transects, and run the model on that. The results won't be authoritative, but your model will run much faster, and so the debugging process will also be faster. ------------------------------------------------------------------- This list is for discussion of modelling issues and the BUGS software. For help with crashes and error messages, first mail [log in to unmask] To mail the BUGS list, mail to [log in to unmask] Before mailing, please check the archive at www.jiscmail.ac.uk/lists/bugs.html Please do not mail attachments to the list. To leave the BUGS list, send LEAVE BUGS to [log in to unmask] If this fails, mail [log in to unmask], NOT the whole list