MLOGIT Conundrum

[X33277]

Amateur hour here - But I have RTFM and searched the forum and help file for some assistance so figure I may ask a simple question. I have a 40 occasion multi-state (4 states) study. In MARK is there an easy way to specify the MLOGIT function? I had to specify the MLOGIT for more than 296 parameters (some psi were fixed). When I started this project on Friday night I easily passed Gary's sobriety check, by the time I finished specifying and double checking the MLOGITs well that's another story.

Maybe this is the time to finally learn RMark.

Alternatively I guess I could use the logit link but given the number of states I am assuming this would be frowned upon.

[cooch]

Amateur hour here - But I have RTFM and searched the forum and help file for some assistance so figure I may ask a simple question. I have a 40 occasion multi-state (4 states) study. In MARK is there an easy way to specify the MLOGIT function? I had to specify the MLOGIT for more than 296 parameters (some psi were fixed). When I started this project on Friday night I easily passed Gary's sobriety check, by the time I finished specifying and double checking the MLOGITs well that's another story.

Maybe this is the time to finally learn RMark.

Alternatively I guess I could use the logit link but given the number of states I am assuming this would be frowned upon.

1\ cut and paste from Excel - its actually pretty easy.

2\ if you're clever, you can write an R script to generate whatever Excel sheet you need, for whatever structure you want, and cut/paste from there into MARK

3\ how long did it take to collect the data you're analyzing? In my general experience, the time it takes to set things up in MARK is vanishly small relative to the time it took to collect the data in the first place. So it takes you an hour to set up parameters - given how long it took you to collect the data, is that really a hardship?

4\ if you want speedy this and speedy that, you will not be a happy camper when you go Bayesian. I had a job I worked on recently where a single model took over 5 days to converge. Multply that by the 15 models or so I considered building, and....you get the point. But, the data were collected over 26 years,so in the cosmic scheme of things, no problem.

RMark will help automate a lot of things, but unless you're an R God (orJeff Laake, which amounts to much the same thing), then you'll probably spend as long debugging the RMark code as you would have spent setting it up in 'classic MARK'.

Simple reality check -- complex models with lots of data and lots of states take time to set up.

[X33277]

Fair enough, and thanks, I didn't know you cut and paste from excel but that works really well and makes it a lot easier to keep track of the psi parameters. Definitely not an R wizard by any means, so I will continue with classic MARK, just didn't know if I was missing an easy trick or not.

[jlaake]

I'm sure Evan would be disappointed if I didn't respond to this query. Well maybe not. While I have no vested interest in "selling" RMark, you don't need to be an R wizard or R god to use RMark. If this is the only capture-recapture data that you'll ever analyze, stick with what you are doing. But if you are likely to continue with this type of analysis, I suggest you take the time and learn a little and save yourself a lot of time down the road. Many of the models in MARK have RMark templates that you can use as a starting point so you are not starting from scratch. Here is the mstrata example for Multi-state models. No PIMs, design matrix definition or mlogit specification. All embedded in RMark but you do need to understand how formulas translate to design matrices. While my RMark documentation is not as voluminous as the Cooch and White book, it is relatively complete and I have seen numerous articles from folks that used RMark that never posted on phidot or contacted me individually. So it is possible to learn with the available documentation.

Code: Select all

data(mstrata)
run.mstrata=function()
{
#
# Process data
#
mstrata.processed=process.data(mstrata,model="Multistrata")
#
# Create default design data
#
mstrata.ddl=make.design.data(mstrata.processed)
#
#  Define range of models for S; note that the betas will differ from the output
#  in MARK for the ~stratum = S(s) because the design matrix is defined using
#  treatment contrasts for factors so the intercept is stratum A and the other
#  two estimates represent the amount that survival for B and C differ from A.
#  You can use force the approach used in MARK with the formula ~-1+stratum which
#  creates 3 separate Betas - one for A,B and C.
#
S.stratum=list(formula=~stratum)
S.stratumxtime=list(formula=~stratum*time)
#
#  Define range of models for p
#
p.stratum=list(formula=~stratum)
#
#  Define range of models for Psi; what is denoted as s for Psi
#  in the Mark example for Psi is accomplished by -1+stratum:tostratum which
#  nests tostratum within stratum.  Likewise, to get s*t as noted in MARK you
#  want ~-1+stratum:tostratum:time with time nested in tostratum nested in
#  stratum.
#
Psi.s=list(formula=~-1+stratum:tostratum)
#
# Create model list and run assortment of models
#
model.list=create.model.list("Multistrata")
#
# Add on specific model that is paired with fixed p's to remove confounding
#
p.stratumxtime=list(formula=~stratum*time)
p.stratumxtime.fixed=list(formula=~stratum*time,fixed=list(time=4,value=1))
model.list=rbind(model.list,c(S="S.stratumxtime",p="p.stratumxtime.fixed",
  Psi="Psi.s"))
#
# Run the list of models
#
mstrata.results=mark.wrapper(model.list,data=mstrata.processed,ddl=mstrata.ddl)
#
# Return model table and list of models
#
return(mstrata.results)
}
mstrata.results=run.mstrata()
mstrata.results

#