cschwarz-stat-sfu-ca / BTSPAS

Bayesian Time Stratified Petersen Analysis System
1 stars 3 forks source link

Diagonal case fails with a single release group #32

Closed cschwarz-stat-sfu-ca closed 3 months ago

cschwarz-stat-sfu-ca commented 3 months ago

Tyler Pilger wrote:

I have been using BTSPAS for several years now on a couple RST programs I work with in California. I recently acquired data from another program and am planning to use BTSPAS again to estimate annual abundance for fall-run Chinook salmon. Unfortunately, the data from this program is less than ideal in that the number of marked releases to estimate catchability is very limited. As few as one in a sample season. The main reasons for this is because the number of fish passing this trap is low, so there are few fish available to mark and release. But also in recent years, hatcheries have not had surplus fish to use for marked releases. Ultimately, I would like to use prior information on the relationship between logit P and log flow to help with weekly estimates of logit P.

I have encountered two issues when using BTSPAS when there is only a single jweek with non-zero values for n1 and m2. The first was in the function TimeStratPetersenDiagError_fit. I traced the issue to the section where you apply the Petersen estimator to each stratum after excluding n1=0 or bad values of n1 or m2. On line 320 the object temp is created to display results and line 321 assigns column names to temp. When there is only 1 stratum with n1 and m2, the number of columns of temp does not match the number of column names resulting in an error. In an effort to get this to work, I created my own version of the function and commented out line 321.

After this, the function worked down to the section where it calls the function TimeStratPetersenDiagError. The next issue appears to be occurring with the call to JAGS. The error I receive is "Error in jags.model(model.file, data = data, inits = init.values, n.chains = n.chains, : Error in node epsilon[2] Node inconsistent with parents".

At this point, I have not been able to identify the cause of this error. I am not sure if it is caused by only having one week with empirical data for logit P or something else. Attached is one of the years of data that I have encountered this issue. In the data, there were actually four weeks with n1, but in weeks 13, 16, and 17, the number of recaptures was extremely low or not at all. I assigned weeks 13, 16, and 17 to bad.m2, leaving only week 6 with values for n1 and m2. The JAGS model will run if I remove either week 13 or 16 from bad.m2.

cschwarz-stat-sfu-ca commented 3 months ago

Carl Schwarz a) First problem is "easy". It occurs when you have only 1 capture-recapture group. A test for pooling doesn't make any sense. The TestIfPool function still "runs", but now tests if the recapture probability is 0.5 which is silly. I've added a test that stops the test for pooling if the number of release groups is < 2. This has been pushed to GITHUB

(b)Second problem is also related to having a single release group. The model has logitP varying around the mean logitP with some variance, i.e. logitP[i] = meanLogitP + epsilon[i] only for [i] with release data. In turn, epsilon[i] comes from a normal distribution with mean 0 and precision (1/variance) of tauP. [JAGS uses the precision rather than the variance when describing a normal distribution)

WIth a single release group, there is NO variation in logitP around the mean in the various release groups which implies that variance of epsilon = 0 which implies that tauP goes to infinity which eventually causes JAGS to fail.

As surmised in the previous email, the problem was with the precision of the epsilon being infinite, corresponding to sd =0. Turns out, the initial value of tauP was set to infinite (by us!), so the jags program didn't even get started. I bounded the init value of tauP to 5. The prior on tauP keeps it from wandering off too large.

cschwarz-stat-sfu-ca commented 3 months ago

Corrections made and submitted to CRAN