Styjun

I am working with a data set containing nested groups and am wondering how to properly specify the model(s).

The data are binary indicators of whether or not a "Code" is agreed upon by a Group. There are 3 Groups within the Control condition and 3 Groups within the Treatment condition.

I am trying to model the probabilities of the various Codes being present in the Treatment Condition.

Some toy data:

library(lme4)

Data <- rbind(data.frame(Code = rep(LETTERS[1:5],6),
 Condition = rep("Control", 30),
 Trial = rep(c(1:3), each = 5), 
 Group = rep(letters[1:3],10),
 Present = sample(0:1, 30, replace = T)),data.frame(Code = rep(LETTERS[1:5],6),
 Condition = rep("Treatment", 30),
 Trial = rep(c(1:3), each = 5),
 Group = rep(letters[4:6],10),
 Present = sample(0:1, 30, replace = T)))

Give the inherent nesting in the data, can I specify the model as:

Mod1 <- glmer(Present ~ Condition * Code + (1|Group), family=binomial(link = "logit"), data = Data)

Or do I need to specify the nesting with something like:

Mod2<- glmer(Present ~ Condition * Code + (1|Condition/Group), family=binomial(link = "logit"), data = Data)

I'm not sure which model captures the design and I have seen conflicting posts about the use of / vs :, so I'm not clear if I have specified the nesting correctly (in addition to whether it's necessary).

The example data are small, so the second model gives a singular fit warning. My data generation/simulation skills are non-existent, so any advice on creating a better example set would also be welcome!

No, all nesting (in the coding sense) does is create two terms, the first term alone and the interaction of the first and second term. And all an interaction needs to have is a unique identifier for each unique combination.

That is, A/B results in A + A:B, and if you had a third variable C which was, say, paste(A, B), then this would also be equivalent to A + C.

In your case, Condition/Group reduces to Condition + Condition:Group, which is equivalent to Condition + Group. So that's why your two models are not equivalent, the second includes a random effect for Condition and the first does not.

Referring back to my first sentence, it's important to distinguish between nesting in the design and nesting in the coding; in your case, Group is nested within Condition in the design sense, because each level of Condition is different for each Group, but you're enforcing that in the computer by giving each a unique identifier, so you don't need to nest in the code.