Lectura recomendadísima con unos cuantos consejos sobre cómo organizar los directorios de trabajo para facilitar la reproducibilidad, el orden homogéneo de todos nuestros proyectos, y nuestra salud mental en general. Cuanto menos, dan inspiración y refuerzan ideas o experiencias previas en el mundo de los sistemas de archivos. Además, molan porque son tan sencillos que ayudan hasta a los que más nos cuesta organizar las cosas. Traducidos al castellano, los comentarios más importantes serían:

1. Crea una estructura estándar para tus proyectos, respétala en todo momento, conócela como la palma de tu mano, y reutilízala en cada proyecto que hagas. Por ejemplo:
   1. Ten un directorio por cada proyecto que tengas. Todo lo necesario para un proyecto debería estar en el mismo directorio raíz.
   2. Dentro del directorio principal del proyecto, al menos los tres siguientes sub-directorios:
      1. Código: todos los scripts, borradores de código, etc.
      2. Datos: todos los raw data, datos tabulares, etc. Todo lo que se generó durante un experimento, así como información proporcionada por otra persona.
      3. Resultados: todo lo generado usando código.
2. Usa enlaces simbólicos (==symbolic links, o symlinks) (ln -s) para evitar la redundancia de datos. Importantísimo, que a la hora de llamar el comando ‘ln -s’ se haga usando la ruta completa del archivo de origen, incluyendo cuanto menos el directorio home (“~/ruta/al/archivo” en lugar de, por ejemplo, “../ruta/al/archivo”).
3. Usa rutas (==paths) relativas entre sí. Por ejemplo, si trabajas en R, sitúa tu workingdirectory en “~/ProjectName” y haz las llamadas a lecturas de datos desde “Data/…”. ¿Que tienes algún dato o cosa que necesitas usar rápido y sin más importancia? Usa el consejo #2 (link simbólico a “Data/” ) para respetar la estructura decidida en la regla 1.

Si quieres más consejos a cuenta de la casa, continúa leyendo.

Mi caso particular

Personalmente, mi estructura de trabajo después de un año trabajando más a full en bioinfo suele ser como sigue. Vamos a seguir el ejemplo de un proyecto de genómica donde se están generando datos de distinto tipo, como RNA-Seq, ATAC-Seq, … en diferentes condiciones o tipos de experimentos (que bien podrían ser sub-proyectos), y que nuestro interés es encontrar genes o ciertos elementos sobreexpresados o sub-expresados por alguna razón:

• Directorio raíz del proyecto
  • Genoma: todos los archivos necesarios o relativos al genoma. NOTA: algunos de estos pueden ser links simbólicos a otras ubicaciones como Datos o Outputs
    • secuencia.fasta
    • anotación(.bed,.gff)
    • transcriptoma(.fasta)
    • proteoma(predicho o experimental, .fasta)
    • índices de genoma (softwares como bowtie, bowtie2, STAR, etc.)
    • índices del transcriptoma (softwares como kallisto, salmon, etc.)
  • Datos: los datos en crudo. Normalmente, los FASTQs, bien ordenados según muestra y/o lane de secuenciación. Idealmente, por cada tipo de experimento o dato tenemos una meta-tabla con los nombres de cada directorio, la condición/estadío/tejido
    • RNASeq
      • Timeseries
        • Estadío 1,2,3,
        • …
      • Inhibitor experiments
        • Control
        • Compuesto A,B,C
        • …
      • Knockout
      • Tejidos
        • Epitelio, Cerebro, Músculo,
        • …
    • ATACSeq
      • Timeseries
      • Inhibitor experiments
      • Knockout
    • ChIPSeq
      • Proteína A, B, …
      • …
    • Hi-ChIP
    • Hi-C
  • Código: como mi lenguaje principal de análisis downstream es R, este directorio lo dedico casi enteramente a tener MUY bien organizados los scripts.
    • RSCRIPTS
    • Packages
    • Programs (instalación personalizada)
  • Outputs: Los resultados de haber trabajado con cada tipo de datos en “Datos/”. Aquí sigo un criterio algo diferente al post original. Organizo todo en carpetas según el tipo de output obtenido, con la “excepción” de organizar todo lo relativo a los datos en subcarpetas de los mismos nombres. Por simplicidad explico un par de casos nada más:
    • output_RNA
      • Timeseries
        • “fecha_herramienta_mapping”: mapeos de transcriptoma, ordenados y con su metatabla al igual que en la carpeta datos. Formato de entrada pensado para que sea fácil cargar en R según qué herramienta
          • commands: carpeta donde están los scripts usados para generar lo que aquí se contiene. Esencial.
        • diff_RNA: sub-carpeta de outputs una vez se han identificado los genes de interés
          • GOterms (y dentro: commands/…)
          • associated_ATAC (y dentro: commands/…)
          • …
    • output_ATAC
      • Timeseries
        • “fecha_mapeo_output”(/commands/…)
        • “fecha_idr”(/commands/…): output del análisis de IDR
        • “fecha_counts”(/commands/…): output de los comandos para transformar los archivos de alineamiento contra el genoma en matrices de cuantificación (que luego irán a R, como en el caso del RNAseq)
        • diff_ATAC: ídem que con el RNAseq.
    • output_HiChIP
    • GO_annotation
      • “fecha_iteration_1,2,3…” según haya sido y/o convenga, y cada uno con su ./commands/ respectivamente
    • pfam
    • etc…

Consejos particulares:

• Pon fecha a todo. Esto incluye, por ejemplo, versiones distintas de un genoma, distintas iteraciones con distintos parámetros (o corrigiendo/puliendo cosas anteriores). Mi formato preferido, por cómo se ordena alfanuméricamente, es AñoMesDía, sin espacios y con ceros a la izquierda cuando haga falta. Por ejemplo: 20200513_ para el 13 de Mayo de 2020, 20201028 para el 28 de Octubre de 2020, and so on. Es más difícil de leer al principio, pero el hecho de que todo se quede ordenado cuando haces un ls … supera a todo.
• Guarda todos los comandos que corras en la terminal. Aunque sea un parseo rápido para crear/quitar una columna, genera un sh aunque tenga una única línea. Ten a mano una carpeta con los comandos usados. Pon también la fecha a los nombres de los archivos con los comandos, que nunca sabes cuándo vas a necesitar volver a lo que hiciste. Spoiler: muchas veces.
• Nombra los archivos y carpetas con nombres legibles por personas, explícitos, y con una estructura concreta que se repita. Esto facilita muchísimo el reusar scripts de veces anteriores, porque pasas menos tiempo cambiando líneas. Por ejemplo: no llames un día diff_RNA a los resultados del RNAseq, y al mes siguiente RNA_diff, porque te vas a volver loco a tí mismo, a tus compañeros, y a los pobres scripts.

Y de momento creo que eso es todo. Si recuerdo cualquier otra cosa la añadiré por aquí.

Fuente: https://constantamateur.github.io/2020-12-06-projMan/