Including a feature as both a random and a fixed effect

Downstream analysis and statistics MaAsLin
1

On this line, MaAsLin2 removes fixed effects that are also included as random effects. My understanding is that it is not uncommon to include a features as both a fixed effect and a random effect, as this remove the fixed intercept assumption when fitting the linear model. Granted, there seem to be plenty of definitions of fixed and random effects, so the most likely explanation is a disconnect on my end…

Why does MaAsLin2 not allow features to be both fixed and random effects? To get around this issue, I duplicated a column (z) in my metadata, adding one as a fixed effect as a random effect and the other as a fixed effect. In both cases, the fit in the ranef.rds was identical:

image

but in the case where it was included as a fixed effect, three genera (Escherichia, Enterococcus, and Ruminococcus) were shown to be deferentially abundant.

In the case where z was only included as a fixed effect, four genera (Gemmiger, Escherichia, Enterococcus, and Ruminococcus) were shown to be deferentially abundant.

So, the three scenarios (z as fixed, z as random, and z as both) all yield different results. In this case, z is the institution samples were collected from: I want to account both systemic differences due to batch effects (as the fixed effect) as well as variability due to different treatment schemes between institute (eg patients may be given different drugs based to their disease progression according to institute policies).

Let me know if there is anything I can do to clarify things! And thanks for all your work!

2

Hi Nick - thanks for bringing up an interesting discussion. As you mentioned, it is not uncommon to have a factor as both fixed and random effect but we are yet to encounter such a scenario in our own studies, which was the reason behind the exclusive design we adopted for MaAsLin 2. As you have alluded to, this special scenario needs to be considered in a dataset-specific manner and needs careful consideration which was the other reason for going with the current infrastructure.

Having said that we agree that there should be a way to handle this situation and the solution you provided is correct. I will add a note to add this to our list of improvements for the next iteration either in the tutorial or in the code itself.

Thanks for flagging,
Himel

3

Hi @himel.mallick ,
Thanks so much for reply! Great to have this all spelled out, thanks so much for the clarification.

Nick

1 Like