trying to re-run species interaction occupancy models

[klg-2016]

https://github.com/kaitlyngaynor/gorongosa-mesocarnivores/blob/1d4c1f983058967b05bae777b42d202f1e72152e/scripts/species-interaction-model/01-prep-data-for-occupancy-analysis.R.R#L16

I'm going through to re-run the models, and running into an issue getting the data in the right format. When we did these models in 2020, occasionStartTime went in the detectionHistory function, and we specified 12 for it because we were interested in noon to noon.

Now, occasionStartTime is part of the cameraOperation function. Default seems to be 0 (midnight).

If I run the code with start time as 0, the resulting detection history misses a bunch of inoperational cameras (there are not NAs in the sheet where there should be)

If I change the start time to be 12 in the camera operation function, it still misses those inoperational dates. It also removes some records that were taken before the start of the period (before noon on August 1, which makes sense) and one that was taken after the end of the last occasion (00:23:00 on November 12, doesn't make sense). I'm going to check the information on the package and see if somehow the NAs were removed from the detection history (though why that would be, I have no idea).

If you see this and have any thoughts, I'd appreciate them! Thank you

[klg-2016]

Just checked and the camera operation resulting matrix should still have NAs: Legend: NA: camera(s) not set up, 0: camera(s) not operational, 1 (or higher): number of operational camera(s) or an indicator for whether the station was operational (depending on camerasIndependent and allCamsOn)

[klg-2016]

I am not sure why, but the camera operation function isn't correctly reading in the problems

[klg-2016]

working on trouble shooting: the table has NAs just fine for camera F09, which wasn't put up until September 9, 2016 but it misses NAs for camera D09, which has a problem starting 8/7/2016

[klg-2016]

I do not have an answer for this, but I realized that this whole script is to spit out data frames to be used elsewhere, so I'm trying to move forward by using the saved dfs I have from 2020

[kaitlyngaynor]

Ok I think your last comment suggests this has been resolved? I think that's the best plan. Mysterious. My guess is that it has something to do with the way that dates are formatted (dates are always a headache) but no need to troubleshoot if you can just use your existing dfs.

[klg-2016]

Yep that's where I landed, so I think we should be okay to use the existing dfs.

Just confirming my understanding: are an NA and a 0 inherently different? Or does the model treat "not set up" and "not operational" as effectively the same? That could be at least part of the explanation for the difference between last time and now. so in the 2023 iteration of the package, it's going to give NAs until the camera is set up and 0s any time there's a problem (is my guess), whereas last time it gave NAs any time the camera wasn't "on"

[kaitlyngaynor]

I am pretty sure this particular model treats NA and 0 as the same. Other models may not, which may be why they are now differentiated. Or maybe they are trying to mimic the format of the detection history files (where there IS a difference between NA = no camera operating and 0 = not detected)

[klg-2016]

Okay, that may be the answer here then. either way, going to keep moving forward with the existing dfs (unless I figure out that the warning there is actually very bad and can't be ignored)

[klg-2016]

just making a note here with more clearly what I think the answer is so I don't come back to this in a few days and get confused:

• I think that the current version of camtrapR creates camera operation tables that have NAs until the camera is set up, 0s for days with problems, and 1s for days that the camera is operating. this is different from the 2020 version, which gave NAs for any day that the camera was inoperational, including both pre-set up and problem days.