How the genes annotated as strongly selected were calculated?

Hi,
I used the code provided in the link below to calculate the LRT (LRT calculation code used by the DepMap portal · GitHub), but the results are not exactly the same as the results in the table you provided (https://depmap.org/portal/api/download/gene_dep_summary). For crispr, I choose the dataset named DependencyEnum.Chronos_Combined to mapping the results. The dataset I used for the calculation was CRISPRGeneEffect_Q4.csv.

May I ask if you have done anything else with the data? Thank you very much.

Best,
danwei

It appears that I started to reply to this message but never posted a response.

I wonder if what you’re encountering is something that I too recently experienced: using the latest versions of R and the dependent libraries causes the LRT code to produce different results. I found this surprising and when I investigated, the source of the discrepancy seemed to be due to the optimization step where the LRT code it trying to find parameters for the skewed-t distribution. For reasons that I didn’t fully investigate, doing a fresh install of R and all the libraries gives different results then the versions that we use on the portal. (The portal precomputes these using a docker that has all of the versions of these libraries frozen. We discovered this problem when we recently attempted to create a new version of this docker image.)

This is unfortunate but not entirely surprising as the skewed-t model fit procedure appears to not be terribly robust even ignoring variation from different versions of R (if you look in the LRT code that we’re using, we resort to trying the fitting procedure with multiple initial conditions in an attempt to get a decent fit.) What I saw was using an updated version of R, that the values were correlated, but clearly different (and often very different when the optimizer choose poor parameters for the skewed-t model).

We’ve considered moving away from using LRT because it has a few other undesirable properties in addition to not being very robust. However, we haven’t committed yet to a replacement.

Phil