Missing start=setting line in the core file generated by uniwig

[saanikat]

wigToBigWig gives me the following issue when I provide the .wig files generated by uniwig (dev branch):

Missing start= setting line 879394241 of /scratch/bam8pm/tlgl_atac/uniwig_wigs/_core.wig

It seems like some kind of a header line is missing in the core wig file generated by uniwig. The command I used to generate the wiggle files was:

cargo run uniwig -f /scratch/bam8pm/tlgl_atac/combined/combined_chrsort.bed -c /scratch/bam8pm/tlgl_atac/hg38.chrom.sizes -m 1 -s 1 -l /scratch/bam8pm/tlgl_atac/ -y wig -t bed

However, when I reset the dev branch to commit : 884e7b6 there is no issue with wigToBigWig indicating that the header start=setting line is generated in this case.

To reproduce this error, I have provided the bed file and the chrom sizes file :
/project/shefflab/brickyard/results_pipeline/tlgl_atac/combined_chrsort.bed
/project/shefflab/brickyard/results_pipeline/tlgl_atac/hg38.chrom.sizes

The command I used for wigToBigWig is:

wigToBigWig -clip /scratch/bam8pm/tlgl_atac/uniwig_wigs/_core.wig /scratch/bam8pm/tlgl_atac/hg38.chrom.sizes /scratch/bam8pm/tlgl_atac/tracks/all_core.bw

[nleroy917]

It seems like some kind of a header line is missing in the core wig file generated by uniwig. The command I used to generate the wiggle files was:

What does the header of the bad .wig file look like?

Also, unrelated but you should run with --release. It will be much faster. I like to just do:

cargo install --profile=release --path=gtars/

Then you can just run gtars:

gtars uniwig ...

[saanikat]

The line which is causing an issue (line 879394241) looks like this:

fixedStep chrom=chr4_GL000008v2_random start=0 step=1

For reference, this is what the other fixedStep lines in the same file look like:

fixedStep chrom=chr1 start=803560 step=1
fixedStep chrom=chr1_KI270706v1_random start=2752 step=1
fixedStep chrom=chr1_KI270707v1_random start=23913 step=1

wigToBigWig isn't throwing an error for these lines though.

[donaldcampbelljr]

Looks like it might be this commit:
9f96c8d

start must be > 0 for wigtobigwig, correct?

I reverted a change where I was clamping the start position for the core counts. It was causing other issues but I don't remember now what issues it fixed. You could re-add that line and see if it fixes your issue.

Alternatively, (and more recommended) you can use the newest changes in this branch:
https://github.com/databio/gtars/tree/dev_bam_bedgraph_bigtools

And simply set the output type to bw, skipping the intermediate wiggle step.