Closed brianpenghe closed 2 years ago
Hi @brianpenghe! Thanks for using ArchR! Please make sure that your post belongs in the Issues section. Only bugs and error reports belong in the Issues section. Usage questions and feature requests should be posted in the Discussions section, not in Issues.
Before we help you, you must respond to the following questions unless your original post already contained this information:
1. If you've encountered an error, have you already searched previous Issues to make sure that this hasn't already been solved?
2. Can you recapitulate your error using the tutorial code and dataset? If so, provide a reproducible example.
3. Did you post your log file? If not, add it now.
Thanks for reminding. Just added the log file. I'll give it a try using the tutorial dataset.
Interestingly using the pre-subset ArchR worked. So there must be something wrong with the subsetting function.
I really need you to provide more information in your issue posts.
Interestingly using the pre-subset ArchR worked. So there must be something wrong with the subsetting function.
This logic doesnt hold up. Are you saying that the pre-subset tutorial project works BUT a post-subset tutorial project doesnt work? That might indicate something wrong with the subsetting function. If you get an error with the tutorial dataset, then provide a reproducible example.
OK I used the tutorial dataset and the error is gone. Probably something else wrong in my dataset. Thanks!
Hello, I encountered a similar issue while using the getGroupBW function and managed to identify a potential bug related to the calculation of the number of tiles (nTiles). Specifically, if a fragment is located at the very end of a chromosome, the expression trunc(end(fragik) / tileSize) + 1 can mistakenly result in nTiles + 1 instead of nTiles. I resolved this issue by modifying the indexing in the following manner:
i <- pmin(pmax(c(trunc(start(fragik) / tileSize), trunc(end(fragik) / tileSize)) + 1, 1), nTiles)
This change ensures that the index remains within the correct bounds, thus preventing any overflow errors. The error disappeared after applying this modification.
I solved this issue by dropping levels which are not present in the column used for groupBy
argument of getGroupBW()
.
I was running getGroupBW to save bigWig files but got these errors:
What's interesting is that this object is a subset of another object that should only have 66 cell types but it seems that it is scanning through 88 cell types that the pre-subset object altogether has. I used the subsetArchRProject function.
Is it actually related to all the other errors I had ???
Thanks!
ArchR-getGroupBW-703d349bd3-Date-2021-12-02_Time-22-40-55.log