Temporally constraining p to deal with identifiability?

questions concerning analysis/theory using program MARK

Temporally constraining p to deal with identifiability?

Postby mldavis13 » Wed Jan 04, 2012 1:01 pm

Dear All,

I'm using an AICc analysis to compare different POPAN models of a deer dataset over 23 capture occasions. I've read the MARK book and searched the forum but need some clarification. I'm concerned about the need to manually adjust the parameter count downward due to lack of parameter identifiability. For the record, I'm using the default adjust=TRUE argument in RMark so the non-estimable parameters ("at the boundaries") are being counted (I've checked).

My understanding is that with the model phi(time).p(time).pent(time), I have two instances of confounding: PhiK-1*pK and pent0*p1. The MARK book table 13.2 states that "in order to resolve this confounding, the models must make assumptions about the initial (p1) and final (pK) catchabilities. For example, a model may assume that catchabilities are equal across all sampling occasions."

Just so I am absolutely clear on this issue: Does the use of a temporal covariate work to solve these instances of confounding or does p need to be constant?

In other words: given that I know from collaborators that trapping effort has increased with time, would constraining my catchability estimates with an effort covariate (pEffort) or using a simple temporal trend (pTime) be a reasonable way to solve these problems of variable confounding? (Thus avoiding the need to adjust npar downward).

Presumably, then, the same logic would work for the confounding of PhiK-1 and pK in the CJS models?

Many thanks,

Miranda
mldavis13
 
Posts: 15
Joined: Mon May 23, 2011 12:41 pm

Re: Temporally constraining p to deal with identifiability?

Postby abreton » Thu May 16, 2013 4:53 pm

the non-estimable parameters ("at the boundaries")


Note, a parameter on a boundary is estimable (not confounded), it's just that by being on a boundary (either close to 0 or close to 1) the link functions provided in MARK may/may not (depending on the link) be able to determine/arrive at an estimate. In contrast, when two parameters are 'confounded' they are not separably estimable ... and no tweaking of link functions can resolve this problem. The latter is a model issue, the former is a limitation of certain link functions. See discussions about sin vs. logit link functions in the gentle intro ... if you want more details.

Does the use of a temporal covariate work to solve these instances of confounding or does p need to be constant?


A temporal covariate (e.g., p COV) that does not vary in its effect on the parameter (e.g., p) over time used IN PLACE OF the categorical time effects (e.g., p time) would solve this problem, i.e., terminal parameters would no longer be confounded. This parameter would be implemented into the design matrix of mark as a single column (beta). if implemented in columns for each year (except one = intercept) then it's effect is time-varying ... and you're back to the confounding.

given that I know from collaborators that trapping effort has increased with time, would constraining my catchability estimates with an effort covariate (pEffort) or using a simple temporal trend (pTime) be a reasonable way to solve these problems of variable confounding?


Yes, it's reasonable/certainly should be considered. Effort can be a very useful covariate for detection probability, same is true for temporal trend. Just keep in mind that by constraining the p's to be functions of only one or more covariates you may be tossing out a lot of time variation that IS NOT captured by the covariate(s). If this is true, i.e., a lot of existing variation in p is not accounted for, then you'll get biased estimates for the p's ... as well as all other parameters in the model. Covariates can be very helpful, especially for absorbing heterogeneity among individual detection probabilities, but they need/should be used with care.

andre
abreton
 
Posts: 111
Joined: Tue Apr 25, 2006 8:18 pm
Location: Insight Database Design and Consulting


Return to analysis help

Who is online

Users browsing this forum: No registered users and 3 guests

cron