mark or rmark?

[chillo]

I’ve got a squishy, non-technical question, and I’m hoping someone out there has experience to help me decide if I am better off grinding through the analyses I describe below in Mark, or if rMark would be a more efficient use of my time. I spent a couple months last summer working through Cooch and White, did some simplistic analyses of my data in Mark, but had to put that aside when the summer ended and I got busy with other things. For more complicated analyses I was looking forward to the flexibility of rMark, but my R skills, which I’ve been working on this past year, are still quite basic. I have written some simple scripts for data munging and plotting, but have to hit up stack overflow to ask questions pretty regularly. I think the right advice here might possibly keep me from going down a month-long dead end. Details of what I’m attempting in the next two paragraphs. I probably included too much info, sorry. Maybe skip the middle paragraph if you’re in a hurry.

I’m doing an analysis of mortality in a population of birds, about 200 individuals marked on an ongoing basis and then each marked bird tracked monthly by resighting (resighting efforts are more or less continuous, binned by month). I think the best approach is Barker method (based on publications by Andrew Barbour, who is in the archives here under user name “snook”!) and I have written an r script to turn our resightings log (12,000 lines) into Mark-compatible .inp files in Barker format, where each time period has two entries, 0 or 1 in the first column for whether the bird was initially marked in that time period, and 0 or 2 in the second column for whether the bird was resighted in that period. Oh, and there are actually two different input files, one with months as a time step and another with seasons as a time step. Same data, just binned differently. Birds emigrate from our population and are never seen again, so I am really estimating “apparent mortality,” because that’s all I can do, so substitute that term for “mortality” if you’re a stickler, but know that I’m aware.

I have male and female birds, and two age classes, with birds graduating from immature to adult as time passes. The age status in particular seemed like something that would be easier to handle in rMark. I want to run a variety of models to estimate adult mortality, immature mortality, sex-specific mortality for both age classes, and whether mortality and capture probability vary by month, season, or year. Right off the bat I notice that convert.inp will not work with the Barker input files I have created (if I’m correctly interpreting documentation which says “[won’t work with] specialized ones for known-fate or Brownie models.”). So right away rMark does not seem like it’s plug and play, more like "start by working through other simpler analyses in the various workshop examples and develop the skills needed to do your own analyses." Without starting down that road I don’t have much idea if “develop the skills” will take me one week or six or thirty-six. If it’s the latter I could probably just devote a weekend or two to very carefully typing numbers into fairly massive Mark PIMs and come out ahead.

If you made it this far, thanks for reading! I have enjoyed rtfa and slightly less so rtfm, and appreciate previous posts here. Which way should I jump?

[cooch]

It isn't really a straight contrast of MARK vs RMark, since the latter uses the former for *all* of the estimatin calculations. Rather, its a question of which flavor of interface tdo you prefer, and what additional things would you like to be able to do with various 'outputs' from the estimation, perhaps mid-stream.

Given you've already learned a fair bit about how MARK (generally) works, I'd recommend deep diving into RMark. There are definite advantages to RMark, *IF* you know what MARK is doing with the code, and *IF* you have some facility with R. The sheer number of 'help me get my RMark code to work' questions posted on this forum (99% of which Jeff Laake answers) is diagnostic that RMark doesn't in and of itself automatically make things easier/more efficient. It *can* do so, provided (i) and (ii) above apply.

To me, the phrase 'ongoing basis' in your post is another major motivator to 'go RMark'. One of Jeff's motivations for creating it was the ability to easily 'add another surveys worth of data' to an analysis. In GUI-based MARK, you'd literally need to start from scratch with each additional bit of data.

[chillo]

Thanks for that reply, cooch! I had to go back and look - did I really say "ongoing basis?" Because I'm only leaning into population biology temporarily and would be DELIGHTED if I could knock out these analyses, publish, and close down the monitoring scheme to focus on new questions about movement in this species. I am happy never to become expert on mark-recapture analyses. That was the flavor I hoped to impart - if this was a one-shot deal, one analysis, one paper, is rMark (granted all its advantages going forward) still worth the learning curve? [turns out I did say "ongoing basis" but that was how the data was collected up til now, and I likely have enough data in hand to answer my questions more than adequately]. And yes, your first paragraph is 100% spot on - it's the interface that I'm trying to decide on.

[cooch]

Thanks for that reply, cooch! I had to go back and look - did I really say "ongoing basis?" Because I'm only leaning into population biology temporarily and would be DELIGHTED if I could knock out these analyses, publish, and close down the monitoring scheme to focus on new questions about movement in this species. I am happy never to become expert on mark-recapture analyses. That was the flavor I hoped to impart - if this was a one-shot deal, one analysis, one paper, is rMark (granted all its advantages going forward) still worth the learning curve? [turns out I did say "ongoing basis" but that was how the data was collected up til now, and I likely have enough data in hand to answer my questions more than adequately]. And yes, your first paragraph is 100% spot on - it's the interface that I'm trying to decide on.

Given that, then GUI-based MARK might be your best option, only because of the bulk of documentation that is available for that interface (this is not to slight the RMark documentation, but documentation notwithstanding, using RMark at a high level is conditional on (i) really understanding how MARK works, and (ii) being pretty savvy with R). If you might re-visit mark-recapture down the road, then there is greater value in learning RMark, but as a one-off, GUI-based MARK.

My 2 cents...