SEQanswers

Go Back   SEQanswers > Sequencing Technologies/Companies > Illumina/Solexa



Similar Threads
Thread Thread Starter Forum Replies Last Post
Analysis of Directional mRNA-seq data / Illumina jmtepp RNA Sequencing 7 02-26-2014 11:13 PM
Directional RNA-seq: Illumina Tru-seq versus dUTP based method jazz Sample Prep / Library Generation 35 06-06-2013 10:50 AM
RNA-Seq: Directional RNA deep sequencing sheds new light on the transcriptional respo Newsbot! Literature Watch 0 06-30-2011 02:00 AM
Directional RNA Seq huguesparri Illumina/Solexa 28 06-07-2011 05:56 AM
Illumina directional RNA-seq protocol Herve Illumina/Solexa 10 06-13-2010 07:18 AM

Reply
 
Thread Tools
Old 02-07-2011, 01:44 PM   #1
flobpf
Member
 
Location: USA

Join Date: Apr 2010
Posts: 76
Exclamation Illumina Directional RNA-Seq

Hi,

We recently got single end directional mRNA-Seq data obtained using the new Illumina protocol. I'm trying to map it to the genome using TopHat and Cufflinks. For both programs to understand that the library prep was different, I'm using the option

Code:
--library-type fr-firststrand
However, I'm not really sure whether the Illumina protocol only does first strand sequencing, or whether the library type should be standard Illumina or fr-secondstrand. I did it both ways (standard and firststrand) and found that the number of transcripts I get after Cufflinks is quite different. I know Illumina uses its own 5' and 3' adapters for defining the strand specificity, but not really clear how it does that/which strand it ends up sequencing?? Is the sequence we get that of the Coding Strand or the Template Strand?

Please help.

Thanks!

Last edited by flobpf; 02-07-2011 at 02:11 PM.
flobpf is offline   Reply With Quote
Old 02-16-2011, 09:10 AM   #2
flobpf
Member
 
Location: USA

Join Date: Apr 2010
Posts: 76
Thumbs up Update

I think that the Illumina directional sequencing protocol only does first strand sequencing. So fr-firststrand may be the option to use for TopHat and Cufflinks. Similarly, if you want to find out # of reads mapping to annotated genes using htseq-counts function and want to know both sense and antisense expression of a gene, one would need to use the option --stranded=no else it will only give sense expression.

Last edited by flobpf; 04-25-2011 at 10:47 AM.
flobpf is offline   Reply With Quote
Old 03-16-2011, 06:42 AM   #3
marcowanger
Senior Member
 
Location: Hong Kong

Join Date: Dec 2008
Posts: 350
Default

I am a bit confused. According to Simon Anders

Quote:
htseq-counts assumes your RNA-Seq data to be strand-specific, i.e., it will only count those genes which map to the strand that the feature is on. If you want it to count reads on both strands, use the '--straded=no' option.
I assume htseq count the read that map to the sense/antisense according the the strand of feature, so we should use --stranded=yes?

But practically, I found if I use --stranded on my ss-RNAseq I got prettly low count for the genes..

So I wonder which should I use.



Quote:
Originally Posted by flobpf View Post
So it turns out that the Illumina directional sequencing protocol only does first strand sequencing. So fr-firststrand is the option to use for TopHat and Cufflinks. Similarly, if you want to find out # of reads mapping to annotated genes using htseq-counts function and want to know both sense and antisense expression of a gene, one would need to use the option --stranded=no else it will only give sense expression.

hope this helps someone in need...
marcowanger is offline   Reply With Quote
Old 03-16-2011, 08:59 AM   #4
Simon Anders
Senior Member
 
Location: Heidelberg, Germany

Join Date: Feb 2010
Posts: 991
Default

In case of "--stranded=yes", only those reads are counted that map to the same strand as the gene sits on, i.e., I assume strand-specific RNA-Seq sequences the coding strand. This is how it is with the data from our lab (which has been made with an older pre-release version of Illumina's strand-specific protocol). To be honest, I didn't even think about that the reads could all end up on the opposite strand, but, of course, if the adapters are now ligated the other way round (P5 to 3', P7 to 5' of first strand), we can get it that way as well. So maybe, I should add a third setting, something like '--stranded=reverse'.
Simon Anders is offline   Reply With Quote
Old 03-16-2011, 09:35 AM   #5
flobpf
Member
 
Location: USA

Join Date: Apr 2010
Posts: 76
Default HTSeq antisense values

Quote:
But practically, I found if I use --stranded on my ss-RNAseq I got prettly low count for the genes..

So I wonder which should I use.
I guess HTSeq is only mapping the reads on the same strand as the annotated feature. Using --stranded=no will (probably) consider all reads mapping to the same locus regardless of the strand, but still it will not give you the degree of antisense expression.

What I did here was
1) used -s=no option to count the reads regardless of whether they were sense or antisense to a gene
2) Then, i wrote a custom python script to figure out from the readcounts file and the GFF file whether a given read was sense or antisense to a gene (0 = + strand and if gene = + strand, sense; 16=-strand and if gene = + strand, antisense)
3) I created pseudo-annotations - geneA_forward and geneA_reverse and reported number of reads mapping to a given gene in either orientation

To avoid these intermediate steps, --stranded=reverse option will be very helpful! In fact, if HTSeq-count could tell me the number of reads mapping to a gene in both sense and antisense, that would be the best!

Last edited by flobpf; 03-16-2011 at 04:27 PM. Reason: this approach is better
flobpf is offline   Reply With Quote
Old 03-16-2011, 07:50 PM   #6
marcowanger
Senior Member
 
Location: Hong Kong

Join Date: Dec 2008
Posts: 350
Default

Thanks for the clarification.

Would you mind help me explain the following observation?

I used htseq-count -t exon -i Name --mode=union --stranded=[yes/no] -o input.tagged.sam input.readName.sorted.sam hg19.Refseq.gff

Quote:
chr13 hg19_refGene gene 101183811 101185997 0.000000 - . ID=87769;Name=A2LD1
chr13 hg19_refGene mRNA 101183811 101185997 0.000000 - . ID=NM_033110;Name=A2LD1;Parent=87769
chr13 hg19_refGene exon 101183811 101184855 0.000000 - . ID=NM_033110.;Name=A2LD1;Parent=NM_033110
chr13 hg19_refGene exon 101185817 101185997 0.000000 - . ID=NM_033110.;Name=A2LD1;Parent=NM_033110
The gene "A2LD1" is coded by the -ve strand

Then I have the reads mapped by BWA/Tophat. Both shows the reads should be mapped to -ve strand.

BWA- the tagged SAM output by Htseq (0.47p2) with --stranded=no:

Quote:
GRC076:3:61:5267:19366#0 99 chr13 101183857 60 76M = 101183974 193 GCTGTGAAGCTTGATCTGAAAATTAGGAAGAATGGTGCTATACGCACTCTGATATACAGCATGCTTGCCCTGTGGA bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb XT:A:U NM:i:0 SM:i:37 AM:i:37 X0:i:1 X1:i:0 XM:i:0 XO:i:0 XG:i:0 MD:Z:76 XF:Z:A2LD1
GRC076:3:61:5267:19366#0 147 chr13 101183974 60 76M = 101183857 -193 CTCAGGGGTTACAGGCCAGAATCAGTATAGTAGGGCTGCTAAAATCTAGCGGCAACACCAAGTCTTTACACTGATC babbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb XT:A:U NM:i:0 SM:i:37 AM:i:37 X0:i:1 X1:i:0 XM:i:0 XO:i:0 XG:i:0 MD:Z:76 XF:Z:A2LD1
However, when I used --stranded=yes, then
Quote:
GRC076:3:61:5267:19366#0 99 chr13 101183857 60 76M = 101183974 193 GCTGTGAAGCTTGATCTGAAAATTAGGAAGAATGGTGCTATACGCACTCTGATATACAGCATGCTTGCCCTGTGGA bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb XT:A:U NM:i:0 SM:i:37 AM:i:37 X0:i:1 X1:i:0 XM:i:0 XO:i:0 XG:i:0 MD:Z:76 XF:Z:no_feature
GRC076:3:61:5267:19366#0 147 chr13 101183974 60 76M = 101183857 -193 CTCAGGGGTTACAGGCCAGAATCAGTATAGTAGGGCTGCTAAAATCTAGCGGCAACACCAAGTCTTTACACTGATC babbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb XT:A:U NM:i:0 SM:i:37 AM:i:37 X0:i:1 X1:i:0 XM:i:0 XO:i:0 XG:i:0 MD:Z:76 XF:Z:no_feature

I suppose when I use --stranded=yes, this pair should be still tagged to A2LD1, right? But It turns out it is only counted when stranded=no.

p.s. I found out this problem when I used --stranded=yes to count the reads in my strand specific sequencing and found more than 90% of the reads are not counted, which is weird.
Quote:
Originally Posted by Simon Anders View Post
In case of "--stranded=yes", only those reads are counted that map to the same strand as the gene sits on, i.e., I assume strand-specific RNA-Seq sequences the coding strand. This is how it is with the data from our lab (which has been made with an older pre-release version of Illumina's strand-specific protocol). To be honest, I didn't even think about that the reads could all end up on the opposite strand, but, of course, if the adapters are now ligated the other way round (P5 to 3', P7 to 5' of first strand), we can get it that way as well. So maybe, I should add a third setting, something like '--stranded=reverse'.

Last edited by marcowanger; 03-16-2011 at 07:53 PM. Reason: supplementary
marcowanger is offline   Reply With Quote
Old 03-16-2011, 07:57 PM   #7
marcowanger
Senior Member
 
Location: Hong Kong

Join Date: Dec 2008
Posts: 350
Default

The protocol we used

1> Poly-A selection, Fragmentation
2> First strand cDNA synthesis
3> Second strand syntehsis with dUNTP
4> end repair,3' end A-tailing, Adapter ligation (i have no idea if P5 to 3', P7 to 5' of first strand was used)
5> Size selection
6> UDGase treatment

I suppose in this protocol, we should have sequenced the coding strand?
marcowanger is offline   Reply With Quote
Old 03-16-2011, 08:34 PM   #8
marcowanger
Senior Member
 
Location: Hong Kong

Join Date: Dec 2008
Posts: 350
Default

One thing come into my mind.

We used strand specific (ss) paired-end sequencing.

And from illumina's website, the ss prep only works on single read flow cell only
Quote:
The Directional mRNA-Seq Sample Prep protocol is an experimental application of Illumina technology, requiring Illumina small RNA sequencing primers and the mRNA-Seq Sample Prep kit. This protocol is compatible with single-read flow cells only
And Simon you mentioned

Quote:
This is how it is with the data from our lab (which has been made with an older pre-release version of Illumina's strand-specific protocol)
Does it mean that HTSeq only count if both read of the pair are mapped into the strand as the gene sit on?

If so, I think the situation we faced is that, we have paired-end sequencing so that the FORWARD read (with a tag 99) always get mapped into the coding strand. Therefore in Tophat using --library-type fr-firststrand, the read mapped to Forward strand has a tag XS:A:-, meaning the RNA that produce this read comes from -ve strand (coding strand). Then, the gene that code for this read should sit on +ve strand (to have a -ve coding strand). Therefore, this Forward read, if exists alone, should be counted.

The complication comes in, when the reverse read of the pair is of opposite strand of the Forward (tag: 147), so that it behaves the other way round. Therefore, summed it up, the pair is considered not the be counted in the gene and is discarded. Is it true?

So in the meantime, I should use --stranded=no, and wait for a htseq update?

Quote:
Originally Posted by Simon Anders View Post
In case of "--stranded=yes", only those reads are counted that map to the same strand as the gene sits on, i.e., I assume strand-specific RNA-Seq sequences the coding strand. This is how it is with the data from our lab (which has been made with an older pre-release version of Illumina's strand-specific protocol). To be honest, I didn't even think about that the reads could all end up on the opposite strand, but, of course, if the adapters are now ligated the other way round (P5 to 3', P7 to 5' of first strand), we can get it that way as well. So maybe, I should add a third setting, something like '--stranded=reverse'.

Last edited by marcowanger; 03-16-2011 at 09:23 PM. Reason: supp.
marcowanger is offline   Reply With Quote
Old 03-16-2011, 08:39 PM   #9
marcowanger
Senior Member
 
Location: Hong Kong

Join Date: Dec 2008
Posts: 350
Default

Thanks flobpf

Quote:
Originally Posted by flobpf View Post
I guess HTSeq is only mapping the reads on the same strand as the annotated feature. Using --stranded=no will (probably) consider all reads mapping to the same locus regardless of the strand, but still it will not give you the degree of antisense expression.

What I did here was
1) used -s=no option to count the reads regardless of whether they were sense or antisense to a gene
2) Then, i wrote a custom python script to figure out from the readcounts file and the GFF file whether a given read was sense or antisense to a gene (0 = + strand and if gene = + strand, sense; 16=-strand and if gene = + strand, antisense)
3) I created pseudo-annotations - geneA_forward and geneA_reverse and reported number of reads mapping to a given gene in either orientation

To avoid these intermediate steps, --stranded=reverse option will be very helpful! In fact, if HTSeq-count could tell me the number of reads mapping to a gene in both sense and antisense, that would be the best!
marcowanger is offline   Reply With Quote
Old 03-16-2011, 10:15 PM   #10
marcowanger
Senior Member
 
Location: Hong Kong

Join Date: Dec 2008
Posts: 350
Default

I mean in the meantime, I should

1>
Quote:
So in the meantime, I should use --stranded=no
2> Filter the tagged sam by Htseq -o, filter the reads mapped to the gene that are tagged by Tophat XS:A:[+/-] with the strand matching the Gene strand in the GTF/GFF file.

Is it true?
marcowanger is offline   Reply With Quote
Old 03-17-2011, 04:33 AM   #11
flobpf
Member
 
Location: USA

Join Date: Apr 2010
Posts: 76
Default

Quote:
I suppose when I use --stranded=yes, this pair should be still tagged to A2LD1, right? But It turns out it is only counted when stranded=no.
I'm not sure why that is happening. I used tophat for mapping my reads, am not familiar with BWA.
Quote:
I mean in the meantime, I should

1>
Quote:
So in the meantime, I should use --stranded=no
2> Filter the tagged sam by Htseq -o, filter the reads mapped to the gene that are tagged by Tophat XS:A:[+/-] with the strand matching the Gene strand in the GTF/GFF file.

Is it true?
As far as I understand, TopHat XS:A is not the right FLAG. Strandedness of the read is displayed in the second column (0 or 16)
http://seqanswers.com/forums/showthread.php?t=10122
flobpf is offline   Reply With Quote
Old 03-17-2011, 05:07 AM   #12
marcowanger
Senior Member
 
Location: Hong Kong

Join Date: Dec 2008
Posts: 350
Default

flobpf, I think that is 2 different issues we are talking about here.

The term "strandness" puzzled me so much.

Strandness of the read:
The second column is about the strandness of the read's sequence.
For example, when a read ATGC being mapped onto the forward strand of the DNA, then this read is a FORWARD READ , as indicated by the status in column 2.

Strandness of the RNA that produce this read:
But the Tophat XS tag correspond to the strandness that the RNA that code for this read. Think we have a strand specific illumina sequencing, we only sequence the first strand of the mRNA (yet the genes may express mRNA from either +ve strand / -ve strand of the DNA sequences). Therefore, when mRNA is converted to first strand cDNA and get sequenced back, its sequence still correspond to the coding strand of the DNA (i.e. the strand the gene sit on). So theoretically, I think that is the FORWARD read of the pair determines the strand of the mRNA molecules that the read come froms (PE sequencing in illumina produce FR read on opposite strand).



Quote:
Originally Posted by flobpf View Post
I'm not sure why that is happening. I used tophat for mapping my reads, am not familiar with BWA.


As far as I understand, TopHat XS:A is not the right FLAG. Strandedness of the read is displayed in the second column (0 or 16)
http://seqanswers.com/forums/showthread.php?t=10122

Last edited by marcowanger; 03-17-2011 at 05:12 AM.
marcowanger is offline   Reply With Quote
Old 03-17-2011, 05:09 AM   #13
marcowanger
Senior Member
 
Location: Hong Kong

Join Date: Dec 2008
Posts: 350
Default

In fact I just used BWA to illustrate the scenario. I faced the problem using tophat BAM.....


Quote:
Originally Posted by flobpf View Post
I'm not sure why that is happening. I used tophat for mapping my reads, am not familiar with BWA.


As far as I understand, TopHat XS:A is not the right FLAG. Strandedness of the read is displayed in the second column (0 or 16)
http://seqanswers.com/forums/showthread.php?t=10122
marcowanger is offline   Reply With Quote
Old 03-17-2011, 05:16 AM   #14
marcowanger
Senior Member
 
Location: Hong Kong

Join Date: Dec 2008
Posts: 350
Default

Maybe first we have to clarify the terms so that we can discuss on the same line.

Please correct me if I am wrong,

Strandness in GTF/GFF file: Strand of the gene, the coding strand of the RNA, the non-template strand

Strandness in column 2 of SAM file: The strand the read being mapped onto the reference

Strandness of Tophat XS:A tag: Strand of the RNA that produce the read.


What I don't understand is that "Strand of the RNA" and "Strand of the gene in GTF". I think they are the same thing?

If I am correct, then for a gene A sit on the +ve strand. Then I should only say the read comes from this gene A if Tophat tag this pair with XS:A:+ve.

Last edited by marcowanger; 03-17-2011 at 05:20 AM.
marcowanger is offline   Reply With Quote
Old 03-17-2011, 05:34 AM   #15
marcowanger
Senior Member
 
Location: Hong Kong

Join Date: Dec 2008
Posts: 350
Default

I think this "thread" should be moved to "bioinformatics"?
marcowanger is offline   Reply With Quote
Old 03-17-2011, 12:19 PM   #16
flobpf
Member
 
Location: USA

Join Date: Apr 2010
Posts: 76
Default

Quote:
Strandness in GTF/GFF file: Strand of the gene, the coding strand of the RNA, the non-template strand

Strandness in column 2 of SAM file: The strand the read being mapped onto the reference

Strandness of Tophat XS:A tag: Strand of the RNA that produce the read.


What I don't understand is that "Strand of the RNA" and "Strand of the gene in GTF". I think they are the same thing?

If I am correct, then for a gene A sit on the +ve strand. Then I should only say the read comes from this gene A if Tophat tag this pair with XS:A:+ve.
Marcowanger, I think you are right. Please see this image attached for an illustrated explanation (and let me know if I'm wrong)


So the read obtained from directional sequencing corresponds to the template strand of the gene (not coding strand). Having said that, I infer the following. However, if we use XS tag in TopHat, we'd get the sense/antisense wrong (thanks Marcowanger for pointing that this was not an HTSeq issue):


Is my understanding correct? Or am I being mistaken?

Flobpf

UPDATE June 10, 2011: I contacted Illumina and they were confused too. However, finally they (and people at TopHat and our sequencing center) resolved the issue. The reads that come out of the machine have the same sequence as the CODING strand of the DNA and not the template strand.

Last edited by flobpf; 06-10-2011 at 08:15 AM. Reason: Update. Also see last post
flobpf is offline   Reply With Quote
Old 03-17-2011, 08:01 PM   #17
marcowanger
Senior Member
 
Location: Hong Kong

Join Date: Dec 2008
Posts: 350
Default

To strengthen our understanding on this issue, perhaps we should take a look at the paper on strand specific sequencing.

I take this for an example. http://nar.oxfordjournals.org/conten...e123/suppl/DC1

Please see below attachment:
nar-00743-met-g-2009-File006.marco.pdf

I have add my annotation to the above supplementary file (highlighting for better illustration). Basically if you read to page 4, we know the read's sequence is identical to the 1st strand cDNA (i.e. complementary to the DNA coding strand, a.k.a mRNA sequence with T-U substitution). Then flobpf you are right. The read should corresponds to DNA's template strand, which is also complementary to the strandness in GTF/GFF file (which indicates the gene coding strand)


XS:A:+/-:

This is the tophat's tag not HTSeq tag.

If the interpretation of XS:A is right
Quote:
XS: "+" for GT-AG and "-" for CT-AC
(http://seqanswers.com/forums/showthr...=tophat+strand)

As HT-Seq count only the read map to the Gene coding strand, the read from a gene-coding-strand being +ve will be mapped to -ve DNA strand (A gene with template strand -ve, coding strand+ve produces a mRNA that will be mapped to template strand -ve), then being discarded by HT-seq.

By the way, anyone know how HT-seq deals with paired-ended strand specific sequencing? Does it only look at Forward pair to infer strandness?


Quote:
Originally Posted by flobpf View Post
Marcowanger, I think you are right. Please see this image attached for an illustrated explanation (and let me know if I'm wrong)


So the read obtained from directional sequencing corresponds to the template strand of the gene (not coding strand). Having said that, I infer the following. However, HTSeq-counts seems to guess the sense/antisense wrong:


Is my understanding correct? Or am I being mistaken?

Flobpf

Last edited by marcowanger; 03-17-2011 at 08:05 PM.
marcowanger is offline   Reply With Quote
Old 03-17-2011, 08:07 PM   #18
marcowanger
Senior Member
 
Location: Hong Kong

Join Date: Dec 2008
Posts: 350
Default

As Simon assumes
Quote:
I assume strand-specific RNA-Seq sequences the coding strand
.

Then it probably explains why I got extremely low count for nearly all of the genes.
marcowanger is offline   Reply With Quote
Old 03-22-2011, 02:08 AM   #19
Simon Anders
Senior Member
 
Location: Heidelberg, Germany

Join Date: Feb 2010
Posts: 991
Default

Just to quickly clarify:

htseq-count does not look at the 'XS' optional field, only a the strand information according to the FLAG field. The strand information in the FLAG field (bit 0x10) specifies whether the sequence as read by the sequencer and as found in the FASTQ file has the same orientation as the sequence in the reference FASTA file ("+" strand, bit cleared), or whether the sequences in FASTQ and FASTA file are reverse-complements of each other ("-" strand, bit set).

With "--stranded=no", htseq-count ignored the strand bit. With "--stranded=yes" and single-end reads, it will count a read only if the alignment strand information according to the FLAG field is the same as the strand information for the gene/exon in the GFF file. For paired-end data, the strands have to be the same for the mate from the first sequencing pass and opposite for the mate from the second pass.

I guess I should add a new option "--stranded=reverse" that reverses this, i.e., counts reads only if, for single end, the strand informations in FLAG field and GFF file are opposite, and, for paired-end, if the first pass mate has opposite and the second pass mate same strand as the gene.

I hope this makes sense.

Simon
Simon Anders is offline   Reply With Quote
Old 03-22-2011, 02:18 AM   #20
marcowanger
Senior Member
 
Location: Hong Kong

Join Date: Dec 2008
Posts: 350
Default

Thanks Simon.

Quote:
Originally Posted by Simon Anders View Post
Just to quickly clarify:

htseq-count does not look at the 'XS' optional field, only a the strand information according to the FLAG field. The strand information in the FLAG field (bit 0x10) specifies whether the sequence as read by the sequencer and as found in the FASTQ file has the same orientation as the sequence in the reference FASTA file ("+" strand, bit cleared), or whether the sequences in FASTQ and FASTA file are reverse-complements of each other ("-" strand, bit set).

With "--stranded=no", htseq-count ignored the strand bit. With "--stranded=yes" and single-end reads, it will count a read only if the alignment strand information according to the FLAG field is the same as the strand information for the gene/exon in the GFF file. For paired-end data, the strands have to be the same for the mate from the first sequencing pass and opposite for the mate from the second pass.

I guess I should add a new option "--stranded=reverse" that reverses this, i.e., counts reads only if, for single end, the strand informations in FLAG field and GFF file are opposite, and, for paired-end, if the first pass mate has opposite and the second pass mate same strand as the gene.

I hope this makes sense.

Simon
marcowanger is offline   Reply With Quote
Reply

Tags
cufflinks, directional rna-seq, illumina, rna-seq, tophat

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off




All times are GMT -8. The time now is 10:49 PM.


Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2018, vBulletin Solutions, Inc.
Single Sign On provided by vBSSO