scientific computing - Reproducibilidad en la programación científica.

scientific-computing (8)

Junto con producir resultados incorrectos, uno de los peores temores de la programación científica es no poder reproducir los resultados que ha generado. ¿Qué mejores prácticas ayudan a garantizar que su análisis sea reproducible?

Creo que muchas de las respuestas anteriores pasaron por alto la parte de "computación científica" de su pregunta y respondieron con cosas muy generales que se aplican a cualquier ciencia (haga que los datos y el método sean públicos, especializados para CS).

Lo que faltan es que tiene que ser aún más especializado: debe especificar qué versión del compilador utilizó, qué interruptores se usaron al compilar, qué versión del sistema operativo utilizó, qué versiones de todas las bibliotecas vinculado contra, qué hardware está utilizando, qué más se estaba ejecutando en su máquina al mismo tiempo, y así sucesivamente. Hay artículos publicados por ahí donde cada uno de estos factores influyó en los resultados de una manera no trivial.

Por ejemplo (en el hardware de Intel) podría estar usando una biblioteca que usa los flotadores de 80 bits de la FPU, haga una actualización de O / S, y ahora esa biblioteca solo puede usar dobles de 64 bits, y sus resultados pueden cambiar drásticamente si su El problema estaba en lo más mínimo mal condicionado.

Una actualización del compilador puede cambiar el comportamiento de redondeo predeterminado, o una sola optimización puede cambiar en el orden 2 en que se realizan las instrucciones, y nuevamente para sistemas mal acondicionados, boom, resultados diferentes.

Diablos, hay algunas historias extravagantes de algoritmos subóptimos que muestran "lo mejor" en las pruebas prácticas porque se probaron en una computadora portátil que ralentizó automáticamente la CPU cuando se sobrecalentó (que es lo que hizo el algoritmo óptimo).

Ninguna de estas cosas es visible desde el código fuente o los datos.

Muchas buenas sugerencias ya. Agregaré (tanto de la amarga experiencia --- antes de la publicación, ¡afortunadamente!),

1) Compruebe sus resultados para la estabilidad:

Pruebe varios subconjuntos diferentes de los datos
rebinar la entrada
rebinar la salida
ajustar el espaciado de la cuadrícula
prueba varias semillas al azar (si corresponde)

Si no es estable, no has terminado.

Publique los resultados de las pruebas anteriores (o al menos, conserve la evidencia y mencione que lo hizo).

2) Verificación puntual de los resultados intermedios.

Sí, es probable que vayas a desarrollar el método en una pequeña muestra y luego a todo el lío. Pico en el medio unas cuantas veces mientras se lleva a cabo esa molienda. Mejor aún, cuando sea posible, recopilar estadísticas sobre los pasos intermedios y buscar signos de anomalías en ellos.

Una vez más, cualquier sorpresa y tienes que volver y hacerlo de nuevo.

Y, de nuevo, retener y / o publicar esto.

Cosas ya mencionadas que me gustan incluyen

Control de fuente --- lo necesitas para ti de todos modos.
Registro de entorno de compilación. La publicación de la misma es agradable.
Planea hacer el código y los datos disponibles.

Otro que nadie ha mencionado:

3) Documentar el código.

Sí, estás ocupado escribiéndolo, y probablemente estés ocupado diseñándolo a medida que avanzas. Pero no me refiero a un documento detallado, sino a una buena explicación de todas las sorpresas. De todos modos, tendrá que escribirlos, así que piense en ello como para obtener una ventaja en el papel. Y puede mantener la documentación en el control de código fuente para que pueda tirar libremente los trozos que ya no se aplican, estarán allí si los necesita.

No estaría mal construir un pequeño README con instrucciones de compilación y una extensión de "Cómo ejecutar". Si va a hacer que el código esté disponible, la gente preguntará sobre estas cosas ... Además, para mí, volver a consultar me ayuda a mantener el rumbo.

Publicar código, datos y resultados en Internet. Escribe la URL en el papel.

Además, envíe su código a "concursos". Por ejemplo, en la recuperación de información de música, hay MIREX .

Publicar el código del programa, ponerlo a disposición para su revisión.

Esto no está dirigido a usted de ninguna manera, pero aquí está mi perorata:

Si realiza un trabajo patrocinado por el dinero de los contribuyentes, si publica los resultados en una revista revisada por pares, proporcione el código fuente, bajo una licencia de código abierto o en un dominio público. Estoy cansado de leer acerca de este gran algoritmo que se le ocurrió a alguien, que dicen que hace x, pero no proporciona ninguna forma de verificar / verificar el código fuente. Si no puedo ver el código, no puedo verificar sus resultados, ya que las implementaciones de algoritmos pueden ser diferencias muy drásticas.

En mi opinión, no es moral mantener el trabajo pagado por los contribuyentes fuera del alcance de los colegas investigadores. está en contra de la ciencia presentar documentos, pero no proporciona beneficios tangibles para el público en términos de trabajo utilizable.

Registre los parámetros de configuración de alguna manera (por ejemplo, si puede establecer una determinada variable en un determinado valor). Esto puede estar en la salida de datos, o en el control de versión.

Si está cambiando su programa todo el tiempo (¡lo estoy haciendo!), Asegúrese de registrar qué versión de su programa está usando.

Soy un ingeniero de software integrado en un equipo de geofísicos de investigación y actualmente (como siempre) estamos trabajando para mejorar nuestra capacidad de reproducir resultados a pedido. Aquí hay algunos consejos recogidos de nuestra experiencia:

Ponga todo bajo control de versión: código fuente, conjuntos de datos de entrada, makefiles, etc.
Cuando compilamos ejecutables: incrustamos directivas de compilación en los propios ejecutables, etiquetamos un registro de compilación con un UUID y etiquetamos el ejecutable con el mismo UUID, calculamos las sumas de comprobación de los ejecutables, construimos automáticamente todo y realizamos actualizaciones automáticas de una base de datos (OK, es solo una archivo realmente) con detalles de compilación, etc.
Utilizamos las palabras clave de Subversion para incluir números de revisión (etc.) en cada parte de la fuente, y éstas se escriben en los archivos de salida generados.
Hacemos muchas pruebas de regresión (semi) automatizadas para garantizar que las nuevas versiones de código, o las nuevas variantes de compilación, produzcan los mismos resultados (o lo suficientemente similares), y estoy trabajando en un montón de programas para cuantificar los cambios que hacen ocurrir.
Mis colegas geofísicos analizan las sensibilidades de los programas a los cambios en los insumos. Analizo su sensibilidad (los códigos, no los geos) a la configuración del compilador, a la plataforma y similares.

Actualmente estamos trabajando en un sistema de flujo de trabajo que registrará los detalles de cada trabajo ejecutado: los conjuntos de datos de entrada (incluidas las versiones), los conjuntos de datos de salida, el programa (incl. Versión y variante) utilizados, los parámetros, etc., lo que comúnmente se denomina procedencia. Una vez que esto esté funcionando, la única forma de publicar resultados será mediante el uso del sistema de flujo de trabajo. Cualquier conjunto de datos de salida contendrá detalles de su propia procedencia, aunque aún no hemos hecho el diseño detallado de esto.

Estamos bastante (quizás demasiado) relajados sobre la reproducción de resultados numéricos al dígito menos significativo. La ciencia que subyace en nuestro trabajo y los errores inherentes a las mediciones de nuestros conjuntos de datos fundamentales no respaldan la validez de ninguno de nuestros resultados numéricos más allá de 2 o 3 pies cuadrados.

Ciertamente no publicaremos ni el código ni los datos para una revisión por pares, estamos en el negocio del petróleo.

Tal vez esto sea un poco fuera de tema, pero para seguir las indicaciones específicas de @Jacques Carette con respecto a la informática científica, puede ser útil consultar la documentación de Verificación y Validación ("V&V") para algunas preguntas específicas, especialmente aquellas que difuminan la línea entre la reproducibilidad y la corrección. Ahora que la computación en la nube se está convirtiendo en una opción más para los grandes problemas de simulación, la reproducibilidad entre una variedad aleatoria de CPU aleatorias será más una preocupación. Además, no sé si es posible separar completamente la "corrección" de la "reproducibilidad" de sus resultados, ya que estos se derivan de su modelo computacional. A pesar de que su modelo parece funcionar en el grupo A computacional pero no en el grupo B, debe seguir algunas pautas para garantizar que su proceso de trabajo para hacer este modelo sea sólido. Específicamente para la reproducibilidad, existe cierto interés en la comunidad de V&V para incorporar el error de reproducibilidad en la incertidumbre general del modelo (dejaré que el lector investigue esto por su cuenta).

Por ejemplo, para el trabajo de dinámica de fluidos computacional (CFD), el estándar de oro es la guía ASME V&V . Para el modelado y simulación multifísicos aplicados, especialmente para las personas (con sus conceptos generales aplicables a la comunidad científica en general), este es un estándar importante para internalizar.

Publique los datos originales sin procesar en línea y póngalos a disposición de descarga gratuita.
Haga que el código base sea de código abierto y esté disponible en línea para descargarlo.
Si se utiliza la aleatorización en la optimización, repita la optimización varias veces, seleccionando el mejor valor que resulte o utilice una semilla aleatoria fija, para que se repitan los mismos resultados.
Antes de realizar su análisis, debe dividir los datos en un conjunto de datos de "capacitación / análisis" y un conjunto de datos de "prueba / validación". Realice su análisis en el conjunto de datos de "entrenamiento" y asegúrese de que los resultados que obtenga se mantengan en el conjunto de datos de "validación" para asegurarse de que su análisis sea en realidad generalizable y no se limite a memorizar las peculiaridades del conjunto de datos en cuestión.

Los dos primeros puntos son increíblemente importantes, porque hacer que el conjunto de datos esté disponible permite que otros realicen sus propios análisis en los mismos datos, lo que aumenta el nivel de confianza en la validez de sus propios análisis. Además, hacer que el conjunto de datos esté disponible en línea, especialmente si utiliza formatos de datos vinculados, hace posible que los rastreadores agreguen su conjunto de datos con otros conjuntos de datos, lo que permite el análisis con conjuntos de datos más grandes ... en muchos tipos de investigación, el tamaño de la muestra a veces es demasiado pequeño para estar realmente seguro de los resultados ... pero compartir su conjunto de datos permite construir conjuntos de datos muy grandes. O, alguien podría usar su conjunto de datos para validar el análisis que realizaron en otro conjunto de datos.

Además, hacer que su código sea de código abierto hace posible que el código y el procedimiento sean revisados por sus pares. A menudo, tales revisiones conducen al descubrimiento de fallas o de la posibilidad de optimización y mejora adicionales. Lo más importante es que permite a otros investigadores mejorar sus métodos, sin tener que implementar todo lo que ya ha hecho desde cero. Acelera enormemente el ritmo de la investigación cuando las investigaciones pueden centrarse solo en mejoras y no en reinventar la rueda.

En cuanto a la aleatorización ... muchos algoritmos se basan en la aleatorización para lograr sus resultados. Los métodos estocásticos y de Monte Carlo son bastante comunes y, si bien se ha demostrado que convergen en ciertos casos, aún es posible obtener resultados diferentes. La forma de asegurarse de que obtiene los mismos resultados, es tener un bucle en su código que invoque el cómputo un número fijo de veces y elegir el mejor resultado. Si usa suficientes repeticiones, puede esperar encontrar optima global o casi global en lugar de quedarse atascado en optima local. Otra posibilidad es usar una semilla predeterminada, aunque no sea así, en mi humilde opinión, un enfoque tan bueno, ya que podrías elegir una semilla que te haga atascarte en los óptimos locales. Además, no hay garantía de que los generadores de números aleatorios en diferentes plataformas generen los mismos resultados para ese valor semilla.