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
Tengo que reconocer que me he divertido leyéndolo, aunque supongo que no fue tan divertido encontrar el fallo. Te dejo mi decálogo adquirido con la experiencia…
1. Actualizar lo justo y necesario.
2. Usar distribuciones LTS de Ubuntu (o mejor Kubuntu para trabajar).
3. No instalarse la última versión de linux hasta pasados unos meses de su lanzamiento (o dejar que los fallos los descubran otros con más tiempo libre).
4. Si algo funciona bien, ¿por qué cambiarlo a peor? Office y Windows XP son los mejores ejemplos.
5. Usar copias de seguridad del trabajo diario con rsync y de vez en cuando de disco completo con FSArchiver.
6. Apagar el ordenador del trabajo por las noches, ahorrará energía y vivirá más y mejor. Mi compañero indio lleva meses sin apagarlo y sin cerrar ventanas, un día de estos le explotará.
7. Para finalizar decir que era fan de los 32bits hasta que llegaron los programas de NGS. Todavía no estoy muy seguro si con 64bits se mejora mucha pero me lo he tenido que instalar.
En este caso se trataba de una versión bastante antigua de Ubuntu (una 12.10), que tenía todo el software proveniente de los repositorios de esa versión, salvo todo el software relacionado con bioinformática, que sí está más actualizado. La política de nuestro administrador de sistemas es justo esa, actualizar lo justo y necesario, no sólo porque sea conveniente para la estabilidad, sino además porque se encuentra sobresaturado.
Y sobre el uso de arquitecturas de 64 bits, sí, hay una gran diferencia, sobre todo a nivel de gestión y manipulación de ficheros enormes como los de NGS con herramientas que usen tipos de datos de más de 32 bits o librerías matemáticas optimizadas.