fritzsedlazeck / nibsv

Kmer based genotyper for short reads.

NibblerSV

Fading out to https://github.com/brentp/nibsv <--

Intro

nibsv genotypes base-resolved structural variants by counting the occurence of novel k-mers generated at the break-points.

This means that nibsv has very high specificity, but because there are some SVs that do not generate novel k-mers, it can have a lower sensitivity.

Usage

To run nibsv, download the static binary from the releases and run as:

nibsv -o ${genotyped_vcf} \
  -k 13 --space 17 --space 18 \
  ${sites_vcf}  ${bam_or_cram} ${reference_fasta}

Full usage:

[nibsv] version: 0.0.2 commit: b1b9e06937d519fed27f9032b26a285367106354
nibsv

Usage:
  nibsv [options] vcf bam ref

Arguments:
  vcf              SV vcf with sites to genotype
  bam              bam or cram file for sample
  ref              reference fasta file

Options:
  -k=K                       kmer-size must be <= 15 if space > 0 else 31 (default: 27)
  --space=SPACE              space between kmers (can be specified multiple times)
  -o=O                       output vcf (default: nibsv.vcf.gz)
  --cram-ref=CRAM_REF        optional reference fasta file for cram if difference from reference fasta
  -h, --help                 Show this help

Contributors

Brent Pedersen¹, Christopher Dunn², Eric Dawson³, Fritz Sedlazeck⁴, Peter Xie⁵, and Zev Kronenberg²

¹ University of Utrecht; ²PacBio; ³Nvidia Corporation; ⁴Baylor College of Medicine; ⁵JBrowse (UC Berkeley);

nibsv's Issues

running nibSV

Hi there, I just tried to make it work on OS X. I installed nib first using homebrew (after a bit of wrestling of installing from the source), and in the end nib seems to work for me now. Then both steps of nibSV installation also seemed successful by log, but then when I execute ./src/nibsv it complains about a problematic library (the same I get when I execute the example).

./src/nibsv --help
could not load: libhts.dylib
(compile with -d:nimDebugDlOpen for more information)

Don't even know where to start looking... I never tried to get a nib program to work, so it might be something really basic :-)

far fetched tought

So, I just submitted the report.

I gave up on testing everything, but I tried to at least give every tool a fair thought, so I ended up with a really long one. So in the end I tried to cut on things that we too far fetched and this is the one I had for nibSV:

Then I had this far fetched thought. I see the process somewhat analogous to how salmon/kallisto work with assigning reads to individual transcripts. The difference is that salmon/kallisto operate on kmer graphs and treating reads as a consecutive sequences of kmers when trying to find the most likely source transcript for each read. How much different it would be for nibSV build a (de Brujin?) graph, instead of the kmer dictionary? Taking the order of kmers into account would then allow using also kmers that are found in other genomic regions but in different local contexts (i.e. you would probably not need the kmer filtering step). Furthermore, treating each read as haplotype-specific set of kmers could also help to genotype heterozygous variants. I presume there would be a computational cost to building a graph, but I am pretty sure that salmon/kallisto scale very well to enormous reference sizes and depths of sequencing libraries hence it might be almost as fast as the current nibSV approach. Is that completely unreasonable?

how do we build this now?

The makefile was deleted, so I'm not sure how this is supposed to be built anymore. Brent, could you add something to the README?

Fritz, Eric needs a new invitation to this repo