Ampliado el plazo para los abstracts en las XII Jornadas de Bioinformática


Tal como os conté el pasado 1 de Abril, la próxima edición de las Jornadas de Bioinformática (y van 12) se va a celebrar en Sevilla. Leyendo lo que escribí entonces me he dado cuenta que desde entonces ha cambiado varias veces el plazo de envío de abstracts, y de registro temprano.

La última noticia que tenía (de la semana pasada) era que ambos plazos vencían justo en el día de hoy, adelantándose así en un mes con respecto a lo que aparecía expuesto a principios de Abril. Pero, tras consultar de nuevo hace un instante la página principal del simposio para ver cuándo expiraba el plazo, me he encontrado con un nuevo cambio de fechas: el plazo de inscripción temprana ha sido ampliado hasta el 10 de Julio, mientras que el de envío de contribuciones se ha extendido hasta el 24 de Julio.

Para poder enviar vuestra contribución hay primero que registrarse, pero por ese lado la organización permite enviar hasta dos abstracts por persona registrada. Por otro lado, la SEBBM (Sociedad Española de Bioquímica y Biología Molecular) va a proporcionar hasta 6 becas de 200€ cada una para asistir a las Jornadas a aquellos que las soliciten y cumplan los requisitos para recibirlas.

Así que, si estais interesados en este simposio, aún estáis a tiempo de participar.

Etiquetas:
Categorias: Congresos

Cuando tus herramientas fallan: Ubuntu, R, ATLAS y fallos bizantinos


Como en cualquier profesión, nuestro trabajo depende tanto de nuestra profesionalidad como del buen funcionamiento de nuestras herramientas. Pero, ¿puede pasar que nuestras herramientas dejen de funcionar de forma correcta por una actualización? Por desgracia, todos sabemos que sí.

Esta situación ocurrió en nuestro laboratorio, y nos dimos cuenta la semana pasada. En la estación de trabajo de una compañera está instalada la distribución de Linux Ubuntu 12.10, y se le actualizó R (lenguaje y entorno de programación muy usado en cálculos estadísticos) hace cuatro semanas a la última versión, la 3.1.0, por paquete de Ubuntu. Las instalaciones de R en Ubuntu dependen de la implementación de BLAS (una librería matemática que define funciones de álgebra lineal) que haya activa. En Ubuntu hay disponibles varias: la implementación de referencia, la implementación de ATLAS, la implementación de OpenBLAS, etc… Como también se actualizaron los paquetes de Ubuntu de esa máquina, también hubo una actualización de la librería BLAS (estaba seleccionada ATLAS)… y algo pasaba con esa implementación.

Esta compañera empezó a sospechar que algo “raro” pasaba, cuando cálculos realizados meses atrás empezaron a salir distintos. ¿Cómo saber qué tenía la culpa? En estos casos hay que tener una dosis de suerte, y pensar lo impensable. Primero estuvo mirando si fue algún paquete de R, e intentando acotar el problema y su origen, se encontró con que cálculos tan sencillos en R como una regresión lineal daba resultados diferentes con cada ejecución para un mismo conjunto de datos. Este tipo de errores en el software es de los denominados fallos bizantinos, ya que no son fallos evidentes, y no son reproducibles.

Al ser lm una función básica de R, el problema podía estar en el propio R, en alguna librería que use R o en el hardware de la máquina (por ejemplo, un módulo de memoria defectuoso). Así que probamos a instalar R 3.1.0 a partir del código fuente, compilando con las opciones por defecto, y funcionaban los cálculos. Así que, ¿estaba mal compilado R, o qué pasaba? Aquí es donde intervino la suerte, cuando esta compañera se acordó que algunos paquetes de R habían dejado de funcionar con la actualización, y esos paquetes dependían de la librería BLAS del sistema. Buscando cómo reemplazar ATLAS de forma rápida y sencilla, encontramos esta entrada de blog donde se describe cómo activar OpenBLAS en Ubuntu. Y tras eso, el R 3.1.0 instalado por paquete empezó a funcionar de nuevo como debía.

¿Qué conclusiones salen de todo esto? No, no voy a decir que ATLAS sea una mala librería matemática, porque eso sería ser injusto con el trabajo y dedicación de sus desarrolladores. Ni que sea un problema de Ubuntu, porque posiblemente sea un fallo específico de la versión de ATLAS instalada con la versión de R instalada. La conclusión a nivel científico es que tenemos que ser capaces de reproducir nuestras investigaciones, y cuando no lo conseguimos, averiguar el por qué. Puede ser la metodología que hemos seguido, puede ser la implementación del método… o puede ser algo que no hayamos tenido en cuenta, como que no funciona bien alguna herramienta.

Actualización 30 de Junio de 2014

Algo que se me olvidó contar, pero que es muy importante, es que, cuando se cambian las librerías matemáticas de las que depende R (y en general, cualquier librería que sea usada por algún paquete de R), es más que recomendable reinstalar los paquetes que las estén usando. Tras el cambio a OpenBLAS se dio el caso de que la función lm funcionaba, mientras que otro paquete seguía fallando.

Otro detalle importante para evitar más problemas es que OpenBLAS tiene soporte multihebra que funciona muy bien cuando no hay otro tipo de paralelismo de por medio. Pero como hay paquetes de R o nuestro propio código que ejecutan en varios núcleos cuando éstos están disponibles, todo esto junto se lleva bastante mal. En los comentarios de la propia página mencionan este problema, y cuentan una de las maneras de desactivar el soporte multihebra de OpenBLAS. Estableciendo en el fichero de perfil .bashrc la variable de entorno OPENBLAS_NUM_THREADS, o la variable de entorno GOTO_NUM_THREADS, o la variable de entorno OMP_NUM_THREADS (asociada a OpenMP) a 1:

export OPENBLAS_NUM_THREADS=1

conseguimos evitar ese problema

Etiquetas:
Categorias: Misceláneo

Los accession numbers de UniProt tendrán más longitud a partir de Junio


UniProt es una de las bases de datos de proteínas más curada (en su sección SW) y mantenida actualmente, y por eso es tomada como una de las bases de datos de referencia a nivel de información de proteínas. Desde que se hizo pública en Julio de 1986 Swiss-Prot (una de las integrantes de UniProt, y predecesora), cada entrada de la base de datos dispone de un accession number (AC en el formato SW) principal, que sirve para identificar de forma inequívoca cada entrada. También se almacena para cada entrada cero o más accession number secundarios, que fueron usados en el pasado para esta entrada, y que sirven tanto para mantener un historial dentro de UniProt como para poder relacionar material de investigación antiguo (por ejemplo, artículos) con los datos actuales.

Inicialmente, un identificador de Swiss-Prot o TrEMBL tenía el siguiente formato de 6 caracteres:

1 2 3 4 5 6
[O,P,Q] [0-9] [A-Z,0-9] [A-Z,0-9] [A-Z,0-9] [0-9]

lo que permitía tener 13996800 entradas diferentes (3·10·(26+10)3·10). Posteriormente, se permitieron más letras en la primera posición (y menos en la tercera):

1 2 3 4 5 6
[O,P,Q] [0-9] [A-Z,0-9] [A-Z,0-9] [A-Z,0-9] [0-9]
[A-N,R-Z] [0-9] [A-Z] [A-Z,0-9] [A-Z,0-9] [0-9]

lo cuál aumentó el número de identificadores diferentes a 91497600 ((23·10·26·(26+10)2·10) = 77500800).

Pero, en la versión de Mayo de 2014 ya hay 56555610 entradas (545388 de UniProt/SwissProt y 56010222 de UniProt/TrEMBL), eso sin contar los accession number secundarios de dichas entradas. Los encargados de UniProt han hecho sus propios cálculos de estimación del crecimiento de la base de datos y de uso de accession numbers, y se han dado cuenta que para finales de 2014 se iban a quedar sin accession numbers para proteínas nuevas. Así que, a partir del 11 de Junio podrá haber entradas que usen, además de estos formatos, accession number de 10 caracteres:

1 2 3 4 5 6 7 8 9 10
[O,P,Q] [0-9] [A-Z,0-9] [A-Z,0-9] [A-Z,0-9] [0-9]
[A-N,R-Z] [0-9] [A-Z] [A-Z,0-9] [A-Z,0-9] [0-9]
[A-N,R-Z] [0-9] [A-Z] [A-Z,0-9] [A-Z,0-9] [0-9] [A-Z] [A-Z,0-9] [A-Z,0-9] [0-9]

que proporcionarán (23·10·(26·(26+10)2·10)2) = 2.6114669568·1013 nuevos identificadores (una diferencia de 6 órdenes de magnitud), margen suficiente para varios años más.

Enlaces

Etiquetas:
Categorias: General, Noticias

Workshop de Biología Computacional y de Sistemas en Comorbilidades de Enfermedades en ECCB’14


Del 7 al 10 de Septiembre de 2014 se va a celebrar el ECCB’14 en Estrasburgo (Francia), y tal como aparece en este tweet, entre los distintos workshops asociados a dicha conferencia se encuentra uno de Biología Computacional y de Sistemas en Comorbilidades de Enfermedades. Pero ¿qué son la morbilidad, la comorbilidad, y cuándo se dan comorbilidades de enfermedades?

La morbilidad, según la RAE, es “la proporción de personas que enferman en un sitio y tiempo determinado”, por lo que es una medida para saber la prevalencia de una enfermedad (cómo de común es). Y, transcribiendo de la definición de Wikipedia, “comorbilidad” es un término médico que se refiere a dos conceptos distintos:

Leyendo la página del workshop, la comorbilidad de enfermedades, o “multimorbilidad”, existe si dos o más desórdenes (defectos genéticos, enfermedades, etc…) afectan a los mismos individuos más frecuentemente que lo esperado en el caso común. El punto clave de la definición está en que esa coocurrencia de enfermedades sea la norma, en lugar de la excepción. Ciertos sectores de la población, como las personas mayores, están predispuestos a las multimorbilidades, lo cuál influye en la necesidad de mayores inversiones en sanidad pública para esos sectores.

Pero tal como declara la página del workshop, la reciente expansión de tanto las bases de datos biomédicas y conjuntos de datos post-genómicos asociados a distintas enfermedades, proveen ingentes cantidades de datos que permiten llevar a cabo investigaciones de comorbilidades entre los distintos desórdenes estudiados. Y justo ahí es donde entran en juego la biología computacional, la biología de sistemas y el workshop.

Tal como aparece en la página del workshop, éste está estructurado en tres sesiones, y se va a celebrar el 7 de Septiembre de 2014. Si tenéis interés de participar y aportar vuestro granito de arena a este workshop, desde el pasado 9 de Abril podéis enviar vuestros abstracts, usando el enlace de EasyChair del workshop. El plazo límite para enviar abstracts es el 15 de Mayo, y la comunicación de la aceptación o rechazo de vuestras contribuciones será el 26 de Mayo.

Enlaces

Etiquetas:
Categorias: General

Las XII Jornadas de Bioinformática serán en Sevilla


Ya es oficial. Las XII Jornadas de Bioinformática (http://www.bioinformaticsconference2014.org/) van a celebrarse en Sevilla, del 21 al 24 de Septiembre, en el cicCartuja (Centro de Investigaciones Científicas Isla de la Cartuja). Aunque las primeras ediciones de las Jornadas de Bioinformática se celebraban anualmente, desde hace unos años ha adoptado un formato bianual, acorde a los tiempos económicos en los que vivimos.

Los coordinadores de esta duodécima edición (Damien P. Devos, Ildefonso Cases y Ana M. Rojas) quieren que las nuevas generaciones de bioinformáticos se involucren en el evento, y por ello el tema principal de las Jornadas es “Bioinformatics: The New Breed“. Los principales puntos que se quieren destacar en esta edición son:

Las fechas claves del evento de momento confluyen en el 31 de Julio, que es cuando se cierra el plazo tanto para el envío de contribuciones a las Jornadas, como para el registro temprano (y más barato) en las mismas. Antes del 31 de Julio la cuota de inscripción es de 100€ para los estudiantes y 180€ para el resto, mientras que después de esa fecha costará 160€ para estudiantes y 230€ para el resto.

En el programa provisional se encuentra reservado el primer día para el simposio de estudiantes, dejando el segundo día para la metagenómica, la evolución y la filogenia, el tercer día para las charlas de estructura, función de proteínas y la bioinformática biomédica, dejando el día de clausura para la biología integrativa.

Así que ¡aún tenéis tiempo para animaros a asistir! Tanto para realizar la inscripción como el envío de contribuciones hay que registrarse en la página del congreso, en http://www.bioinformaticsconference2014.org/eng/enter .

Etiquetas:
Categorias: Congresos, Noticias

TopHat 2: arreglos para algunos fallos técnicos


Una parte de la bioinformática actual gira en torno a los análisis de datos de experimentos de ultrasecuenciación: ChIP-Seq, FAIRE-Seq y DNase-Seq, exome sequecing, RNA-Seq, … Una de las herramientas es TopHat (en el momento de escribir esta entrada iba por la versión 2.0.10), que se usa en los experimentos de RNA-Seq para identificar splice junctions tipo exón-exón… Para entender qué  es esto de los splice junctions tipo exón-exón, primero hay que recordar cómo funciona la síntesis de proteínas con estos esquemas de la Wikipedia inglesa:

Cuando una proteína del código genético de la célula va a ser producida por la maquinaria celular, lo primero que se hace es, dentro del núcleo, copiar el código genético correspondiente a los exones que representan a esa proteína, descartando normalmente otros exones alternativos del mismo gen (y de los demás genes). Todos esos exones son puestos de forma consecutiva en un ARN mensajero, que es el que sale del núcleo de la célula con esa información y viaja por el citoplasma hasta llegar a un ribosoma. Pero los procesos biológicos encargados de la composición del ARN mensajero pueden fallar, por ejemplo juntando exones correspondientes a proteínas de distintos genes. Estos procesos pueden estar alterados por defectos genéticos, y por diversas enfermedades, como por ejemplo todos los tipos de cáncer.

Los experimentos de RNA-Seq tratan de capturar la información sobre parte del transcriptoma (que sería el conjunto de todos los posibles ARN mensajeros), justo aquéllos que se encuentran en uso en las muestras usadas para el experimento de RNA-Seq. TopHat usa un genoma de referencia relacionado con los datos a analizar (por ejemplo, el genoma humano), información sobre los exones conocidos y a qué genes corresponden (proveniente de UCSC Genome Browser o Ensembl), y los datos a analizar como tal (del orden de decenas de GB).

TopHat, como casi todas las herramientas y pipelines de análisis del mundo NGS, está en continuo desarrollo y es bastante complejo (está escrito en Python 2.7 y C++), con lo que es inevitable que contenga fallos técnicos. Los datos de un experimento de RNA-Seq que tuvo que analizar una compañera de trabajo han tenido la “suerte” de ser capaz de disparar tres de estos fallos técnicos.

  1. Segmentation fault en segment_juncs: Como se puede ver en esta entrada de un foro de Google Groups, es un fallo existente de antes. La suerte es que en esa entrada vienen las pistas de cómo arreglar dicho fallo en el código fuente, en el fichero src/segment_juncs.cpp .
  2. AttributeError: 'NoneType' object has no attribute 'split' de tophat al relanzar un trabajo terminado abruptamente: tophat viene con la posibilidad de reiniciar trabajos de análisis que hayan terminado de forma abrupta, desde el punto en el que haya fallado. Pero ese mecanismo tiene fallos… Para los que programéis en otros lenguajes de programación, pero no en Python, ‘NoneType’ es la clase de los ‘None’, el equivalente a ‘undef’ de Perl, ‘nil’ de Ruby, ‘NULL’ de C y C++, ‘undefined’ de JavaScript, etc… También hubo suerte, porque en esta otra entrada del mismo foro de Google Groups, un usuario propone un arreglo que, aunque no sea muy ortodoxo ni correcto, hace que tophat continúe.
  3. Segmentation fault en tophat_reports: Aunque este fallo está más o menos documentado en el mismo foro de Google Groups, nadie propone un arreglo. Pero investigando un poco aquí, descubrí que el fallo se encuentra en el fichero src/tophat_reports.cpp, por una razón similar a la descrita en el fallo de segment_juncs.

 Actualización

Para que os sea más fácil arreglar estos problemas si os topáis con ellos, he puesto los parches derivados de los arreglos en un repositorio de GitHub: https://github.com/inab/tophat2-patches

Actualización 2

Hemos encontrado para nuestro caso la causa principal de los dos Segmentation fault. Había discrepancias entre el genoma de referencia y sus índices de bowtie, que se solucionaron ejecutando de vuelta bowtie-build.

Etiquetas:
Categorias: General

¿Por qué las publicaciones científicas están prisioneras detrás de un muro de pagos?


Normalmente, cuando veo una noticia o una entrada de un blog que es interesante para esta bitácora, intento plasmar un resumen personal del mismo, encontrar entradas independientes relacionadas en algún sentido y aportar mi granito de arena adicional, excavando un poco más en lo que he encontrado.

Pero siempre hay excepciones. En el blog Priceonomics, he encontrado la entrada Why is Science behind a paywall?, publicada por Alex Mayyasi el 10 de Mayo de 2013, que pienso que merece ser traducida íntegramente al castellano, al proporcionar una gran retrospectiva sobre por qué los descubrimientos científicos, y las publicaciones donde fueron hechos públicos, son como son (un poco más centrado en Estados Unidos que en el resto de países, todo sea dicho de paso). Espero no hacer un trabajo muy burdo…

Seguir leyendo »
Etiquetas: