Describe the bug
When supplying multiple BAMs but no "target", the program has no defined behaviour.

Expected behavior
Should quit erroring

Hi guys I'm trying to use your tool but every option I try to put return this error. invalid integer: "everything"
I'm using the latest versione 2.7 isntalled with Conda.

First I tried with: bamtocov -w -o -T 24 sorted.bam > coverage.wig
and the error was invalid integer: -o
then I removed -o and I have the error invalid integer: -T
then I tried to write --threads instead of -T and invalid integer: --threads
then I left only the -w and the error was invalid integer: sorted.bam

So after some bestemmie I left only the basic command bamtocov sorted.bam > coverage.bed and it works.
Is it a common issue for you?

Hi!
I'm trying you strand coverage calculator, using the command:
bamtocov -s alignment.rg.clipped.recalibrated.bam > stranded_cov.txt
But I couldn't found any indication about the strand output, is the first column the forward and the second column the reverse?
Thanks

Related to #2

A future release can generate a whole chromosomes target if no target is explicitly provided.
Or provide this option with a dedicated parameter (probably better)

Describe the bug
When specifying --report but omitting --regions unconsistent report is produced (dev("t not in index: " & t))

Expected behavior
Error and quit

Is your feature request related to a problem? Please describe.
In most of the IP-based methods, we need to extend reads to the fragment size to get the correct coverage for real IP regions if we sequence in a single-end mode.

Describe the solution you'd like
Add similar arguments with "--extendReads" from bamCoverage of deeptools would be a very good option.

Describe the bug
Dear bamtocov team,

I have human WES data and am trying to run bamtocov. After 6 hours, not even half is done/calculated, even when using 24 threads. Maybe I am missing something?

To Reproduce
bamtocov EF_V1_S9.MD.sorted.bam --regions Targets_hg38.bed --threads 24 --mapq 20 > EF_V1.cov

Expected behavior
From the paper I gather it should run a lot faster than 6 hours.

System information (please complete the following information):

• OS: Linux
• Browser [e.g. chrome, safari]
• Version: 2.7.0

It is often useful to see if reads horizontally cover a certain percentage of a locus' length. Existing tools (bedtools coverage) are too slow/memory-consuming with unsorted BAMs.

@telatin Dear Dr. Telatin,

I'm curious about how bamtocov deal with paired-end bam from stranded libraries by setting with --stranded.

Will bamtocov automatically treat mated reads as reverse strand? For example, if mate1 of a fragment was recorded as '-' strand in bam, which means that mate1 are actually comes from '+' strand. When setting with --stranded, mate1 will be counted as '+' strand. My question is, will mate2 of this fragment be automatically counted as '+' strand as well in this case?

Also, will the new '--extendReads INT' parameter also work well with paired-end bam?

Best,

Keren

Describe the issue
bamtocov file.bam generated "ERROR: coverage went backwards from 0 to 0"

System information (please complete the following information):

• UBUNTU 20.04 app

Additional context
I do not know what the error means. I generated bam file using minimap2 in Galaxy and I successfully visualized the bam file in IGV.

Thank you in advance.