[simonandrews]

Sorry to take a while to get back to you. I tried your sequences and they worked fine on my system. I also tried gzipping them and that worked OK too.

When fastq_screen runs it simply pipes the original file through zcat so in terms of the searches there's nothing different between normal and gzipped files. Could it simply be that you don't have zcat installed on your system (it's a standard part of gzip so it should be on most unix systems).

Can you try running 'which zcat' and see if that finds anything. If it doesn't then this is the problem, but I'd have thought that that would have returned a more sensible error message.

[albireo]

Hello,

the problem had to to with the gzip compression of my fastq files. When I unpacked the gz files and used the .fastq as input instead, the program run correctly. Any idea why that should be the case?

By the way the .fastq are very large, ranging from 7 to 12GB. I'm actually using the sampling function in fastqscreen to operate on 5000000 reads only, but I completed one successful run without subsampling as well.

[albireo]

If you run the screen against just the first of your paired reads do you find any hits from that? If you don't then there's probably something odd going on in the search.

Hi Simon, no I don't find any hits even using one of the paired reads.

[simonandrews]

Hi,
Any idea on what I might be doing wrong? Apologies if I'm missing something really obvious.

I can't immediately see why this would be going wrong from the data you've provided. If you run the screen against just the first of your paired reads do you find any hits from that? If you don't then there's probably something odd going on in the search. If you find hits from analysing each of the files as single end, but not when you pair them then that suggests that either something is going wrong in the pairing of sequences or that you have oddly separated pairs.

If you can put a subset of your sequences up somewhere where we can see them (just 100k or so would be plenty) then we could take a look and see what's happening with your data.

[albireo]

Hi,

I have a problem when running fastqscreen on mouse paired-end ChIPseq data. Basically for all of the four libraries I have, I'm getting more than 99% no hits in the final fastqscreen graph.

Mmus    99.96   0.02    0.02    0.00    0.00

The sequences I'm checking my libraries against are human, mouse, rat, fly, vectors, adapters. I downloaded the mouse mm9 fasta from the ucsc and generated the bowtie index with bowtie 0.12.7. The same version of bowtie is used in the fastqscreen.conf file.

The reads are 51b paired end and I call the program as follows

fastq_screen --nohits --conf=fastq_screen.conf --paired <library>_2_sequence.fastq.gz <library>_1_sequence.fastq.gz

I also tried using the --bowtie="--trim5 10" option, as well as --trim3 but this didn't affect the 99% to 100% nohits results.

Separately, I had used bwa to align the reads agains mm9, and the sequences did align. This is the output of samtools flagstats for one of the four bam files:

78666176 + 0 in total (QC-passed reads + QC-failed reads)
0 + 0 duplicates
76266600 + 0 mapped (96.95%:-nan%)
78666176 + 0 paired in sequencing
39333088 + 0 read1
39333088 + 0 read2
74908040 + 0 properly paired (95.22%:-nan%)
75455201 + 0 with itself and mate mapped
811399 + 0 singletons (1.03%:-nan%)
346117 + 0 with mate mapped to a different chr
130284 + 0 with mate mapped to a different chr (mapQ>=5)

Any idea on what I might be doing wrong? Apologies if I'm missing something really obvious.

[albireo]

Hello Simon, it works perfectly, thank you. It actually detected adapter contamination in some of my libraries

[simonandrews]

Thanks for the reply Simon. Could you also advise on how to feed the fastqc "contaminants.txt" data to the program?

You'd need to convert it into a fasta file. The script below should do this:

#!/usr/bin/perl
use warnings;
use strict;

open (IN,'contaminant_list.txt') or die $!;
open (OUT,'>','contaminant_list.fa') or die $!;

while (<IN>) {
  next if (/^\#/);
  chomp;
  next unless ($_);
  my ($name,$seq) = split(/\t+/);
  next unless ($seq);
  $name =~ s/\s+/_/g;
  print OUT ">$name\n$seq\n";
}
close OUT or die $!;

Once you have that you can index it with bowtie-build using something like:

bowtie-build -f contaminant_list.fa contaminants

You can then put the contaminants database into fastq_screen.

Hope this helps

[albireo]

Thanks for the reply Simon. Could you also advise on how to feed the fastqc "contaminants.txt" data to the program?

[simonandrews]

The choice of libraries really comes down to what other types of library are likely to be around in your facility, or other common sources of contamination. If there are a load of people doing drosophila work then I'd have a drosophila library.

The only common ones would be the vectors/adapters, phix and Ecoli as everyone is likely to have those around somewhere.

If people have found other common sources of contamination then I'd be interested to hear which species they found. The only odd one we've had (that we figured out at least) was acinetobacter which we think came from the beads used for our ChIP (the OmpA protein on the beads comes from this organism).

[albireo]

Hi, I'm new to the forum and very interested in this tool.

Simon, are they any sequence libraries (on top of those you recommend in your sample config files) one would want to search against when checking generic human illumina chip-seq reads? Thanks a lot for your work.

[simonandrews]

what if my reads are long like 100bps will still work?

Yes, that should work. The screen uses bowtie behind the scenes, so any data you could search with bowtie will work. The only problem you might have with really long reads is that a significant proportion of your library might read through into adapter. In that case you can pass the --trim3 bowtie option in the fastq_screen extra bowtie parameters option to limit how much of your reads you use to determine the match.

[husamia]

what if my reads are long like 100bps will still work?

[simonandrews]

I've just put up v0.2.1 of fastq screen to fix a bug which affected v0.2 if you were running multilib searches on paired end data. In these cases the percentage hits reported were twice as high as the true value.

This bug didn't affect v0.1, nor did it affect searches on single end data, or searches not using the --multilib option.

[simonandrews]

I've just put an updated version of fastq screen up onto our website. This version adds a new mode of analysis where the screening results are reported as the percentage of sequences which map to only one of the screen libraries, and the percentage which could map to more than one. This then allows you to see if you're seeing unexpected hits which are specific to the wrong species, or if you just have low complexity sequence which could have mapped anywhere.

The new release also fixes a few bugs and adds support for colorspace encoded reads.

[SES]

This looks pretty nice. As I understand it the user supplies the libraries to screen against - I wonder how one would go about to set up a library of adaptors/vectors/contaminants. Are there any commonly used collections of such sequences?

It sounds like you are looking for UniVec to screen for contaminants. For the adaptor sequences you will want to contact your sequencing center about a project because custom adaptors and combinations of them are commonly used.