Code hangs when using relmatGlmer about lme4qtl HOT 2 CLOSED

Hi,

I am afraid I don't have a ready solution for you, but I will share some thoughts on what you can try.

You can get more controls on timing with verbose argument. Here, a basic example:

library(lme4qtl)

data(dat40)

my_verbose <- 1 # 1, 2 or 3
gmod <- relmatGlmer(trait1bin ~ (1|ID), dat40, relmat = list(ID = kin2), family = binomial, verbose = my_verbose)

In principle, there is no any limits of the size of covariance matrices. Obviously, the bigger the matrix the slower computation. You should also think about how sparse your matrix is. In our preprint, Supplemental Figure 3 (right now), we showed that passing dense covariance matrices to lme4/lme4qtl is not a good idea in general. However, based on our practical experience, it took us 1-2 hours to analyse 3,300 individuals with relmatLmer and dense GRM.

Also, I haven't tested relmatGlmer extensively, but it is known that it generally takes more computation time than lmer / relmatLmer. Perhaps, you can google about your issues in relation to lme4.

As the last comment, I can see that the problem is to separate lme4qtl- vs. lme4-specific issues (dense covariance matrix vs. generalized models). One simple experiment would be to "sparsify" you covariance matrix (i.e. put all matrix elements, which are below some threshold, to zero) and run relmatGlmer to check the computation time. If it is feasible, that means the dense covariance matrix is an issue.

I hope my 5 cents will help you.

Best,
Andrey

from lme4qtl.

Hello Andrey,

Thanks so much for your input! RelmatGlmer worked after I set all of the matrix elements below 0.1 to zero so the issue is with the dense covariance matrix.

Thanks,

Emily

from lme4qtl.