Hi, thanks for this very useful tool.
I’d like to report an issue that initially looked like the Bowtie2 index step getting stuck, but after further investigation seems to be related to high parallelism rather than a hard crash.
When installing a genome with the Bowtie2 plugin enabled, I observed that the Bowtie2 index creation step starts normally and temporary/index-related files are created. However, after that, the process does not proceed to the next step or finish for a very long time, and no further log lines are printed. From the outside, it looks as if the process is stalled.
After debugging, I found that this behavior strongly correlates with the number of threads used. With a high thread count (e.g. --threads 20), the Bowtie2 index step can remain in this “temporary files created but not completed” state for many hours. In contrast, rerunning the same step with fewer threads (e.g. 6 threads) completes successfully in a reasonable amount of time.
This makes me suspect that high parallelism may interact poorly with the downstream process or wrapper logic, leading to extremely slow progress or an apparent hang after temporary files are generated. This seems more like a parallelism/scaling issue than a functional bug, but it can be quite confusing from a user perspective.
For reference, my environment is:
OS: Windows 11 Pro for Workstations 24H2
Linux environment: WSL2 (Ubuntu 24.04.1 LTS)
CPU: AMD Ryzen 9 9950X 16-Core Processor
Motherboard: GIGABYTE X870E AORUS MASTER
Memory: 256 GB DDR5 (4 × 64 GB G.SKILL modules, 5800 MT/s)
Storage: NVMe SSD (Samsung 990 PRO 2TB / ZHITAI TiPlus7100 4TB)
Even on this hardware, using a high thread count caused the Bowtie2 index step to appear stuck, while lowering the thread count resolved the issue.
It might be helpful to document recommended thread limits for Bowtie2 indexing (for example, 4–8 threads), or to guard against overly high thread counts, especially on WSL2, to avoid this confusing behavior.
Thanks again for the tool and for your time.
Hi, thanks for this very useful tool.
I’d like to report an issue that initially looked like the Bowtie2 index step getting stuck, but after further investigation seems to be related to high parallelism rather than a hard crash.
When installing a genome with the Bowtie2 plugin enabled, I observed that the Bowtie2 index creation step starts normally and temporary/index-related files are created. However, after that, the process does not proceed to the next step or finish for a very long time, and no further log lines are printed. From the outside, it looks as if the process is stalled.
After debugging, I found that this behavior strongly correlates with the number of threads used. With a high thread count (e.g. --threads 20), the Bowtie2 index step can remain in this “temporary files created but not completed” state for many hours. In contrast, rerunning the same step with fewer threads (e.g. 6 threads) completes successfully in a reasonable amount of time.
This makes me suspect that high parallelism may interact poorly with the downstream process or wrapper logic, leading to extremely slow progress or an apparent hang after temporary files are generated. This seems more like a parallelism/scaling issue than a functional bug, but it can be quite confusing from a user perspective.
For reference, my environment is:
OS: Windows 11 Pro for Workstations 24H2
Linux environment: WSL2 (Ubuntu 24.04.1 LTS)
CPU: AMD Ryzen 9 9950X 16-Core Processor
Motherboard: GIGABYTE X870E AORUS MASTER
Memory: 256 GB DDR5 (4 × 64 GB G.SKILL modules, 5800 MT/s)
Storage: NVMe SSD (Samsung 990 PRO 2TB / ZHITAI TiPlus7100 4TB)
Even on this hardware, using a high thread count caused the Bowtie2 index step to appear stuck, while lowering the thread count resolved the issue.
It might be helpful to document recommended thread limits for Bowtie2 indexing (for example, 4–8 threads), or to guard against overly high thread counts, especially on WSL2, to avoid this confusing behavior.
Thanks again for the tool and for your time.