Tommaso Leonardi

Ideally scaling should be done for all kmers in a read to correct dwell-time shifts during the course of a run https://github.com/tleonardi/nanocompore/blob/62a8bf41712b5355519024786c5ba34b38ae36bb/nanocompore/TxComp.py#L195

Due to the way Nanocompore passes data between threads, when a transcript has a large amount of data associated with it (e.g. the transcript has very high coverage or is...

Data for the two conditions should be concatenated before scaling. As it is now, the two conditions are scaled separately, resulting in both conditions having mean 0. https://github.com/tleonardi/nanocompore/blob/9f8effec65cbd5347f5ac7e1625164389adad866/nanocompore/SampCompDB.py#L841-L848

When multiple transcripts cover the same genomic coordinates nanocompore reports multiples lines per genomic position

At the moment instead of throwing an exception we just add "!!!!" to the kmer.. It's a left over from an old debugging session, but now it needs to be...

Threads over-subscription

7

It looks like nanocompore sometimes spawns more threads than it should.. Starting it with nthreads=4 with the 7SK IVT data starts 16 threads.

Downsample to the same coverage as the lower coverage sample

2

Very different coverage between samples might causes troubles during GMM clustering. At the moment we can downsample to a fixed coverage level, but it would be great to downsample each...