Re: broken pipe when both -1 and -2 are gzip files

[Chris Miller]

Hi,

If you read --help, you will note that only the first reads file (-1) may be gzipped, currently.

Sorry for the inconvenience.

Chris

On Tuesday, June 4, 2013 11:56:49 AM UTC-6, Kevin Chen wrote:

Hi, was testing it but found such error.

below is partial logs:

gzip: stdout: Broken pipe

subprocess.CalledProcessError: Command 'gzip -dc  /local/scratch/kevin/00_input/test_R1.fastq.gz |  bowtie --phred33-quals -t -p 8 -n 3 -l 20 -e 300 --best --sam --chunkmbs 128 --minins 101 --maxins 723 /local/db/EMIRGE_db/SSU_candidate_db -1 - -2 /local/scratch/kevin/00_input/test_R2.fastq.gz | samtools view -b -S -u -F 0x0004 - > /local/scratch/kevin/01_output/initial_mapping/initial_bowtie_mapping.PE.bam ' returned non-zero exit status 1

Thanks,

[Chris Miller]

Hi,

Paired-end data should be "fully paired," as you put it.  That is, paired reads should exist in the same order in the input read 1 and read 2 files, and every read should have a paired read in the opposite file.  This is a requirement of EMIRGE and the current underlying read mapper, bowtie.  Without this, I'm not sure how bowtie will respond.  Possibly:
error and failure
or, silently fails to align most paired reads.

You can use a trimming tool such as sickle to trim reads and only submit remaining paired reads to EMIRGE.

Chris

On Tuesday, June 4, 2013 1:18:20 PM UTC-6, Kevin Chen wrote:

Thanks, Chris. It is my bad for didn't read it carefully.

Another question, what will happen if my so call paired-end data are not fully paired?

for example, 

f1.fq

@SN:0001/1

@SN:0002/1

@SN:0003/1

f2.fq

@SN:0001/2

@SN:0003/2

Kevin