Open klg-2016 opened 1 year ago
Puzzling! You're probably right that it should be fine, given that it's a warning and will drop in an NA, but I'd still try to take a look at the underlying input data frames to see what's going on, in case it's a symptom of a bigger issue. You do want to make sure the days line up correctly.
I'm not familiar enough with the workflow or format of input dfs to best advise you on troubleshooting, but I'd look at the output at every step of the way and try to follow what's going on. Feel free to add more comments/additional context if you want more advice on this.
I'll spend some more time on this today and see if I can either figure it out or articulate some questions on the troubleshooting
I figured out where the "bad" date was (October 28, 2016 for camera D07). Somehow there is a missing NA on that date only for genets, which means that all the records have been moved over by one date (to be correct as far as I can tell, the NA needs to be added for the 28th, and everything else needs to be shifted to the right one column).
I also went back and spot checked other species for that camera, and there seems to be an issue for marsh mongooses as well (detection history says there was a marsh mongoose detected on 9/8, and the record table has it as 9/9). For civet too, the detection history says there was a civet detected on 9/6, but the record table has it as 9/7. I don't think any honey badgers were detected at that camera.
There is a disagreement between the DateTimeOriginal column and the Date column in the record table spreadsheet, but the code only uses the DateTimeOriginal column.
Unfortunately I think I'm pretty limited in further troubleshooting to figure out what's going on, because the camop object (where I made the camera operation object) isn't something I wrote out to a csv, so I don't have access to the one from 2020 to see what's under the hood of the detection histories. I'm a bit at a loss to understand why everything seems to be off by one day just for one camera.
I don't remember any warnings like this coming up when I worked with these models in 2020. I'm going to try to recreate the detection histories following our conversation in the other issue (that the difference between NA and 0 might be fine) and spot check them to see if that seems safer.
Nope, the "missing" NAs in the camera operation data frame (0s where the camera has problems instead of NAs) mess with the detection histories as well. The genet detection history (created with a camera operation data frame I just generated) for camera D07 has all 0s during the problem, instead of NAs (same problem we were discussing in the other issue).
What we established in the other issue is that for detection histories, 0 and NA are indeed different, right? I'm looking at the unmarkedFrameOccuMulti info online (which creates the data object that goes into the occuMulti model-fitting function), and it includes this for its argument: A list (optionally a named list) of length S where each element is an MxJ matrix of the detection, non-detection data for one species, where M is the number of sites, J is the maximum number of sampling periods per site, and S is the number of species in the analysis Is detection, non-detection literally just 1/0? but then I'm confused by where there should/shouldn't be NAs.
I also went back and spot checked other species for that camera, and there seems to be an issue for marsh mongooses as well (detection history says there was a marsh mongoose detected on 9/8, and the record table has it as 9/9). For civet too, the detection history says there was a civet detected on 9/6, but the record table has it as 9/7. I don't think any honey badgers were detected at that camera.
Wouldn't this discrepancy in the dates of the detection history and the detections be related to the fact that you are going from noon to noon, rather than midnight to midnight? so a record in the wee hours of September 9 will count as September 8.
Is detection, non-detection literally just 1/0? but then I'm confused by where there should/shouldn't be NAs.
As I understand it, detection = 0, non-detection = 0, camera non-operation = NA. So if the camera wasn't working, you get an NA, but if the camera was working and didn't detect the animal, you get a 0.
I'm dipping into this super quickly but let me know if there are specific questions/things you want me to look at! Sorry for this headache, arggg
Yes thank you for reminding me of that. The noon to noon explains most of the problems here, my brain was just going in too many circles to remember that detail. I still don't understand why there's a missing NA on the 2020 genet detection history, or why I can't generate a detection history now that has NAs where there should be NAs, but I think we're back to being able to ignore it. I confirmed every genet detection from that camera (D07) and they all line up, even with the missing NA (so my earlier statement of thinking everything needed to be moved over by a date was wrong, having forgotten what noon to noon means).
With that, I should be set to run more models, but I think I'm going to wait for Erin to respond to our discussion before doing so. I'll spend more of today with the text itself.
Thank you!
Glad that sorted things out! 😊
https://github.com/kaitlyngaynor/gorongosa-mesocarnivores/blob/28f3e622bf27cb972a889a9e6cc460e08629cd24/scripts/species-interaction-model/02-multi-species-occupancy-analysis-GNP.Rmd#L66
actually running the models throws a warning because the detection history NAs don't match up perfectly for each of the 4 species (which they obviously should, because NAs are days that the cameras weren't functioning, which is the same regardless of spp)
in trying to figure out where the discrepancy is, the genet dh has 458 NAs, while the others all have 459. I'm not sure how to identify which camera/date is different.
the warning suggests that the function just replaces the "extra" observation with an NA so everything plays nice, which I think should be fine?