Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Check that indices can be specified as expected #393

Open
grst opened this issue Nov 7, 2024 · 7 comments
Open

Check that indices can be specified as expected #393

grst opened this issue Nov 7, 2024 · 7 comments
Labels
bug Something isn't working

Comments

@grst
Copy link
Member

grst commented Nov 7, 2024

Description of the bug

Specifying indices should work as expected from a nf-core pipeline, i.e.

  • igenomes should be respected
  • it shall be possible to specify pre-computed indices and they shall be actually used
  • it shall be possible to generate indices from fastq/gtf otherwise.

There are a couple of issues related to that and it's probably best to address them all in one go and add tests where it makes sense.

Related issues:
#390
#339
#345

Command used and terminal output

No response

Relevant files

No response

System information

No response

@grst grst added the bug Something isn't working label Nov 7, 2024
@grst grst added this to scrnaseq Nov 7, 2024
@github-project-automation github-project-automation bot moved this to Todo high priority in scrnaseq Nov 7, 2024
@kopichris
Copy link
Contributor

Happy to look into this if the issue is still open 👍

@grst
Copy link
Member Author

grst commented Nov 22, 2024

It would be great if you could take a look, but it's better to wait until #369 is merged because @fmalmeida already made some changes to this (but without the aim to address this entirely).

If you already want to get started, you could also try out the branch from #369 - It would anyway be good to get some additional feedback on this because it entails quite some changes.

@kopichris
Copy link
Contributor

Happy to play around with the #369 branch until it gets merged, thanks for the heads up!

@grst
Copy link
Member Author

grst commented Dec 2, 2024

#369 is merged now. I actually think that most/all points are adressed above. @kopichris, would you be up for testing the behavior and check if there are still some pain points?

@kopichris
Copy link
Contributor

That's great news! I'll test the behavior of #369 and report back by Friday!

@kopichris
Copy link
Contributor

Hi @grst, I reviewed and tested the following issues from the dev branch:

[#330]: I ran the test,conda profile and received the following error in the NFCORE_SCRNASEQ:SCRNASEQ:H5AD_CONVERSION: ANNDATAR_CONVERT process: Error in library(anndataR) : there is no package called ‘anndataR’. I suspect this is because there is no conda recipe in the ANNDATAR_CONVERT process.

[#339 and #345]: Pipeline completed successfully when specifying the --fasta and --gtf parameters.

[#366]: Pipeline completed successfully when using the test_full,docker profile with the --skip_emptydrops parameter. Pipeline failed on time when running with emptydrops. This was likely because the emptydrops workflow is optimized for GPUs, which I don't have on my system. It may be worth skipping the emptydrops workflow by default in the test_full profile.

Anything else you think we should look at?

@grst
Copy link
Member Author

grst commented Dec 11, 2024

I ran the test,conda profile and received the following error in the NFCORE_SCRNASEQ:SCRNASEQ:H5AD_CONVERSION: ANNDATAR_CONVERT process: Error in library(anndataR) : there is no package called ‘anndataR’. I suspect this is because there is no conda recipe in the ANNDATAR_CONVERT process.

Yes, this is expected as anndataR uses a custom container for now. So running with the conda profile is currently not supported (same as for cellranger).

[https://github.com//issues/366]: Pipeline completed successfully when using the test_full,docker profile with the --skip_emptydrops parameter. Pipeline failed on time when running with emptydrops. This was likely because the emptydrops workflow is optimized for GPUs, which I don't have on my system. It may be worth skipping the emptydrops workflow by default in the test_full profile.

That's a good point! Cellbender should still finish on CPU if one throws enough cores and time at it, but I think you are right and we should disable it at least for the test profile.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
Status: Todo high priority
Development

No branches or pull requests

2 participants