Error running Estimates production for all runs on New Database

[jasmyace]

Do either of you recognize the error:

Error in $<-.data.frame(*tmp*, "forkLength", value = NA) : replacement has 1 row, data has 0 Calls: F.run.passage -> F.summarize.fish.visit -> $<- -> $<-.data.frame Execution halted

I’m working with Mokelumne River data and 11 of 16 annual runs with the report “Estimates production for all runs” resulted in the same error. This is a database we haven’t tested before. I can post it for you if you like. I’ve been giving it a QC and can’t find the reason for the problems. They do catch sub-adult and adult fish in there traps but these are excluded from analyses by my sql and it doesn’t seem to be the problem. I don’t see anything different or unusual about these data.

I’ve attached the R.out above. I can send the database or anything else you want.

[jasmyace]

Trent and/or Jason;

In this dataset the life stage and run are consistently assigned however the fork lengths are sometimes missing. This will happen in other watersheds as well. The 2006 test I ran on the Golf trap included three dates when only one Chinook was caught. In each case the fish was assigned a run and life stage but not measured. I don’t think this is the problem since 2005 and 2012 also have similar records and were run successfully. Unless some, but not all, of this type of record cannot be resolved by the code.

Jason found an unidentified error while running tests. His comment contains key words found in the original error “fork length” and “NA”. I don’t understand the comment but he handled it here in the summarize_fish_visit.r file line 20.

Jason add - first pass assumed that unassigned fork length is NA. but...not NA for one day in run I’m investigating. force this.

catch[catch$Unassd == 'Unassigned',]$forkLength <- NA

When I comment out line 20 in this file the analyses seems to run smoothly until the end when it tries to summarize passage. The new error is:

Error in F.est.passage(catch.df.ls, release.df, "year", out.fn.root, ci) : Issue with summation of assignedCatch, unassignedCatch, inflatedCatch, imputedCatch, and/or totalCatch. Investigate est_passage.R, around line 176. Calls: F.run.passage -> F.est.passage Execution halted

In regards to this second error, is it possible that the code considers these fish as “assigned” in one area (both run and life stage are assigned) and “unassigned” (no fork length present) in another and so the tally comes out wrong causing the code to fail?

I put the Mokelumne database on the Camp_Admin site in For Jason folder. They do some other types of trapping so just run locations with the “RST” in the site name. Golf is the one that has both successes and failures and it only has one subsite.

I also put the most recent version of the QC application in there. The reports view all Chinook and Chinook crosstab will help you figure out what the differences might be. I didn’t see anything unusual. The first time you open the QC application you will need to re-establish a link to the CAMP.mdb. A window should come up prompting you to do this. If it doesn’t just use the Check or Change Links button at the bottom of the main form.

[jasmyace]

Hi Connie,

Well...no, I don't recognize this error. However, it looks like the code is expecting some data item to be there, which obviously isn't. This happens often when the code assumes an underlying data structure that doesn't exist. This is not surprising, if this particular river records some key piece of data in some subtly different way that differs from assumption/expectation. Given that we run the code through the other four rivers, with many different combinations of large/small data sets, etc., and with no problem, this is my guess.

Have you been running the code on other rivers without problem? (Are there other rivers?) Or, is this the first you've seen of this? Obviously we can look into this, and determine if it matters for the main rivers, etc. Is there a timeframe for this? We're in between contracts (I think) for right now, so not sure if we can jump into this at this exact moment.

Assuming that we'll take a look at some point, however, it would help if you put this river's database on the server; that will help diagnose the issue.

Thanks, Jason

[jasmyace]

I needed to do something special in this area to accommodate a few runs specific to the Feather, if I remember correctly; the big looping program found a few instances where the data structure in that database (I think) caused the program to crash.

Once we start the next round of work, I'll take a look and see if something is awry, or if this section needs to be generalized slightly to accommodate the data structure of this new river.

[jasmyace]

This issue is duplicated in Issue #47, so I'm closing this one.