23 de marzo de 2012

Es primavera: lidiando con Flower

Hola,

vamos a hablar un poco sobre el trabajo con secuencias obtenidas de experimentos de NGS (Next Generation Sequencing; para despistados) con el secuenciador 454. En concreto, nos vamos a centrar en una herramienta que puede servir para tener un primer vistazo de los datos obtenidos, antes de realizar el ensamblaje, mapeo, ...

Flower (Bioinformatics, 2011) es un programa desarrollado por Ketil Malde, también implicado en el desarrollo de FlowSim. Está escrito con Haskell, el lenguaje de programación funcional, y anteriormente se distribuía el paquete como tal (última versión flower_v0.7) pero hoy día viene en la librería biosff (v0.2). Se trata de una alternativa GPL a las SFF Tools que distribuye Roche con el paquete Data Analysis de su software propietario.

Para instalarlo lo más sencillo es utilizar cabal, gestor de paquetes de Haskell, y bajar además ghc, entorno para desarrollo y compilación en ese lenguaje.

sudo apt-get install ghc cabal-install
cabal install biosff

Vamos a desarrollar algunos ejemplos con los datos de la entrada SRR000001 del NCBI SRA, run que se llevó a cabo en un equipo Roche 454 GS FLX en 2007. Quizás la opción más simple es la que nos ofrece un vistazo rápido del experimento, dándonos información de índice generado (creo que es un índice a la manera de un suffix array), el número de reads, número de flows y la key usada para el run: secuencia de bases que se añade a toda la muestra durante la preparación de las librerías.

flower -i SRR000001.sff
Index: (782054672,9419708)
Num_reads: 470985
Num_flows: 400
Key: TCAG

En éste caso vemos que hay un index (se regeneró mediante sfffile -o, ya que las secuencias de SRA no suelen llevar el índice). Con aquel run obtuvieron 470K reads en 400 flows (100 ciclos: 100 nts/read de media esperada). Por último nos indica que la key es TCAG (aunque al parecer siempre ha sido la misma).

Flower (algo así como FLOW ExtracteR), puede generar FASTA y FASTQ con scores en Phred+33 o basados en la codificación de Illumina. La carencia de un comando para obtener un FASTQ es una de las cosas que más parece echar de menos la comunidad que utiliza SFF Tools. Para obtener el FASTQ en Phred+33 con Flower:

 flower -Q SRR000001.sff > SRR000001.fastq

Con la opción -s se obtienen datos sobre cada uno de los reads del experimento. La salida del programa da los campos separados convenientemente por tabuladores.

 flower -s SRR000001.sff > SRR000001.reads
# name........     date......     time....     reg     trim_l     trim_r     x_loc     y_loc     len     K2     trimK2     ncount     avgQ     travgQ
EM7LVYS01C1LWG     2 7-04-10      15:13:00     01      1          235        1131      1422      255     0.74   0.76       0          26.38    26.33

K2 es una métrica de calidad "K-square", que es la suma de cuadrados de las distancias desde el entero más cercano para cada flow value. Como el sistema de scoring de 454 se basa en estimar la longitud de un homopolímero en base a la señal registrada en un flow, un entero supondría la definición de una longitud de homopolímero con exactitud. ncount es el número de flow cycles sin valor determinado o basecalls ambiguos, que también llevan asociado un error si el flow value no es exactamente 0. avgQ es la calidad promedio del read. Todos los campos que comienzan con tr son equivalentes a los anteriores, pero tras realizar el trimming indicado en el SFF.

Además, para el análisis del experimento también se pueden generar datos para representación gráfica de los flow values. Con la opción -h se obtiene la distribución de flow values por nucleótido.

 flower -h SRR000001.sff > SRR000001histogram.txt
Score     A        C       G        T
0.00     361230    586168  620918   409514
0.01     136705    284992  305021   168203
0.02     182110    407799  437550   228386
0.03     239742    571509  614918   306284
0.04     311296    779612  839794   401568
0.05     397364   1029955 1110715   513386
0.06     503853   1318643 1412014   648700
....
así hasta 99.99

Con la opción -H se obtiene la distribución de flow values para los flow cycle. Si representamos el resultado de esta salida, tenemos un gráfico como el siguiente, donde se muestra claramente que el sistema está optimizado para obtener la menor tasa de error posible. Como ya se ha comentado, la tasa de error está asociada a los puntos entre cada dos enteros. Para poder dar el mayor quality score posible, la mayor confianza posible de que la longitud del homopolímero es la predicha por el basecall, se debe maximizar el número de flow values lo más cercanos que sea posible a un entero.

Imagen tomada de Bioinformatics (2010) 26 (18): i420-i425


En un principio, Flower incluia una herramienta para seleccionar reads del SFF (flowselect). Sin embargo, en la versión de biosff esta utilidad ha desaparecido. Podría venir a suplir las opciones -i y -e de sfffile, que generalmente se usan ya durante el proceso de análisis, para generar subconjuntos de los datos originales una vez se tienen datos de mapeo o ensamblaje.

Como conclusión, Flower es más que una alternativa a SFF Tools para el pre-análisis de las secuencias de 454, en vista de la buena representación de los datos, el buen desempeño que tiene y las opciones extra que nos aporta. Por otro lado, sigue sin cubrir algunas de las utilidades que presenta SFF Tools, sfffile en especial, pero es código libre así que todos estamos invitados a mejorarlo.

saludos!
Carlos

Correlación entre transcriptoma y proteoma

Hola,
una cuestión que ya dio qué hablar en los tiempos de los chips de RNA (microarrays) y que ha vuelto a resurgir recientemente es hasta qué punto podemos hacernos una idea de la actividad celular si sólo medimos la expresión de los genes en forma de mRNAs, cuando en realidad muchas de las funciones las desempeñan proteínas.
Por ejemplo, Tian et al.(2004) publicaron correlaciones del 40% en líneas celulares hematopoyéticas de mamíferos.

Sin embargo, ahora en muchos ámbitos los microarrays están siendo sustituidos por experimentos de RNAseq, y por tanto es pertinente volver a hacerse la pregunta, dado que se espera que esta tecnología sea superior. Dos artículos muy recientes nos ayudan precisamente a valorar esto.

El trabajo de Jiang et al.(2011), que propone el uso de controles para corregir los niveles de expresión medidos por RNAseq, incluye una figura que resume la distribución típica de valores de expresión génica que se obtienen por RNAseq:
Figura original de Jiang et al. (2011). En el A panel se muestra la equivalencia entre 'copias por célula' y 'fragmentos por kilobase mapeada' (FPKM). En el B se muestra el histograma de genes expresados, que se solapa a la izquierda (un hombro) con los valores de genes que se expresan menos de una copia por célula. Los datos se obtuvieron a partir de material extraído de una línea celular de Drosophila melanogaster.

El trabajo de Nagaraj et al. (2011), que se basa en material de la archiconocida línea celular humana HeLa, encuentra una distribución similar de mRNAs, lo que sugiere que debe ser una distribución estándar, pero además la correlaciona con valores de abundancia de péptidos medidos por espectrometría de masas de alta resolución. La figura siguiente resume un montón de datos experimentales:
Figura original de Nagaraj et al. (2011).
En el panel A efectivamente se reproduce el hombro observado en los datos de RNAseq de D.melanogaster y en el B se muestran los datos equivalentes de proteómica. El diagrama de Venn C es interesante, porque muestra que hay muchos mensajeros que no se observan como proteína, y algunas proteínas cuyo mensajero está ausente. El panel D muestra la distribución funcional de los genes expresados y, finalmente, el diagrama de dispersión E muestra la correlación observada entre ambos tipos de mediciones, con un coeficiente de correlación de Spearman de 0.6,
un saludo,
Bruno

Actualizaciones posteriores:
[1] En este trabajo se estudia cómo se heredan los niveles de expresión en mosca
[2] En este artículo se comenta que los genes ortólogos entre distintos organismos tienen mayores correlaciones en sus [proteína] que en [mRNA]

6 de marzo de 2012

ofertas de postdoc en filogenómica

Hola,
copio aquí dos ofertas de trabajo que me han llegado desde bioinformatibericos :

Postdoctoral Position in Evolutionary Genomics at IFCA (Universidad of Santander-CSIC)
A postdoctoral position is available immediately to work with Rafael Zardoya (Madrid), Julio Rozas (Barcelona), David Posada (Vigo), and Jesus Marco (Santander) on a common 
project related with gastropod phylogenomics. The position has a term of 1 year and mobility among the referred labs. 
Prerrequisites: A PhD in Biology, Chemistry, Computer Science or related fields, with proved skills in computational biology. 
Priority will be given to candidates with previous experience in NGS data analysis (assembling, gene annotation, etc), and with expertise in bioinformatics programing languages (Perl, Python, 
C, etc). 
It will be desirable some experience with Phylogenetics and/or Comparative Genomics or evolutionary biology in general, and with Relational databases (MySQL).
If interested please contact Rafael Zardoya, Department of Biodiversity and Evolutionary Biology, Museo Nacional de Ciencias Naturales, rafaz@mncn.csic.es. Application review 
will begin on March 5, 2012 and continue until the position is filled. To apply, please send the following:  
1. A curriculum vitae 
2. Names of 2 referees willing to provide a letter of recommendation upon request 
3. A brief statement of research interests and goals.
 
Postdoc on chromatin biophysics (Structural Genomics Group, National Center for Genomic Analysis)
The successful candidate will team with other members of our group in our efforts towards elucidating the 3D structure of genomic domains and genomes. Recent publication from the group in this field include:

- Umbarger, M. A., Toro, E., Wright, M. A., Porreca, G. J., Baù, D., Hong, S.-H., Fero, M. J., et al. (2011).  Molecular Cell44(2), 252–264
- Marti-Renom, M. A., & Mirny, L. A. (2011). PLoS Computational Biology7(7), e1002125
- Sanyal, A., Baù, D., Martí-Renom, M. A., & Dekker, J. (2011). Current Opinion in Cell Biology. doi:10.1016/j.ceb.2011.03.009
- Baù, D., Sanyal, A., Lajoie, B. R., Capriotti, E., Byron, M., Lawrence, J. B., Dekker, J., et al. (2011). Nature Structural & Molecular Biology18(1), 107–114.

I would appreciate if you could forward this announcement to whom may be interested,
Marc A. Marti-Renom, Group Leader 
Parc Cientific de Barcelona - Torre I - Baldiri Reixac, 4 - 2a.p - 08028 - Barcelona
Tel +34 934 033 743  Fax +34 934 037 279
email mmarti@pcb.ub.cat   web http://marciuslab.org & http://cnag.cat




28 de febrero de 2012

Leyendo el diagrama de Ramachandran

Hola,
la semana pasada les planteé a mis alumnos de la Licenciatura en Ciencias Genómicas el problema de asignar estructura secundaria a los residuos de una proteína, una vez medidos los ángulos dihedros del esqueleto peptídico psi y phi. Para esta tarea lo lógico es usar el diagrama de Ramachandran, como éste tomado de la wikipedia:


La solución naive consiste en delimitar las regiones del diagrama por medio de condiciones tales como 'si phi > X  AND psi < Y' entonces un residuo está en estado Z. Sin embargo, para tener mucha precisión sería necesario tener muchas condiciones como ésta, dada las formas irregulares del diagrama.


Una solución interesante, propuesta por F.Peñaloza, consiste en realmente leer el mapa, como lo hacemos nosotros. Lo que él hizo fue obtener un mapa de Ramachadran cuadrado con unos cuantos colores conocidos,

Diamagra de Ramachandran RGB de F.Peñaloza.


Diagrama anterior con los colores RGB empleados

para luego convertirlo a texto ASCII (con algo como text-image). Con este mapa en memoria, es sencillo obtener la estructura secundaria para unas coordenadas phi,psi dadas. 

Aprovechando el módulo GD de perl podemos leer la imagen directamente, como muestra el siguiente código:
 use strict;  
 use GD;  
   
 my $RAMAPLOT = 'ramachandran.png';  
 my $plot = GD::Image->newFromPng($RAMAPLOT);  
 my ($maxpsi,$maxphi) = checkPlot($plot);  
   
 my $inputPSI = 160;   
 my $inputPHI = -45;   
 printf("El estado de estructura secundaria para %s,%s es: %s\n",  
    $inputPSI,$inputPHI, getSimpleSS($maxpsi,$maxphi, $inputPSI,$inputPHI));  
   
 sub getSimpleSS  
 {  
   my ($maxpsi,$maxphi,$psi,$phi) = @_;  
   my %colorSS = (  
     '236,30,36','E',  
     '164,74,164','E',  
     '156,218,236','H',  
     '4,162,236','H',  
     #'180,230,28','L'   
     );  
   
   if($psi > 180 || $psi < -180 || $phi > 180 || $phi < -180)  
   {  
     die "# valid psi/phi are [-180,+180]\n";  
   }  
   $psi = (0.5 - (0.5 * $psi/180)) * $maxpsi;  
   $phi = (0.5 + (0.5 * $phi/180)) * $maxphi;  
     
   my @RGB = $plot->rgb( $plot->getPixel($phi,$psi) );  
   return $colorSS{"$RGB[0],$RGB[1],$RGB[2]"} || 'C';  
 }  
   
 sub checkPlot  
 {  
   my ($plot,$print_pixels) = @_;  
   my ($maxphi,$maxpsi) = $plot->getBounds();  
   if(!$print_pixels){ return ($maxphi,$maxpsi) }  
     
   foreach my $phi ( 0 .. $maxphi )   
   {  
     foreach my $psi ( 0 .. $maxpsi )   
    {  
       my @RGB = $plot->rgb( $plot->getPixel($phi,$psi));  
       print "$RGB[0] $RGB[1] $RGB[2]\n";  
    }  
   }  
   return ($maxphi,$maxpsi);  
 }  

Un saludo, Bruno


8 de febrero de 2012

HMMER 3.0, HMMER 2.3.2 or PfamScan?

Last time that I annotated Pfam domains into footprintDB database I used the program hmmpfam from the HMMER 2.3.2 software package. But now, many things have changed, Pfam version has moved from 23 to 26, and the current HMM file can't be used directly with HMMER 2, it needs to be converted with a simple tool of HMMER 3 (hmmconvert -2 Pfam-A.hmm > Pfam_ls_26).

HMMER 3 is a nice software tool that is hundreds of times faster than its predecesor, it takes 20 minutes in my Quad-Core computer the same calculation that took like 2 hours in a 28 node cluster.

So I have decided to move to modern times, but cautiously, because last time I tried HMMER 3 I had not wanted results, so I have done my own benchmark that I'm going to explain...

First, I downloaded a test set of protein sequences from 3Dfootprint, as I work with DNA binding proteins, I downloaded all of them from this archive (currently 2007 FASTA sequences).

To calculate the Pfam domains I used the last version of HMMER 3.0 from http://hmmer.janelia.org/software, my old version of HMMER 2.3.2 (something similar can be found here: http://hmmer.janelia.org/software/archive) and pfam_scan.pl script used by Pfam team to create their database in the Sanger Institute. Also I downloaded the last version of Hidden Markov Models from Pfam version 26 and converted it to use with HMMER 3 (hmmpress Pfam-A.hmm) and with HMMER 2 (hmmconvert -2 Pfam-A.hmm > Pfam_ls_26).

Then I started the testing with the 3 programs, with and without using thresholds in the HMMER param options:
HMMER 2 with thresholds: hmmpfam --acc --cut_ga Pfam-A.hmm protein_sequence_complexes.faa > protein_sequence_complexes.hmmscan
HMMER 2 default: hmmpfam --acc Pfam-A.hmm protein_sequence_complexes.faa > protein_sequence_complexes.hmmscan
HMMER 3 with thresholds:  hmmscan --acc --cpu 8 --notextw --cut_ga -o protein_sequence_complexes.hmmscan Pfam-A.hmm protein_sequence_complexes.faa
HMMER 3 default: hmmscan --acc --cpu 8 --notextw -o protein_sequence_complexes.hmmscan Pfam-A.hmm protein_sequence_complexes.faa
PfamScan (default thresholds): pfam_scan.pl -align -cpu 8  -hmm Pfam-A.hmm -fasta protein_sequence_complexes.faa -outfile protein_sequence_complexes.pfamscan

The final conclusion is that I'll use HMMER 3 with thresholds, it's because the calculation time is 200 times faster that HMMER 2 (Figure 1) and both retrive more or less the same number of domains for the main transcription factor families (Figure 2).

It's remarkable that HMMER 3 without thresholds is very much sensitive, detecting near the double number of domains than the rest of the techniques (Figure 1), but most of them are undesired domains that interfere with the identification of the important ones.

HMMER 2 results with and without thresholds are comparable (Figure 1), both of them detect most of the transcription factor domains (Figure 2), even a bit more than HMMER 3 with thresholds, without including spurious domains even without thresholds (Figure 1).

PfamScan detects less domains than the rest of the techniques (Figure 1), although it uses HMMER 3 internally, this is because it doesn't annotate overlapping domains, but also because it has very strict thresholds that in many cases fail to detect real transcription factor domains (Figure 2). We have noticed this problem in a particula recent study of the transcription factor YY1 (1UBD chain C), if we search in Pfam webserver its sequence (chain C) we obtain only 3 of the 4 real Zinc Finger domains, we must find the 4th Zinc Finger domain among the 'insignificant Pfam-A Matches'.

I hope these results help to decide to people like me dubbing among moving to HMMER 3, use PfamScan or continue using HMMER 2.

Figure 1. Statistics of several parameters with the 5 calculation methods.
Figure 2. Numer of retrieved domains for different transcription factor families with the different methods.