Possible RMark bug with shared p & c in robust design

posts related to the RMark library, which may not be of general interest to users of 'classic' MARK

Possible RMark bug with shared p & c in robust design

Postby JeffHostetler » Thu Jan 29, 2009 9:53 am

We're running a complex analysis using Huggins robust design, which we're currently moving from MARK to RMark. To make sure we're doing it correctly, we've tried several models in both interfaces. Most of the discrepancies are due to errors in how we set things up in MARK, but we found one that doesn't seem to be.

Most of our primary sessions contain two secondary sampling occasions. We are setting p=c for all models (by using share=T when defining p in RMark). We have one model where p and c vary between two seasons. In one case the season boundary falls so that the first secondary occasion falls in one season and the second in the other. (Yes, we're aware that robust design may not be the best modeling framework for our sampling design.) By examining the text files, we saw that MARK and RMark are setting up p the same way, but that MARK is setting the c for that occasion to the same parameter as the second p, but RMark is setting it to the same parameter as the first p. I think MARK's behavior here is correct.

This is causing very small differences in AICc and model estimates in this case, which we're happy to ignore. I bring it up because if it's a bug, it's possible that the differences won't be small in every case. Let me know if I can provide more information or if it looks like the problem is due to something we're doing wrong.

Thanks,

Jeff
JeffHostetler
 
Posts: 13
Joined: Thu Sep 18, 2008 11:31 am
Location: Smithsonian Institution

My mistake...

Postby JeffHostetler » Thu Jan 29, 2009 5:02 pm

It turns out the problem was with how I set up the design data. Thanks to Jeff Laake for helping me find this.

The problem came because p and c are counting Time starting at different points, and I used the same code for both. Jeff points out that there is an argument common.zero=TRUE in make.design.data that will also resolve this problem.
JeffHostetler
 
Posts: 13
Joined: Thu Sep 18, 2008 11:31 am
Location: Smithsonian Institution


Return to RMark

Who is online

Users browsing this forum: No registered users and 1 guest

cron