run.zinba() requests base alignment file when refinepeaks=0; attempt to run basealigncount() kills R

[GoogleCodeExporter]

1) What operating system are you using?

2) What error message was displayed?

3) What was the exact command you used that resulted in the error?

4) Please copy and paste any additional screen output that resulted from
running the command

Running R 3.0.1 Good Sport on Red Hat Enterprise Linux Server release 6.4 
(x86_64-redhat-linux-gnu)
Using Zinba 2.02.03 release
Using max-memory queue in an interactive session

> run.zinba(seq='FGC0845_AGGCAGAA.filter.sam', refinepeaks=0, 
filetype='bowtie', align='align36_mm9/', twoBit='mm9.2bit', winSize=300, 
offset=75, outfile='FGC0845_AGGCAGAA.zinba', threshold=0.2, extension=300, 
FDR=FALSE)

Error in run.zinba(seq = "FGC0845_AGGCAGAA.filter.sam", refinepeaks = 0,  : 
  path to read overlap file 'basecountfile' must be specified

> basealigncount(inputfile="FGC0845_AGGCAGAA.filter.sam", 
outputfile="FGC0845_AGGCAGAA.bac", extension=300, filetype="bowtie", 
twoBitFile="mm9.2bit")

<massive error flood>

Aborted (core dumped)

Original issue reported on code.google.com by pikalax...@gmail.com on 12 Aug 2014 at 4:53

[GoogleCodeExporter]

Update: Attempt to run Zinba on R 3.1.1 "Sock it to Me" on platform 
x86_64-apple-darwin10.8.0 (64-bit) recognizes the genome and loads the reads 
(sorted as SAM and converted to Bowtie format).  Here are the last three lines 
of output:

> basealigncount(inputfile='./FGC0845_AGGCAGAA.filter.bwt', 
outputfile='./FGC0845_AGGCAGAA.filter.bac', extension=300, filetype='bowtie', 
twoBitFile='mm9.2bit')

Note:  8 bowtie columns detected, ignoring 8th column
Stopping basealigncounts
-------- BASE ALIGN COUNTS EXITING WITH ERRORS --------

Original comment by pikalax...@gmail.com on 12 Aug 2014 at 9:00

[GoogleCodeExporter]

Alright, so a couple of things went wrong...

1) I tried to run a SAM file through Zinba.  This is not an accepted format, 
hence why on my second attempt, I converted to Bowtie output.  I was in SAM for 
the purpose of using Picard, which requires SAM.

2) My reads had been sorted by coordinate in order for Picard to remove 
duplicates.  This had the unfortunate effect of splitting up read pairs, and 
Zinba had problems with that.  Reordered by read name (not quite the original 
ordering, but at least it reunited mated reads).

After fixing 1 and 2, I managed to get Zinba running.  Though there's still the 
problem of it requiring the basecounts file when refinepeaks=0.  I'll keep this 
open for that reason.

Original comment by pikalax...@gmail.com on 13 Aug 2014 at 12:48

[GoogleCodeExporter]

Attaching an update that fixes this problem.  I am going to include a sam file 
option in the next version, and yes it would have to be name sorted 
unfortunately to keep read pairs together.  The validity of the mappability 
file used by zinba (generated from peakseq) will be questionable however (maybe 
not necessary if each pair maps properly and distance near expected fragment 
length?)

Original comment by homer...@gmail.com on 26 Jan 2015 at 4:54

[GoogleCodeExporter]

Original comment by homer...@gmail.com on 26 Jan 2015 at 4:54

• Changed state: Accepted

Attachments:

• zinba_2.03.1.tar.gz