Any thoughts? I'm posting here to look for bioinformatics tools that would benefit from a speed up. But if it's more general command-line tools that tend to be bottlenecks, list those too.
If you want to list more or less than three, that's fine too, of course. If possible, prioritize them in order of impact on your daily life. I'm hoping this can be a resource for all those who, like me, might be interested in helping to speed up some tools.
•
written
by
dhbradshaw
7 answers
In the interest of offering useful leads:
1) The neural networks used for MHC Class I and II epitope binding prediction. (sadly, most are not open source - see http://tools.iedb.org/mhci/ )
2) Variant annotation with VEP. It's an amazing tool, but is relatively slow.
3) Variant calling, especially for indels. Pindel, in particular, seems to often be a bottleneck in our pipelines.
Really interesting code and applications here. MHC binding application is broken form me -- the url needs the leading http://.
Do you use all the tricks to speed up sort? See discussion on Any Quick Sort Method For Large Bed File As 20G In Size?.
I would like to name these:
- TrimGalore (https://www.bioinformatics.babraham.ac.uk/projects/trim_galore ) - No parallel processing
- Trinity (https://github.com/trinityrnaseq/trinityrnaseq/wiki )
- MAKER (http://weatherby.genetics.utah.edu/MAKER/wiki/index.php/MAKER_Tutorial_for_GMOD_Online_Training_2014 )
I wish denovo tools such as last 2 were faster..
Can you annotate this list a little bit for outsiders like me? Also, I'm trying to understand priorities here since it looks like 1 should be the priority but then you seem to call out the last 2. Or are you saying that there are other de novo tools that you would list as well?
But doesn't it support only paired-end data? "Skewer: a fast and accurate adapter trimmer for next-generation sequencing paired-end reads" (https://bmcbioinformatics.biomedcentral.com/articles/10.1186/1471-2105-15-182)
Sure @dhbradshaw. I should have done that. As we have got alternative for TrimGalore (Skewer). I would like to omit it now.
Trinity is for de novo reconstruction of transcriptomes from RNA-seq data. We can mention Threads & memory in it. But still, it takes too much time even on a machine with 256GB memory & 32 cores. It took almost around 48-60 hrs to process 600GB data.
MAKER is basically used for de novo annotation of newly sequenced genomes. It runs HMM modelling in the background. I guess that's might be one of the reason for slowing it down. Threading is available for this too..
Out of curiosity, how do you normally run mpileup? - piped into bcftools call? I recently got back to DNA-seq after a sabbatical of 4 years away from it.
Here's another one: Bam-readcount, which is fairly fast, until you try to get counts/info for 3M SNPs from a WGS bam file https://github.com/genome/bam-readcount
miRanda for miRNA target prediction! Though, there is a CUDA implementation available but I don't think it's possible for everyone.
- genome assembly tools (de novo)
- sequence alignment tools (such as bowtie)
Log in to answer this question.
-
Job: 2025 Arrowhead AI/LLM for Computational Biology and Data Science Internship
written by Shicheng Guo
-
News: Course: Advance your Python Skills for Life Sciences
written by Transmitting Science communication •
-
News: Course: Structural Variant Detection and Comparison
written by Physalia-courses
-
News: Online course on Reproducibility Data Analysis with R
written by Physalia-courses
-
How to get the minimun branch distance tree?
written by Destineador •
-
News: Get Ensembl training, virtually
written by Emily
-
Compiling a list of MPI-compatible tools
written by Dave Carlson
-
Tutorial: Continuing Education (Pipelines): Best blogs, Online Lectures, Workshops, etc..
written by jnowacki
-
Forum: RNA seq time course data experiment design
written by raina.kumar •
-
Forum: A Universal/Common Biorep System
written by Obi Griffith
One thing to consider is that for lots of operations on "big data" sets, disk I/O is the limiting factor (or even network speed), so speeding up the code may not help!
Architecture speedups are just as interesting and challenging as code speedups. So maybe I/O bound applications are worth listing as well.
But they can potentially cost significantly more :)
BTW: You must have something on your list, why not include those programs in your original post.
I don't have anything on my list; that's the problem!
I'm a physicist turned coder (like half the world, it seems). Outside of Rosalind and Coursera, I've never done any bioinformatics. But I've learned that I like speeding things up and I thought it would be fun to find out where I could make a practical contribution using that interest.
However, if it turns out that there aren't any tools that people wish were faster, then that's useful data too.
As @Chris has already indicated a lot of high throughput sequence data requires massive I/O which ultimately turns out to be a bottleneck.
There are many software packages that probably use routines that can use optimization from a master coder to make them run more efficiently (e.g. see this recent call from a fellow BioStar Call for requirement: a fast all-in-one FASTQ preprocessor (in C++, multi-threaded) ). Variant callers take a long time to process data and may be good candidates (freebayes is one example).
Thanks for these two leads.
I/O has indeed become one of the biggest holdups. The community gave a lot of attention to CPU parallelisation in recent years and now we have a lot of functions for which parallelisation is enabled, and it's also easy to implement on old code written for single thread/CPU processing via forking. It's feasible to analyse multiple whole genome samples in a single day these days.
That said, it still takes >24 hours to back-up 1.5 terabytes of data (my personal and work files since 2000).
As I'm Irish, I'll also throw some humour into the discussion: years ago (2013) I attempted to back up ~2 terabytes of data from a local heavy-duty hard-disk (whole genome seq) to a NFS 'storage' drive on the same network. Windows came back with a predicted time of 154 years for it to complete, at which point my own mortailty was instantly thrown into question.
That just what bad programmers want you to believe. ;)
Do you have a preference for a language? Probably important to mention.
Rust -- I'd probably write anything over from scratch. So maybe smaller is better to start :-D
dhbradshaw : As you can see we are all over the place with these wish lists.
If you are really a master programmer then your best bet is to have a developer of one of these tools contact you with very specific request(s) about accelerating parts of their code. If that will happen remains to be seen :-) I assume you have a limited amount of time available to dedicate to this sort of thing.
That path makes sense and is interesting.
I haven't claimed and will not claim to be a master developer.
But I don't think that's what's called for. What's called for is someone who will focus on a specific problem, read and get advice, think through the algorithm candidates and the effects of scaling on speed, make measurements, and iterate their way toward greater speed. It's more about work than about being a master developer. It's more about doing than about being.
It's important to realize that because if you don't then you miss out on opportunities to make contributions. And you don't grow toward "mastery" like you otherwise would either.
You have clearly done this before and are pragmatic. Hopefully you will be able to find an interesting project out of the several mentioned here to work on. If you are going to start new then something to do with variant calling/annotation would be immediately useful, as has been said elsewhere here. Let us know if you need introductory materials on that topic.
Combining your feedback with that of Chris Miller and others points with a fairly high signal toward variant calling and annotation. So I'm on board.
And yes, please! I do indeed need introductory materials on everything variant related.
Here is some material to get you started (sorry I missed this post). Video 1 and Video 2.
If I could double or triple the speed or throughput of my workplace coffee machine, this certainly would have the greatest impact on my daily life and productivity.
If you can find the source code for it then dhbradshaw will make it happen :)
I wish I had a 3D printer:
https://grabcad.com/library/coffee-machine-for-office-1
https://www.cadblocksfree.com/en/commercial-coffee-machine.html
And many more! I wonder if they really work.