Were you able to get a workaround of this? I have tried a few times running the glm.LRT in R studio server and it went on running over 30 mins a few times and I had to abort. Is there a workaround?
I'm having the same issue, it literally can take 1 hour or more to do a single call of glm.LRT() and I have only 50 samples. I do not understand how they could release a library that takes this long to do DEG on ~800 genes.
If someone has developed a workaround, including even modifying the NanoStringDiff source code glm.LRT() function which I have no problem doing, I would really appreciate it!!
I've given up on NanoStringDiff, it's basically unusable and can take HOURS just to do a simple DEG. Even though the authors mentioned in their paper that when there are counts >1000 in the dataset that the algorithm can be slow this is worse than slow it's a library that isn't usable at all. They should fix their algorithm, period.
I have the same problem and I figured out that problem was because positive control was not ordered in raw data that I got from the client (POS_C(8), POS_A(128), POS_F(0.125), POS_D(2), POS_B(32), POS_E(0.5)). NanoStringDiff assumes that positive control is ordered. I would recommend to order data by Code.Class and Name. After this change analysis for ~800 genes and ~20 samples took 30 minutes max.
Were you able to get a workaround of this? I have tried a few times running the glm.LRT in R studio server and it went on running over 30 mins a few times and I had to abort. Is there a workaround?
I'm having the same issue, it literally can take 1 hour or more to do a single call of glm.LRT() and I have only 50 samples. I do not understand how they could release a library that takes this long to do DEG on ~800 genes.
If someone has developed a workaround, including even modifying the NanoStringDiff source code glm.LRT() function which I have no problem doing, I would really appreciate it!!
I've given up on NanoStringDiff, it's basically unusable and can take HOURS just to do a simple DEG. Even though the authors mentioned in their paper that when there are counts >1000 in the dataset that the algorithm can be slow this is worse than slow it's a library that isn't usable at all. They should fix their algorithm, period.