Parliament2 runs a combination of tools to generate structural variant calls on whole-genome sequencing data. It can run the following callers: Breakdancer, Breakseq2, CNVnator, Delly2, Manta, and Lumpy. Because of synergies in how the programs use computational resources, these are all run in parallel. Parliament2 will produce the outputs of each of the tools for subsequent investigation.

Address of the bookmark: https://github.com/dnanexus/parliament2

Address of the bookmark: http://pacb.com/blog/the-hifi-difference-true-long-reads-vs-synthetic-long-reads/

A recent study published in Genome Biology (https://link.springer.com/article/10.1186/s13059-026-04280-y) addressed this challenge by introducing dicast (https://github.com/burgshrimps/dicast), a machine-learning approach for detecting structural variants in short-read sequencing data. Structural variants, such as large deletions, insertions, duplications, and inversions, can have significant biological and clinical implications, yet they are challenging to identify with short-read technologies. Because different detection methods frequently yield divergent results, researchers commonly employ consensus calling, considering a variant valid only if multiple tools detect it. While this approach reduces false positives, it relies on the potentially flawed assumption that the majority is always correct.

The researchers explored the impact of evaluating the supporting evidence for each variant, rather than simply tallying the number of algorithms that identified it. To establish a ground truth, they analyzed nine genomes using multiple sequencing technologies and 15 detection methods, initially identifying approximately 35 million potential variants. Through extensive filtering, evidence integration, and manual review of over 11,500 variants, they developed a robust benchmark comprising more than 236,000 structural variants. The findings underscored the complexity of the problem: short-read methods detected fewer than half of deletions and less than 10 percent of insertions, with performance declining markedly in repetitive genomic regions. In contrast, long-read technologies demonstrated superior detection capabilities. However, replacing the substantial volume of existing short-read data in clinical and research settings is not immediately feasible. Consequently, the researchers questioned whether short-read data might harbor more information than conventional analytical pipelines currently extract.

This line of inquiry led to the development of dicast. Rather than merely confirming agreement among multiple tools, dicast identifies patterns in sequencing data, including split and clipped reads, discordant read pairs, alignment characteristics, and the surrounding genomic context. An XGBoost machine-learning model evaluates which combinations of these signals are indicative of genuine structural variants. Thus, the approach shifts from tallying algorithmic consensus to interpreting the underlying evidence.

The researchers subsequently conducted a targeted evaluation by examining structural variants detected by only a single short-read tool, which are typically missed by consensus-based approaches. dicast successfully recovered approximately 81% of these single-caller deletions, insertions, and duplications. The signals for these variants were present in the data, but conventional filtering methods failed to integrate them effectively.

The utility of dicast was further demonstrated in cohorts with rare diseases, including congenital limb malformations, atrial fibrillation, and neuromuscular disorders. In one instance, dicast achieved a deletion recall rate of approximately 0.96, compared to 0.74 using consensus calling. The median number of variants requiring manual review was 29 per sample. Among 31 experimentally validated variants that standard filters would have missed, dicast identified 12, whereas consensus calling detected only one.

Overall, dicast identified approximately 20 percent more potential disease-causing deletions than consensus-based methods. While a 20 percent increase may appear modest, in clinical genomics such improvements can have significant practical implications. Missing a deletion may leave a case unresolved, whereas detecting a structural variant can provide critical diagnostic insights.

The study does not claim that machine learning has rendered short-read sequencing superior to long-read approaches. Instead, the results underscore the effectiveness of long-read sequencing for structural variant detection. However, dicast highlights a more nuanced perspective: substantial biological information may still be recoverable from the extensive short-read datasets already available.

The principal lesson extends beyond the detection of structural variants. For many years, bioinformatics pipelines have relied on threshold-based criteria, such as minimum coverage, quality scores, or support from multiple tools. While these rules are useful, biological phenomena do not always conform to rigid checklists; multiple weak signals, when considered collectively, can provide compelling evidence.

This perspective prompts consideration of the solitary variant: one algorithm identifies it, while several others do not. Traditional consensus techniques might have dismissed it, yet machine learning approaches evaluate the available evidence to determine whether the variant is plausible.

Occasionally, the most significant variant within a genome is the one that is almost universally overlooked.

Read more at https://link.springer.com/article/10.1186/s13059-026-04280-y

minimap -t 24 assembly.fasta long_reads.fastq.gz | racon -t 24 long_reads.fastq.gz - assembly.fasta racon_assembly.fasta
nucmer -p nucmer assembly.fasta racon_assembly.fasta
show-snps -C -T -r nucmer.delta

This reports Racon's changes in a table. You can exclude indels with the -I option in show-snps. 

This process (Racon -> MUMmer -> SNP table) solves the problem I originally raised in this issue. So as far as I'm concerned, you can close this issue (or keep it open if you still want to implement some kind of variant table).

We accomplish this by first calculating genotype likelihoods for every site. For a given site in a diploid genome, there are 10 possible genotypes (AA, AC, AG, AT, CC, CG, CT, GG, GT, TT). Referee takes as input the genotype likelihoods calculated for all 10 genotypes given the called reference base at each position.

Referee is a program to calculate a quality score for every position in a genome assembly. This allows for easy filtering of low quality sites for any downstream analysis.

https://github.com/gwct/referee

Address of the bookmark: https://gwct.github.io/referee/#

A swift, versatile phylogenomic and high-throughput sequencing simulator https://jackalope.lucasnell.com

Address of the bookmark: https://github.com/lucasnell/jackalope

More at https://kevlar.readthedocs.io/en/latest/

https://www.cell.com/iscience/pdf/S2589-0042(19)30259-7.pdf

Address of the bookmark: https://github.com/kevlar-dev/kevlar

Tasks:  239 total,   1 running,  238 sleeping,   0 stopped,   0 zombie

This line tells you how many processes are running. If you are using laptops machines it’s not so interesting because you really are the only one using this machine.

Cpu(s):  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st

This line contains the CPU load. The first two numbers are how busy the system is doing computation (“us” stands for “user”) and how busy the system is doing system-y things like accessing disks or network (“sy” stands for “system”). We’ll talk more about this later.

Mem:   49457320k total,    3492174k used,  14535596k free,    1435148k buffers

This should be easy to understand – how much memory you’re using!

Swap:   539356k total,   28332k used,   836562k free,    29862014k cached

Swap is just on-disk memory that can be used to “swap” out programs from main memory. Again, we’ll talk about this later.:

PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
  1 root      39   19  0  0  0 S  0.0  0.0   246:57.22 kipmi0
  2 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 migration/0

And... finally! What’s actually running! The two most important numbers are the %CPU and %MEM towards the right, as well as the COMMAND. This tells you how compute- and memory-intensive your program is. Right now, nothing’s running so the numbers aren’t very interesting, but just wait until we run something...

This page is a HOWTO guide for setting up a SLURM installation, currently focused on a CentOS 7 Linux OS. Please send feedback to Ole.H.Nielsen /at/ fysik.dtu.dk.

See the SLURM homepage (also https://computing.llnl.gov/linux/slurm/).

Address of the bookmark: https://wiki.fysik.dtu.dk/niflheim/SLURM

Pockets Identification

CASTp

Pocket-Finder

PocketPicker