 Hola, bienvenidos a esta sesión del NextLow and Escort, Community Training. Mi nombre es Julia y voy a presentar estas sesiones de training. Gracias por venir, esta es la sesión que haremos en castellano, pero hay otros idiomas, principalmente inglés, también está disponible en lugares o zanzas. Durante estas sesiones, tenemos previsto que sean un punto de partida para los que seáis nuevos en NextLow y en Escort. Es necesariamente un entendimiento básico de usar una terminal, también un entendimiento básico de herramientas informáticas que os ayudarán a entender los ejemplos porque vamos a usar pipelines para análisis informáticas como ejemplos, aunque también todos los conceptos son aplicables a otras diferentes disciplinas. Este training consta de cuatro sesiones de más o menos dos horas cada una, aunque puede variar entre un día o una sesión o otra, y también entre los diferentes idiomas. Entonces tenemos la sesión 1, que es esta bien véniga, luego una introducción. A NextLow empezamos con el training usando NextLow y luego tenemos una prueba de concepto que usaremos la partida de RMSc para como ejemplo. Luego tendremos la sesión 2, donde hablaremos más de NFCort, una introducción de que es NFCort, cómo podéis usar NFCort como usuarios y en el caso de ser desarrolladores como usar NFCort para desarrolladores y finalmente también hablaremos sobre módulos y support flows de NFCort. Luego en la sesión 3 hablaremos de cómo gestionar dependencias y containers. También hablaremos de canales, procesos y operadores de NextLow. Tenemos también una introducción agru, que es el lenguaje que está basado en NextLow y finalmente modularización, es decir, cómo crear módulos. Y finalmente la sesión 4, donde hablaremos de cómo configurar para ejecutar nuestra pipeline, también de diferentes sistemas de implementación, de cómo usar el cache y resume para correr la pipeline desde diferentes puntos de entrada. Finalmente tendremos como solucionar algunos errores o problemas y también una introducción a NextLow Tower. Para acceder al material de training, está disponible online en esta web www.nextlow.io. Este acceso gratuito en cualquier momento, siempre que queráis poder acceder, necesitaréis una cuenta de GitHub y os podéis crear también gratuitamente desde la página de GitHub. Y esto lo usaremos para acceder al tutorial de training que vamos a usar GitHub para hacer todos los ejercicios de training. Estas sesiones también están, las grabaciones de las sesiones están disponibles después del evento para que os podáis usar cuando las necesite y acceder a ellas más tarde. Finalmente tenemos en el Slack de NFCore que podéis entrar con este link. Os podéis unir a Slack y tenemos varios canales dependiendo del idioma donde podéis hacer preguntas. Allí hay voluntarios de la comunidad que estarán para responder las preguntas y ayudaros en lo que sea necesario. En el caso de que haya muchas preguntas, al principio puede ser que cuando salgan estos trainings haya muchas preguntas entonces puede ser que tarden un poco más en responder pero en principio se van a ir resolviendo todas. Y dicho eso, pues vamos a empezar ya con la introducción a NextLow. Empezamos pues con la introducción a NextLow. Esto es una introducción a la lista de datos reproducible con NextLow y NFCore. Cuando pensamos en NextLow, pensamos en OpenScience. Es la idea de que los datos y la manera de procesar estos datos debe ser libre, transparente y accesible para todos. Entonces pensamos en OpenSource. NextLow es de código libre. Es decir que el código está disponible online y cualquiera puede acceder al ver qué hace ver cómo funciona. También finalmente en OpenCommunity, tanto NextLow como NFCore son bien en su comunidad. Y entonces cualquier que quiera participar en esta comunidad puede unirse y hablar sobre NextLow o NFCore o participar también en su desarrollo. En este programa NextLow, la lengua que se usa para workflows o pipelines, análisis, principalmente es usada para análisis genómicos. La mayoría de los pipelines que existen se aplican a datos genómicos pero también hay otras pipelines en otros campos más allá de la biología o la biología de las ciencias de la vida. Y todo lo que vamos a aprender también en este training es aplicable a otros campos. Cuando tenemos una pipeline de análisis puede ser que tengamos una cantidad muy grande de output, ficheros muy grandes que se generen muchos más datos de output. Además también usamos diferentes herramientas para el análisis incluso podemos usar diferentes scripts y además todos estos tienen sus dependencias de otros programas o librerías que se usan para este análisis. Además también la manera de generar, de pasar de un output puede ser dinámica dependiendo del tipo de análisis que tengamos la manera de ejecutar este análisis puede variar. Para visualizar esto de otra forma tenemos aquí este ejemplo que es una pipeline de anotación de un programa. Entonces cada número que se ve aquí corresponde a un proceso es decir una parte de esta pipeline que ejecuta un programa y cada fletcha representa un canal que sería la unión de cada uno de estos procesos. Esta pipeline en real tiene 70 tareas 55 scripts customizados y además es a 39 programas o librerías diferentes. Aquí tenemos un artículo que es desde el 2017 del principio de los principios de NextLow. En este artículo se habla de la reproductibilidad. Con todo esto usando tantas herramientas diferentes tanto software diferentes procesos todo lo que puede variar en un tipo de análisis es difícil reproducir esto, reproducir los mismos resultados en dos entornos diferentes. Por ejemplo aquí en este primer gráfico estaban ejecutando un análisis con Amazon Linux y Mac con Extravidocal o con Mac y software nativo en local o Amazon Linux y también software nativo y aunque la mayoría de output estos son los genes anotados en una pipeline de anotación de genes aunque la mayoría coinciden en los tres sistemas diferentes no todo es reproducible y aquí abajo en estos gráficos tenemos la diferencia entre Amazon Linux y programas nativos y Mac y programas nativos también y difieren en cambio cuando usamos NextLow y containers en este caso el ejemplo se está usando el docket conseguimos que los resultados sean reproducibles. También este es otro problema bastante común cuando encontramos una publicación con unos métodos que queríamos replicar suele pasar que hay mucha información por ejemplo formatos de los hecheros, versiones o metadatos que no están disponibles, no están especificados en esta metodología entonces cuando queremos reproducir un análisis suele ser complicado. Una opción que puede ayudarnos a resolver todos esos problemas de reproducibilidad es NextLow NextLow es este lenguaje que se compone de varios conceptos en primer lugar tenemos los procesos que serían como modelos pequeños cada proceso ejecuta una tarea diferente y luego tenemos los canales que serían los que unen estos procesos es decir el output de un proceso va a ser el input del siguiente la unión entre estos procesos son los canales y finalmente el conjunto de los procesos unidos por canales es la workflow o pipeline aquí tenemos un ejemplo de una workflow en NextLow muy básica en este caso tenemos un proceso que tiene el nombre de FastQC tiene un input también genera un output y el script que en este caso esté comando para usar el programa FastQC en caso de que no sepas lo que es es un programa que se usa para analizar la calidad de secuencias y entonces tenemos la workflow que en este caso está definiendo un canal input como de entrada y está usando este proceso entonces esta pipeline es muy básica y durante este training vamos a entrar más en detalle en cada uno de estos de estas partes NextLow también tiene el clícito a la paralelización es decir cada proceso es independiente de otro si tenemos ficheres de entrada y estos ficheres son independientes al ser cada proceso también independiente y correr por separado independientemente de los demás esto es automáticamente paralelizable en NextLow entonces NextLow mismo gestiona la paralelización para hacer que los análisis sean más rápidos aparte de este concepto de paralelización tenemos la reentrada o resumir de eso también hablaremos más a fondo, más adelante pero básicamente podemos usando Resume entrar y empezar a ejecutar la pipeline no desde principio sino desde un proceso intermedio esto nos facilita si por ejemplo ha habido algún fallo y no queremos volver a correr las partes del inicio que sí han funcionado estamos ahorrando todo este tiempo de computación seguramente todos los ficheres que habrá generado entonces podemos empezar a ejecutar desde cualquier punto intermedio y finalmente pues estas workflows o pipelines de NextLow también son reusales es decir que son disponibles y se pueden usar en diferentes sistemas o diferentes grupos laboratorios que pueden rehusar la misma pipeline sin necesidad de crear otra nueva luego podemos decir que NextLow tenemos estos tres grupos en cuanto a código tenemos el control de versiones por ejemplo podemos usar Git y esto nos permite pues tener un control de cada versión de la pipeline a medida que se van viendo actualizaciones o implementando nuevas funciones tenemos un seguimiento de las versiones anteriores de los cambios que ha habido en cuanto a software usamos containers en este caso pues podemos usar diferentes sistemas para gestionar estos containers como por ejemplo Docker, Singularity y cuando computación también pues ahí NextLow se puede ejecutar en local también en diferentes clusters o en la nube y es fácilmente escalable en cuanto a reproducibilidad por ejemplo aquí tendríamos el aparato de los containers aquí en esta línea estamos usando Conda el container de Conda que tiene el programa Salmon pero esto se puede cambiar fácilmente por ejemplo también Conda por container y aquí podríamos estar usando el container diferente lo mismo con el ejecutor en este caso pues está usando Slab como gestor de diferentes tareas y como resumen pues es reproducible entre diferentes ejecuciones también es portable en diferentes sistemas y es escalable y eso sería todo el introducción de NextLow un celular de NFCore NFCore es una comunidad que colecciona diferentes pipelines de análisis que están construidas usando NextLow ahora mismo NFCore tiene 75 pipelines y también existe un un paquete de Python que es NFCore Tools del que hablaremos más también a fondo en la sesión 2 y este paquete pues es como una ayuda para ejecutar pipelines para escribir al programar estas pipelines y también para test ahora mismo NFCore también dispone de 700 módulos y 24 sub workflows disponibles cada módulo sería una manera de programar un proceso que ejecuta una tarea específica NFCore recoge estos módulos que están testeados es decir, tienen sus test y además son rehusables que tocan cualquier pipeline puede usar este mismo módulo y usarlo en esta pipeline y luego las sub workflows que básicamente son unión de unos pocos módulos que ejecutan tareas más grandes NFCore tiene estos tres conceptos el primero sería que desarrolla en comunidad es decir, que se trata de una comunidad y la gente de la comunidad desarrolla conjuntamente además también se usa una plantilla común es decir, que todas las pipelines y todos los módulos de NFCore siguen la misma estructura con lo que es más fácil reproducirlas, mantenerlas y que diferentes personas puedan contribuir a estas diferentes pipelines y finalmente el concierto de colaborar en lugar de duplicar es decir, que NFCore pretende que haya una sola pipeline para cada tipo de datos y de análisis en lugar de generar una nueva versión humana pipeline lo que se incentiva es que la gente colabora en las pipelines que ya son existentes y hacen lo mismo y puedan implementar nuevas funcionalidades o ir mejorando estas pipelines existentes y luego también un poco de estadísticas NFCore tiene ahora mismo más de 4.000 usuarios en Slack también 500 miembros en la organización de GitHub y 1.500 contribuidores en GitHub también más de 3.000 seguidores en Twitter, 90 historias hay 11.000 por request, 32.000 además NFCore es una comunidad global hay usuarios de alrededor del mundo y además ahora también nos estamos expandiendo a diferentes áreas como por ejemplo Sudamérica entonces si os encontráis en una de estas áreas o regiones y queréis hacer crecer la comunidad tenemos en ganadas también de que pongáis en contacto para hablar de cualquier cosa de lo que os gustaría que pasara en Nexlo y NFCore en vuestra región este es un artículo del 2020 que habla sobre qué es NFCore y lo que hace la comunidad de NFCore y qué puedes hacer formando parte de esta comunidad y pasamos a la introducción una pequeña introducción a Nexlo Tower Nexlo Tower es un producto de sequela lo que proporciona es una interfaz para ejecutar pipelines también para gestionar y monitorizar estas diferentes ejecución de las pipelines se pueden también compartir de equipos es decir que todos los integrantes del equipo pueden tener eso esta misma ejecución y también crea una infraestructura enano hay diferentes planes en Nexlo Tower tenemos el community open source que sería el proyecto luego también hay el acceso a cloud que tiene versión de la Twitter versión de pago finalmente la versión para empresas o comercial entonces si estéis interesados podéis ir a la página web de Tower ponerse en contacto con el equipo y eso sería todo en cuanto a la introducción una cierta información sobre mí que estoy asociada al Quantitative Biology Center de la Universidad de Tuningen luego también tenéis aquí la página de Nexlo Summit que tuvo lugar en octubre del año pasado tenéis los vídeos disponibles en caso de que queréis saber más sobre la página web de Nexlo a las grabaciones y los vídeos están disponibles en esta página web y luego aquí tenemos el Nexlo Summit que está sucediendo ahora y la jacadanda de Nexlo que pasará en un par de semanas y aquí tenéis la página web de Nexlo y Nexlo para más información y también para ver los diferentes eventos que llevan sucediendo y pasamos entonces pues ya al Training vamos a empezar pues con el Training y si accedéis a este link el training.nexlo.io vais a poder acceder al tutorial que vamos a ir siguiendo entonces esta es la página que se abre lo que vamos a seguir es el taller de entrenamiento básico entonces sí que le queréis comenzar comenzar ahora y aquí tenemos el tutorial vais a ver que la mayoría de puntos ahora van a estar en inglés pero la idea es que estén disponibles en español en algún momento entonces puede que los tengáis pronto también disponibles en español esta es una introducción pero durante las siguientes sesiones iremos también profundizando un poco más entonces empezamos con este tutorial la idea del curso es que al final seáis competentes en la escritora de scripts de Nexlo también que conozcáis los conceptos básicos de Nexlo como canales, procesos y operadores que comprendáis el flujo de trabajo con contenedores y flujos de trabajo que sería lo mismo que la traducción de workflow o también que es lo mismo pipeline después también que podáis comprender las diferentes plataformas de ejecución que son compatibles con Nexlo y finalmente que conozcáis la comunidad y el ecosistema entonces vamos a empezar por configurar el entorno en el que vamos a estar trabajando practicando este tutorial veréis aquí también que tenéis links de otros recursos como la documentación de Nexlo, el Slack y otros páginas web que os pueden servir para buscar ayuda o más información en notas para realizar este tutorial existe la posibilidad de instalarlo localmente en vuestro ordenador tendréis aquí primero tenéis las dependencias que vais a necesitar las instrucciones de cómo instalar Nexlo y luego también docker en este caso como ejemplo aunque pudéis escoger otros softwares de contenedorización como descargar también el training material que contiene todos los scripts y los features que vamos a estar usando pero otra opción y la más recomendable y es la que vamos a usar ahora es usar github entonces tenéis este botón aquí que si lo clicáis se va a abrir perdón no voy a abrir en una pestaña diferente se va a abrir un entorno de github esto puede tardar un poco porque está preparando el espacio en el que vamos a trabajar también descarga el container que ya tiene Nexlo y todo lo que vamos a necesitar incluidos los scripts que vamos a estar usando instalados entonces github es gratuito lo podéis usar hasta 50 horas al mes en el entorno básico de forma gratuita podéis acceder con vuestras credenciales de github también podéis crear la cuenta de forma gratuita en la web de github y aquí vamos a estar trabajando ahora a ver cuando termina de abrirse en el caso de que tengáis algún problema siempre podéis pausar el vídeo y solucionar lo que necesitáis antes de seguir bueno pues una vez que se abre github se abre con la interfície de visual studio code aquí es donde queremos esto se puede cerrar es donde abriremos nuestros subscribes y podremos estar modificándolos y programando también se abre la página de donde veníamos que es decir podéis ir siguiendo el tutorial desde aquí o bien cerrarlo y seguirlo desde el browser en la parte de abajo tenemos la terminal donde vamos a estar ejecutando los comandos y aquí en la izquierda tenéis para poder navegar en las carpetas y los ficheros los ficheros de ejemplo que vamos a usar entonces vamos a empezar por la introducción NextLow es un lenguaje de orquestración de workflows o como hemos dicho flujos de trabajo y también es un lenguaje de dominio específico y sus principales características son su portabilidad y reproducibilidad de estas workflows también es escalable y paralelizable y también para implementación y finalmente integra herramientas o programas existentes en diferentes sistemas y también se adapta a los estándares de la industria vamos a usar un poco de tiempo para definir estos conceptos que son básicos y los vamos a estar usando mucho durante estas sesiones que son los procesos y los canales como hemos dicho NextLow se organiza en procesos que son los encargados de ejecutar una tarea y se conectan estos procesos con canales que son los que transportan los datos en este esquema de ejemplo que tenemos aquí tenemos un canal con los datos x y y y estos datos son independientes y son el input de este proceso de aquí que ejecuta una tarea independiente esto por ejemplo podría ser un fichero el proceso puede ejecutar la tarea para cada uno de estos elementos del canal de forma paralela es decir que no es necesario que nosotros hagamos ninguna modificación especial para que esto sea ejecutado en paralelo entonces cada tarea se va a ejecutar y va a devolver su output que en este caso se ha llamado x y y z y podríamos de la misma forma poner este output en un canal igual que el que tenemos aquí de input luego otro otro concepto importante de NextLow es que cuando se ejecuta NextLow es cuando se determina cómo es ejecutado es decir nosotros en NextLow podemos programar en cualquier tipo de lenguaje de programación que queramos por ejemplo Python o R o incluso Bash lo que también orquestramos nuestras tareas como queremos que se vayan a ejecutar usando el lenguaje de programación con los procesos de los canales que hemos comentado también podemos usar diferentes softwares que ya existen programas y para eso usamos containers que van a gestionar todas sus dependencias y son fáciles de usar y de hablar es decir que no es necesario que instalemos todas sus dependencias y finalmente tenemos el control de versiones que nos permite pues tener un seguimiento de los cambios que lleva teniendo nuestra workflow y todo esto es orquestrado por NextLow en runtime en el momento de ejecución es por esto que es altamente escalable es decir que por defecto NextLow para ejecutar todo esto en local pero puede escalar y ejecutar la misma pipeline tanto en nuestro ordenador como en un cluster como en la Nueves y es el caso sin necesidad de que modifiquemos lo que ya hemos programado es decir que la misma workflow puede correr simplemente definiendo donde queremos ejecutarla puede escalar cualquier otro tipo de sistema NextLow también es un lenguaje de dominio específico y lo que hace es ayudarnos a hacernos más fácil la programación de análisis de datos en estas workflows está basado es una extensión de Groovy que a su vez está basado en Java y aunque está bien conocer un poco de cómo funciona el lenguaje de Groovy en el caso de que queramos programar alguna cosa muy específica dentro de nuestra workflow no es para nada necesario ser experto en Groovy o en Java para programar en NextLow vale y ahora lo que vamos a ver es ya vamos a usar nuestra primera workflow con este script gelo.inf si vas siguiendo el tutorial veréis que aquí hay estos símbolos que os dan más información y os explican cada una de las líneas del fichero en el script lo que vamos a hacer es abrirlo en github este script gelo.inf que es el mismo que teníamos en la web este es un script típico que implementa una workflow básica de NextLow entonces primero tenemos el shivan que nos está diciendo que es un código de NextLow luego estamos definiendo un parámetro vamos a profundizar más en que es un parámetro pero en general siempre van a estar definidos por esta palabra clave params punto seguir del nombre a que le queramos dar en este caso le estamos designando un string que es hello world luego estamos creando un canal también veremos en otras sesiones las diferentes formas de crear canales aquí estamos usando channel off y la introducimos nuestro parámetro que hemos definido anteriormente y este canal lo asignamos con un igual ahí le damos el nombre de greeting channel greeting barabaja fh luego tenemos los procesos script letters y convert whopper los procesos se describen con la palabra process entre los cloudators y tienen las secciones de input en este caso nuestro input es un valor también en diferentes tipos de variables que podríamos tener como input output en este caso tenemos un valor y le damos el nombre de X tanto el nombre de las variables como el nombre de los procesos son totalmente customizables y así podéis ponerle el nombre que prefierais lo que sí que es recomendable es poner un nombre un poco descriptivo de lo que va a hacer nuestro proceso luego tenemos también la sección de output aquí tenemos un tipo de variable que definirá los ficheros y el patrón que seguirán los ficheros que son de output en este caso se usa el asterisco como una expresión regular que es decir que cualquier tipo de carácter está incluido aquí o sea todos los ficheros que tenga el prefijo chunk barabaja seguido de cualquier otra cosa para ir a nuestro output finalmente tenemos la sección de script que podéis ver en algunos casos los procesos el script está definido con la palabra clave script aunque esto no es necesario porque al tener las tres comillas dobles ya se identifica directamente como la sección de script aquí podemos programar en cualquier lengua que quedamos por ejemplo podríamos estar usando Python para interpretar como bash entonces aquí estamos ejecutando comandos de bash tenemos printf que va a imprimir nuestra variable que hemos definido como input x y para identificar que es una variable o para definir que es x es una variable usamos el símbolo del dólar luego vamos a estar usando split que lo que va a hacer es separar nuestra string en trozos o palabras de seis caracteres y lo va a guardar en un fichero con el prefijo chunk barra baja luego tenemos nuestro segundo proceso compratualper este proceso tiene un input que en este caso es un fichero también y le hemos llamado y un output aquí estamos usando la palabra clave standout es decir que todo lo que sea standard output va a ser nuestro output y lo que estamos haciendo en la sección de script es ver el contenido de nuestro fichero otra vez usamos el dólar para marcar que esto es la variable vemos el contenido con cat y luego se usamos este comando que lo que va a hacer es sustituir todas las minúsculas por mayúsculas finalmente tenemos la workflow que es lo que orquestra como nuestros procesos en donde primero estamos ejecutando nuestro primer proceso split letters el input que va definido entre paréntesis es el canal que habíamos definido al principio in creating channel que contiene la frase hello world y el output lo asignamos otra vez con el igual a un canal llamado letters channel este canal a su vez es el input de nuestro segundo proceso aquí estamos usando flatten flatten es un operador de nextflow ya veremos también en sesiones más adelante diferentes operadores nextflow tiene implementados estos operadores que nos ayudan a operar con los canales entonces aquí lo que está haciendo flatten es que los ficheros que retorna nuestro primer proceso en este caso va a retornar dos cuando divida esta frase en lugar de leerlos todos juntos lo que hace flatten es separarlos y que cada uno sea un elemento diferente luego lo asignamos a results channel y finalmente lo que vamos a hacer con view es ver el contenido de results channel y aquí it se usa it viene de item de elemento se usa como para darle nombre a la variable de cada elemento que contiene este canal es decir que lo que estamos haciendo es imprimir por pantalla cada uno de los elementos de nuestro último canal entonces vamos a ejecutar nuestra papel perdón lo que vamos a hacer primero antes de ejecutar nada es definir vamos a ver que aquí tenemos nextflow ya instalado nuestro en nuestro entorno de github si ejecutamos sólo nextflow veremos que que nos aparece la ayuda y por ejemplo podemos ver la versión con v aquí estamos usando la versión 22.10.6 nextflow cambia bastante regularmente le van implementando nuevas funciones entonces la versión va cambiando constantemente lo que vamos a hacer para asegurarnos de que todo lo que estamos haciendo es reproducible tanto en vuestro ordenador como en el mío es usar la misma versión y para eso vamos a exportar esta variable de entorno nextflow version nxf y vamos a usar la versión 22.04.5 y ahora si volvéis a ver la versión veréis que está descargando ahora ya estamos usando la misma versión 22.04.5 una vez hecho esto podemos ejecutar ahora ya entonces cada vez que corramos que ejecutemos una pipeline con nextflow run y el nombre del script primero lo que vemos es la versión de nextflow que estamos usando luego el nombre del script que hemos ejecutado también se le asigna un nombre a este a esta ejecución en particular y un un número decimal y aquí también vemos la versión de nextflow que ahora está usando dsl2 antes existía dsl1 pero con las nuevas versiones sólo está disponible dsl2 que esto indica la versión de lenguaje luego tenemos el ejecutor que ya me has dicho que por defecto es local es decir que esto se está ejecutando aquí en el entorno de gitbot y luego tenemos una línea para cada uno de los procesos que hemos ejecutado primero split letters que hemos ejecutado una vez y aquí tenemos el porcentaje de compresión en este caso por si ya termina lo tenemos el 100% y luego nuestro segundo proceso que en este caso se ha ejecutado dos veces ya que nuestro input se ha dividido en dos partes luego es el proceso dos y ha ejecutado dos veces y aquí tenemos también un valor hexadecimal asignado para cada una de las tareas que se han ejecutado y ahora vemos para que sirva este valor entonces vemos a nuestro input que ha imprimido por pantalla el contenido de result channel separando nuestras string input en dos y pasando a mayúscula entonces una cosa que pasa, si volvemos a ejecutar puede que pase o puede que no es que el orden no sea el esperado o sea hello world sino al revés world hello eso es porque al poder ejecutar las diferentes tareas, al poder ejecutar las diferentes tareas en paralelo, la primera que acabe, la primera que acabe, será la primera que introducirá el resultado. Entonces, bueno, ahora tres veces de tres hemos obtenido gelo, pero puede pasar que obtengáis el orden inverso. Vale, esta, esta valóricia decimal que se le ha asignado aquí cada vez que ejecutemos next loop, se va a crear una carpeta work dentro de esta carpeta. Es donde se guarda cada tarea donde se ha ejecutado. Y esto es el nombre que nos da este valor. Por ejemplo, aquí tenemos la carpeta 12, que es aquí. Y dentro hay estas dos carpetas aquí, en el output de next loop, siempre vemos los seis primeros caracteres. Y dentro contienen los ficheros que hemos obtenido como output, en este caso, en dos ficheros que vienen de este primer, primer proceso, si miramos el contenido de los ficheros, tendrán, pues en este caso, contienen gelo y si miráramos la otra carpeta, en este caso, el fichero que vemos es el input, que es un enlace del fichero anterior. Si vemos lo que contiene dentro, pues este ABD debería contener norm y, efectivamente, obtenemos work. Entonces, para hacer una pequeña demostración, voy a guardar la carpeta work y voy a volver a ejecutar el script pasando este parámetro. Next loop tiene diferentes parámetros que podemos usar. Iremos viendo algunos a lo largo de las sesiones. Este, lo que hace, cuando estamos hablando anti log false, lo que hace es que nos va a imprimir en lugar de una línea para cada proceso, lo va a desglosar y tendremos una línea para cada tarea. Entonces, el proceso uno se ha ejecutado una vez. En cambio, el proceso dos, tenemos la primera vez que se ha ejecutado y la segunda vez que se ha ejecutado una para cada fichero. Y ahora sí vemos la carpeta work que se ha creado otra vez. Efectivamente, vemos que hay estas tres carpetas, igual que habíamos visto antes, con los ficheros que contienen, pues, halo, como esperamos. Vale, lo que vamos a hacer ahora es modificar nuestro script un poco. Por ejemplo, el segundo proceso, el lugar de convertir a mayúsculas, lo que vamos a hacer es usar este comando red que lo que hace es hacer el reverse, es decir, girar las palabras. Entonces, lo que podíamos hacer ahora cuando ejecutamos una vez modificado es usar el parámetro resu. Aquí una cosa apunte es que estamos dando los parámetros con un solo guión antes del parámetro, aunque normalmente probablemente estaréis acostumbrados en que la mayoría de comandos de terminal, cuando tienen un parámetro largo, se proporcionan con dos guiones. Esto es una peculiaridad de Nextflow y se usa así para diferenciar los parámetros que estamos dando a Nextflow y los parámetros que forman parte de la pipeline en sí. Entonces, vamos a usar aquí Resion. Y lo que vamos a obtener es que el primer proceso ahora nos aparece aquí Touch. Eso quiere decir que gracias a esta carpeta Work que hemos visto, Nextflow tiene guardado cada una de las tareas que se han ido ejecutando. Entonces, en el momento de ejecución, puede acceder a cada una de estas carpetas cuando tenemos Resion y puede ver si se ha ejecutado o no se ha ejecutado y si hay algo que ha cambiado, si se ha modificado alguna cosa de esta tarea en concreto. Entonces, como nuestro proceso 1 no había cambiado, puede rehusar sin necesidad de ejecutar otra vez todo el contenido. Y por eso vemos aquí Touch. En cambio, el proceso 2, como si tenía esta modificación, se ha vuelto a ejecutar otra vez y tenemos efectivamente el resultado ahora girado. Eso es muy útil que usar Resion. Si, por ejemplo, cuando estáis desarrollando queréis hacer algún cambio, especialmente si tenéis procesos que han sido muy costosos computacionalmente, no es necesario volverlos a ejecutar todos si ya han funcionado y ya estamos seguros y podemos entrar la plan en cualquier punto usando este Resion a partir del punto donde ya hemos hecho una modificación. Otra cosa que hemos visto es, en este caso, Params. Aquí habíamos definido un parámetro con la palabra Params, que era este string, hello world, pero los parámetros también se pueden proporcionar a través de la línea a la command line, nuestro comando. Entonces, bueno, ahora volvamos a ejecutar lo mismo que antes. Veremos que los dos procesos están cached, es decir, que no se ha ejecutado nada por segunda vez, simplemente se ha rehusado todo. Bueno, lo que podemos hacer también es dar un parámetro. Eso, como ya he dicho, se proporciona con dos guiones, es decir, que no sería un parámetro, un argumento de Nexlo, sino que es un parámetro de la parnet. Y lo proporcionamos, pues si nuestro parámetro sería más adquirido, le vamos a dar una frase diferente, por ejemplo, hola mundo. Y ahora veremos que se ha sobrescrito el parámetro que teníamos aquí, porque hay un orden de preferencia. Entonces, todo lo que hemos proporcionado por command line, por el comando, tiene preferencia y sobrescribe lo que se había definido en el script. Y ahora, como veis, en lugar de usar hello world, estamos usando hola mundo y el output es hola mundo, también como otra pequeña demostración, si pudiéramos una string más larga. En este caso, se ha dividido en cuatro troces. Entonces, el proceso número 2 se ha jugado cuatro veces aquí. Vale, entonces, los parámetros también se pueden proporcionar a parte del dentro del script, como pipeline O, a través del comando. También se pueden proporcionar con un fichero de configuración. Esto lo veremos también en otras sesiones más adelante. Y también veremos el ordente de prioridad que tiene. Vale, pues hemos terminado esta primera parte. Otra vez, si vais a la página web siguiendo el tutorial, podéis consultar la información extra. Lo que hemos hecho ha sido ejecutar nuestro primer script. Luego hemos visto cómo se arreció, cuando hacemos una modificación y que no hace falta cambiar, ejecutar todos los procesos que ya estaban, que ya se habían ejecutado. También hemos visto cómo proporcionar parámetros a nuestro workflow. Y finalmente, en el caso de que os sea más fácil entender todo esto que hemos estado haciendo en este formato de Dac, de gráfico, tenemos aquí un resumen de lo que hemos visto. Teníamos un input que era Hello World. Luego lo hemos introducido en un canal que ha sido el input de nuestro proceso 1. A su vez, este ha generado dos ficheros como output que han ido a otro canal, letters, letters channel. Luego este canal ha sido el input de nuestro proceso 2 y nuestro proceso 2 ha retornado como output, el standard output, y luego lo hemos visualizado. Vale, entonces lo que vamos a hacer ahora es pasar a la siguiente parte, que es una prueba. Vamos a estar usando la página de RNA-Seq como ejemplo para ver una pipeline real. Esta pipeline que vamos a usar ahora, RNA-Seq, es una demostración, no es una pipeline real, sino que es una versión más pequeña o más simple que vamos a usar como demostración, pero para que veáis cómo se puede aplicar a una aplicación real, a datos reales, en este caso son datos de un sector más biológico, más médico, entonces RNA-Seq se usa para la análisis de datos de secuenciación de RNA. En el caso de que no sepáis qué es RNA-Seq, no tengáis una formación más biológica. No pasa nada, la intención es que podáis pensar en cómo aplicar las herramientas de Nexlo que vamos a estar viendo en vuestros programas que usáis normalmente o otros tipos de datos que vosotros uséis. Entonces, vamos a empezar yendo otra vez a nuestra sesión de KitKat. Ahora ha empezado la sesión de cero sin querer si había pagado. Vale, ya no vamos a necesitar más Hello, sino que vamos a usar ahora Script1.nf. Voy a empezar para rápidamente explicar cómo comentar. En Nexlo, un comentario con dos barras inclinadas nos permite comentar nuestro código y también, además, podemos poner múltiples líneas de comentarios con barra inclinada y asterisco para abrir y asterisco para cerrar. Entonces, tenemos en este Script lo que vamos a ver es que estamos dando diferentes parámetros, como ya hemos visto antes precedidos por la palabra clave params. Tenemos reads, transcript on file y multi-QC. En este caso, los tres son strings, son rutas a ficheros. Aquí estamos usando Projecteer. Projecteer es una variable especial que se usa para definir la carpeta del proyecto en el que estamos trabajando. Entonces, tenemos los hicheros que vamos a usar en reads, que eso los podemos ver aquí, en data, ggail, y vamos a usar todos los que empiezan por GAT y luego uno o dos que son estos dos hicheros aquí. Entonces, tenemos transcript on file, que también está aquí, transcript on, FASTA y finalmente multi-QC, que en este caso es una carpeta. Lo que vamos a hacer es ejecutar este script. Y lo que estamos haciendo aquí es imprimiendo, usamos println, este es un script en Excelow. Básico, aquí no tenemos ningún proceso, ningún workflow, simplemente estamos imprimiendo este string reads y la variable que se va a popular ahora y imprimiremos params.reads. Entonces, aquí vemos el resultado, reads es a workspace, GITBOT, NFtraining, data, ggail, GAT, uno y dos. En este caso veis que se ha substituido también project.dir por workspace.gitbot.nftraining, que es efectivamente la carpeta en donde estamos ahora. También podemos, es decir, en el... Siguiendo el tutorial, una de las cosas de los ejercicios que se propone es añadir otro nuevo parámetro. En este caso, un parámetro que se llama outdir. Os invito a pausar este vídeo ahora y intentar definir este nuevo parámetro y además podemos imprimir cualquier otro parámetro. Entonces, podéis probar de imprimir, en lugar de reads, imprimir nuestra carpeta de output. Podéis posar el vídeo. Y en el caso de que ya habéis descubierto cómo hacerlo, básicamente tenemos que proceder nuestro nuevo parámetro por la palabra params y le asignaremos un nombre de la carpeta que vamos a querer usar, de output, por ejemplo, results. Y aquí pues vamos a imprimir nuestro output. Y si lo ejecutamos, vemos que en este caso se ha impriso el contenido de params outdir, que era results. Entonces, podemos añadir cualquier parámetro que queramos. La siguiente cosa que nos propone el tren es usar log.info. Voy a copiar ahora este puso de código para que lo podamos ver. En lugar de imprimir nuestros resultados con print, lo que vamos a usar es log.info que nos define, en este caso en un string de múltiples líneas, la información en un log que se va a imprimir cuando ejecutemos este fichero. Entonces, vamos a imprimir cada uno de nuestros parámetros, incluidos output que acabamos de definir. Y aquí estamos usando strip indent que es para eliminar la iniciación en cuanto imprimimos esto por pantalla. Así que otra vez podemos probar de ejecutarlo. Y efectivamente, vemos que en este caso se ha impriso lo que habíamos definido como volvir populando las variables que habíamos definido con el símbolo de total otra vez. Aquí también mencionar que estamos usando los corchetes, los cloudators para indicar que todo es una variable. Todo lo que está entre cloudators forma parte de la variable. También podríamos definir estas variables de aquí entre cloudators. Vamos a pasar al script número 2 ahora, script 2.nextload. Aquí ya teníamos los parámetros igual que antes. Aquí ya veis que incluimos comentarios para diferenciar las secciones. Y luego tenemos un proceso index que tiene otra vez sus secciones input output script. En este caso input es un path a un fichero, o sea, y la variable le llamamos a transcript. Luego tiene un output que es también un fichero nombrado salmon index. Y el script que ejecuta este programa salmon. Ahora vamos a ver que estamos usando el argumento threads y pasamos task.cpu. Task se utiliza similar a como usamos los parámetros, como usamos params aquí. Y sirve para especificar sí, parámetros que va a usar este proceso. En el caso de CPUs, estamos controlando las CPUs que asignamos a este proceso cuando lo ejecutamos. Luego también estamos usando aquí el input, la variable otra vez con el símbolo de dólar transcript. Y finalmente guardando el resultado en una carpeta perdón, en este caso salmon index. Y aquí tenemos la workflow. Ahora también vamos a ejecutar este script. Y lo que hace la workflow es pasar como input para el transcriptom file, es decir, que el fichero transcriptom.fr, que digamos, definido aquí es nuestro input y es el que estamos usando. Y guardamos todo en el canal index channel. Entonces aquí vemos un error. Esto es esperado. Vamos a ver el mensaje de error. Normalmente cuando tengamos un error está estructurado de esta forma. Primero tenemos la causa, que nos indica el código del error 127, el comando que se ha ejecutado. Aquí veis que ya se ha sustituido a la variable por el nombre del fichero. Es el comando que ha ejecutado la tarea. Otra vez el estado, el output, que en este caso está vacío, y el error. ¿Qué nos dice? En la línea 2 no hemos encontrado salmon. Ese es esperado porque como habíamos dicho antes, por defecto, NextFlow está ejecutando nuestras tareas en local. Entonces vamos a ver la carpeta que ha creado. Aquí nos dice siempre el nombre, el pad de la carpeta, donde está el proceso que ha fallado. Y aquí vemos que tenemos nuestro fichero de input transcriptom.fr, pero si vamos a listar a todos los ficheros incluidos los ocultos, vemos que hay otros ficheros que se crean aquí. Estos son, ya que NextFlow está ejecutando esta tarea dentro de esta carpeta como un entorno independiente, debe tener todo lo que necesite para ejecutarse disponible en esta carpeta o accesible desde esta carpeta. Entonces el programa salmon en este caso no está disponible y desde aquí no lo tenemos instalado en local. Pero como hemos dicho antes, lo que podemos hacer, de hecho vamos a ver el contenido de alguno de estos ficheros, por ejemplo, todos estos se crean automáticamente, son creados por NextFlow. Automáticamente al ejecutar cada tarea son todo lo que necesita para ejecutarse. Perdón, aquí tenemos este fichero y como veis obtiene el script que queríamos ejecutar en nuestro proceso. No lo tenemos aquí en este fichero comand.sh y por ejemplo, si quisiéramos ver el output, lo tendríamos en out, que hemos dicho que está vacío o si miramos un power de error, vemos también el comando de error que hemos obtenido. Entonces, ¿cómo vamos a resolver este error que tenemos? Tenemos un programa que no está uso en IPv3. Como ya hemos dicho, tenemos integrado en NextFlow, puede integrar cualquier software de gestión de programario. En este caso, normalmente, bueno, aquí como ejemplo, estamos usando Docker y como vamos a ver el script stone, vamos a abrir este fichero que tenemos aquí, también en nuestros ficheros navegables. A NextFlow.config, este es el fichero de configuración donde normalmente tendremos a definiremos algunos variables que queremos para la configuración de nuestro run, nuestra ejecución. En este caso, hemos definido qué queremos usar un container, está decidido por la palabra clave process, es decir, que para procesos queremos usar un container y hemos definido qué container queremos usar. También hemos definido algunas opciones, parámetros que le queremos pasar al Docker, pero lo que hemos hecho es decirle a NextFlow que queríamos usar Docker, por eso se ha ejecutado en local y está intentando encontrar los programas en local. Entonces, lo que tenemos que hacer, podemos hacer, es, voy a observar el resumen ahora para tenerlo aquí ya para las siguientes ocasiones, para oír un poco más rápido, decirle qué queremos correr, ejecutar este script usando Docker y entonces el error debería estar solucionado. Efectivamente, hemos ahora podido ejecutar nuestro proceso que teníamos aquí en el script, nuestro workflow, para no tener que proporcionar este argumento cada vez que queramos ejecutar esto, lo que podemos hacer es definir en nuestro fichero de NextFlow.config qué queremos usar Docker siempre. Entonces escribiremos Docker en myPold. Entonces estamos habilitando usar Docker. Como puedes ver, ahora sí tenemos este argumento, pues también debería correr. Efectivamente, pues ha vuelto a ejecutarse, en este caso, pues catch, porque hemos usado resumen y se había ejecutado una vez. Vale, NextFlow.config ya lo podemos cerrar ahora y lo que vamos a hacer es ver lo que tenemos en este canal. Igual que hemos usado antes, el operador vio lo podemos usar otra vez para ver qué hemos generado de output, que lo hemos guardado en este caso. Nuestro output era todo la carpeta de esta Salmon.index y vamos a ver qué contiene el canal de output. Y aquí veis que se nos ha imprimido el elemento que contenía este canal, que es el path. A la carpeta de output en donde podemos inspeccionar un poco y tenemos dentro de Salmon.index. Tenemos todos los ficheros que son el output de este comando, de este programa que hemos estado ejecutando de momento, pero solo están dentro de nuestra Work Directory, de nuestra carpeta Work. Ahora vamos a ver cómo podemos guardar estos ficheros en algún sitio más accesible para no tener aquí y que acceder en la carpeta Work, que realmente es solo para NextFlow para poder ejecutar todas las tareas. Antes, pero, vamos a volver atrás un poco y hablar de Task.CPUs. Una cosa que podemos hacer en los procesos es añadir directives o directives en inglés. Por ejemplo, ahora TaskCPUs es por defecto 1. Lo que podemos hacer es especificar una opción, es añadir CPUs como directiva y especificar que queremos usar dos CPUs. Esto va a estar un populando o sobreescribiendo, asignando la variable CPUs y vamos a ejecutar nuestro script. Otra vez, y voy a inspeccionar primero del run anterior, la carpeta que se nos había creado dentro de Work, el fichero comand.sh que es el que contiene, como hemos dicho, este script que hemos ejecutado. En el anterior, como veis TaskCPUs era 1, pero si miramos el actual que lo tenemos aquí, efectivamente, ahora cuánto hemos proporcionado la directives a 2. Ahora Threads es 2 y hemos estado usando 2 Threads. Vamos a pasar a usar ahora el script 3. En este script, lo que estamos haciendo de nuevo, tenemos otra vez lo mismo. Al mismo inicio, lo que estamos haciendo aquí es generar un canal. Si recordáis anteriormente hemos usado un... Esto se llama Channel Factory, o sea, fábrica de canales. Hemos usado una fábrica de canales que era off y terminamos off. En este caso le decimos from file-pers, es decir, desde parejas de ficheros. Estamos creando un canal y lo asignamos y le llamamos read-pers-channel. Entonces le pasamos a este canal. Nuestro parámetro reads que contiene los ficheros que empiezan por acá y luego tienen 1, 1, 1, 1, 2. Lo que vamos a hacer es visualizar qué tenemos en este canal. Resíoma en este caso no está siendo muy útil porque es la primera vez que ejecutamos este script, pero tampoco nos afecta. Vale, entonces aquí tenemos el contenido de este canal, read-pers-ch, y lo que nos ha creado es primero ha utilizado la primera parte del nombre de nuestros ficheros y asignó el valor, que en este caso es el tipo de tejido. Y después tenemos una lista con los dos ficheros el que contiene 1, 1 y el que contiene 2. Esto es una manera de crear canales especiales que es muy útil en datos de secuenciación. Si conocéis los datos de secuenciación suelen estar apareados y siempre tendremos un fichero con 1 y un fichero con un 2. Entonces, from file-pers desde las parejas de ficheros al decirle que use los ficheros que contengan 1, 1 o 1, 2 automáticamente va a coger los ficheros. En este caso empiezan por gut1 y 2 y va a crear este tipo de canal que usa un nombre, digamos, como tarjeta, como identificador la primera parte del fichero y luego tenemos el fichero 1 y 2. Entonces, el siguiente ejercicio sería usar veis que aquí dentro de la carpeta GGA-L tenemos tres diferentes tipos de tejidos intestino, gut, ilgado, labor y pulmón, lung entonces sería sobrescribir igual que ya hemos hecho antes, podemos pasar para amps.reads a través de nuestro comando en la terminal y sobrescribir para usar en lugar de solo gut todos los tres tejidos. Entonces, otra vez podéis pausar este vídeo y probar de hacerlo y si ya ahora deberías haberlo probado vamos a probar aquí de tarjetreads y en este caso lo que queremos que sea reads es data.g. En este caso le estamos dando el path la ruta relativa desde donde estamos ejecutando el comando y vamos a usar para usar todos los ficheros. Usaremos otra vez el asterisco y luego todos los que contengan 1 1. 1 2 y terminen por ese cu. Otra vez deberíamos ver ahora imprimido por pantalla del contenido y como veis se ha creado este canal que cada línea representa un elemento es decir, este canal ahora tiene tres elementos. Primero tenemos cat con se fichero 1 y se fichero 2 luego tenemos labor con se fichero 1 y fichero 2 y finalmente lung con fichero 1 y fichero 2. Otra cosa que podemos hacer es usar set. Set se utiliza para definir un canal para guardar y darle un nombre a un canal. Entonces lo que vamos a hacer funciona exactamente igual que un que esté igual del símbolo de igual, pero es más más fácil de para aler código ya que es propio de de nextflow. Entonces esto lo podemos usar. Set entre los clodadores y el nombre de nuestro canal. Otra cosa que también podemos hacer el nextflow que facilita bastante la lectura es separar los diferentes operadores en diferentes líneas, entonces vamos a ejecutar lo mismo. Criamos el canal y lo guardamos en un canal con este nombre Ritpers Channel. Voy a volver a ejecutar el mismo el mismo proceso y efectivamente pues funciona exactamente igual que antes. Siguiente con el training o coleccionar recoger ficheros por parejas aquí. Exacto. El training nos invita a usar opciones. Nextflow tiene varias opciones también. Es bueno que si queréis reviséis la documentación de Nextflow aquí tenéis un enlace directo para ver las diferentes opciones que existen. Aquí, por ejemplo, nos está diciendo que usemos check if exist. Entonces voy a copiar esta parte del código. Esta es una opción de esta fábrica de canales. Run file press check if exist lo ponemos a true y lo que va a hacer es validar si estos ficheros existen. Sólo como prueba para ver qué funciona voy a decir. En, por ejemplo, un nombre de un fichero que no exista y vemos efectivamente que debería fallar no falls much pattern y decir que ningún fichero está tiene este patrón que hemos definido empezando por pulmón en esta carpeta. Entrante de esto efectivamente ha funcionado. Como digo, podéis revisar la documentación para ver pues las opciones que hay disponibles. Vamos a pasar ahora al script número cuatro. Vale, aquí tenemos también el mismo inicio, nuestro proceso de index y aquí hemos añadido un nuevo proceso que se llama quantification. En este caso tenemos dos inputs. Le pasaríamos dos canales como input. El primero es la carpeta que teníamos de output del proceso anterior. Salmon index y llamamos a la variable también Salmon index. Y el segundo canal de input va a ser un table. Esto es una manera de decir que vamos a usar múltiples valores del mismo canal y los podemos entonces asignar a diferentes variables. En este caso el primero es el valor sample ID que si nos acordamos de cómo teníamos antes el canal. Esto sería nuestra sample ID que efectivamente es un identificador de la muestra que estamos que estaremos analizando. Y el segundo se trata de rutas a ficheros y le llamamos a la variable rich. Y finalmente como output aquí tenemos otra vez un fichero. Y como veis, también podemos usar variables aquí. Es decir que esto está es muy automático por decirlo de una manera. No tenemos que darle nosotros un nombre igual que hemos hecho aquí. Y todos los outputs se van a llamar Salmon index, sino que esto es dinámico y dependiendo de el identificador te muestra que tengamos el fichero del resultado se va a llamar también de esta manera usando la variable. Como script usamos este otro comando de Salmon, del programa Salmon, Salmon Quant. Otra vez asignamos el número de CPUs. Luego le damos Salmon index que hemos dado aquí como input. Usamos en este caso reads. Teníamos una lista con dos ficheros fichero uno fichero dos. Por eso lo podemos usar indexado. La primera parte de nuestra lista va a ser el fichero uno. La segunda parte va a ser el fichero dos. Y finalmente como output le damos el identificador de sample, sample ID. Vale, lo que vamos a hacer ahora es ejecutar. Vamos a cambiar esto por asterisco para no tener que sobrescribirlo cada vez. Y además así tendremos más ficheros. Y ejecutamos el script número cuatro. Vamos a ver entonces qué está pasando en nuestra workflow. Primero hemos ejecutado que es el mismo que antes. Entonces a la resolución pues no hace falta ejecutarlo otra vez. Como veis esto para desarrollo va muy bien. Ya que ahora hemos añadido solo la segunda parte. Entonces la primera parte puede ser re usada. Y quantification está corriendo una vez por cada una de nuestras muestras que teníamos aquí. Le hemos pasado. Entonces teníamos igual que antes. Hemos creado nuestro canal dando los reads de input y llamando los readers. Luego hemos creado, usado nuestro proceso index pasándole nuestro parámetro transcript file que ha creado el canal index channel. Y luego hemos usado quantification pasándolo como hemos dicho. Dos inputs. Primero index channel y luego readverse que sería este de aquí. Y esto es lo que hemos ejecutado. Lo que vamos a hacer ahora es otras cosas que podemos hacer. Como he dicho antes, hay varias directivas. Antes hemos usado CPUs. Otra opción que podemos hacer es usar un TAC para darle una etiqueta a cada una de las tareas de este proceso. Aquí podemos usar Sample ID. Podemos usar otra vez la variable para hacerlo dinámico. Y, por ejemplo, vamos a correr con este mismo parámetro que hemos usado antes. Con Ansible Files. Esto lo usamos y os acordáis con NextPy, con Hello.nf. Y aquí podemos ver los tres procesos que se han ejecutado, las tres tareas de este proceso. Una para cada muestra y efectivamente no se imprime aquí. Nos pone la etiqueta que hemos, que le hemos dado para identificar. Usando Sample ID como identificador. Entonces, en lugar de, o sea, fácilmente podemos ver. Así que si éramos ir a inspeccionar nuestro Work Directory, podemos saber dónde tenemos que acceder para ver cada una de las muestras que habíamos, que habíamos analizado. Luego, otra opción que podemos tener y esto lo vamos a publicar de aquí, porque es en línea más larga es usar PublishDir. Como hemos visto antes, los resultados los tenemos en el Work, en la carpeta Work, pero es complicado, no tener que acceder para ver nuestros resultados dentro de esta carpeta, que realmente es solo para NextLow, para su ejecución. Entonces, lo que podemos hacer es usar esta nueva Directive, PublishDir, es decir, carpeta de publicación. Le damos un nombre, en este caso le vamos a llamar, vamos a usar el parámetro que hemos definido antes a obdir que nos dice el nombre que queremos para la carpeta, para la carpeta de Output, Output. Y también usamos aquí, le estamos especificando un modo copy que lo que va a hacer es copiar los ficheros de Output dentro de esta carpeta, de esta carpeta de Output. Entonces, podemos ejecutar nuestro script y se debería generar la carpeta con el nombre de Results, que es lo que hemos definido aquí, le hemos llamado Results. Efectivamente, la tenemos aquí, y si miramos qué contiene, tiene, aquí le hemos dicho que el Output lo que le hemos en carpetas llamadas SampleID también. Por eso tenemos estas tres carpetas, una para cada maestro con el SampleID, como nombre y todos los ficheros de resultado que ha generado Salmon dentro de estas carpetas. Dicho esto, vamos a pasar otra vez al siguiente script número 5. Lo que vemos aquí es que hemos añadido otro proceso, en este caso el proceso FastGySy. Este ya tiene un tag, también le hemos dado una etiqueta, FastGySy onSampleID, otra vez usamos SampleID, también tiene un input con SampleID y Reads. El Output contiene, ese era llamado también dinámicamente FastGySy para barra baja usando SampleID y Logs, como veis aquí también, pero es importante definir el nombre de la variable dentro del corchete, es porque si no al usar una barra baja detrás se interpretaría como que la variable es todo el nombre, entonces lo definimos así para asegurar que esta variable está dentro de la string ese púrpula correctamente. Y luego tenemos un script que lo que hace es crear una carpeta que es esta misma con el mismo nombre que hemos usado aquí y ejecutamos este programa FastGySy dándole de Output esta misma carpeta que hemos creado y de input Reads, los ficheros que le hemos pasado. Y aquí tenemos la Workflow. Lo que vemos aquí es que este canal, este canal que hemos creado con input se puede rehusar, es decir, es también bastante dinámico y podemos reutilizar los canales en diferentes procesos según necesitemos, en el caso de que nos convenga reutilizarlos. Vamos a ejecutar este script número 5 con nuestro nuevo proceso FastGySy y tenemos, pues, index que se ha ejecutado una vez que provenía de antes a perdón, aquí no hemos cambiado. Solo estamos usando los ficheros de cat. Entonces, vamos a usar otra vez el hasta disco para obtener tres muestras. Vale, pues tenemos los. Primero, corremos index una sola vez, luego corremos Quantification tres veces y finalmente FastGySy tres veces a la vez lo que he ejecutado antes, una vez, vemos que hay una muestra que está en cache y no ha hecho falta ejecutar otra vez. Aquí, como lo habíamos también ejecutado antes de este proceso, también ha sido guardado en cambio los nuestros nuevos muestros para este proceso se han ejecutado ahora. Y aquí tenemos nuestro nuevo proceso. Pasamos al script número 6. Cinco ya no hace falta. Tenemos otra vez lo mismo. Nuestros tres procesos. Y hemos añadido un proceso nuevo. MultiQC. En este caso definimos también una. Una carpeta para guardar todos los ficheros de output. Un input que en este caso es cualquier fichero. Cualquier fichero es de tipo path. Cuál pero con hasta disco cualquier fichero que le pasemos como input será un input. Como output este fichero llamado multiQC report html y ejecutaremos esta herramienta. Este programa llamado multiQC. Y aquí en nuestra workflow otra vez esto es lo mismo que antes. Pero aquí tenemos multiQC y estamos usando dos nuevos operadores. Mix y collect. Aquí otra vez también os invito que vayáis a mirar la documentación de nextflow donde veréis. Podéis ver la documentación de estos operadores. Aquí lo que está haciendo mix es mezclar el contenido de quant barra baja ch de este primer canal con faskey si barra baja ch el segundo canal. Entonces mezclamos estos dos canales y finalmente collect lo que está haciendo es unir el contenido de este canal resultante en un solo elemento. Lo que podemos hacer antes de ejecutar este nuevo proceso es ver. Vamos a comentar esto un momento. Y vamos a usar view para ver el contenido de estos canales. Split no seis. Aquí vemos que perdón otra vez. Vamos a modificar esto porque es más fácil para la explicación usar más muestras. Lo que vemos que ha pasado es que el output de quant channel que era y lo tenemos aquí que eran las carpetas definidas con el nombre de sample ID se ha mezclado con el output de faskey si que era esta carpeta faskey si sample ID locks. Y luego lo vemos todo como veis en un mismo elemento todo seguido. Tendríamos aquí pues faskey si lock esta primera carpeta faskey si lock faskey si labor locks y luego se ha mezclado con las carpetas liver, lung y grout. En el caso de no tener collect vamos a ver qué pasaría si no usamos collect veis aquí nos imprime cada elemento en una línea diferente entonces aquí los tenemos todos juntos en un único elemento en cambio aquí tenemos las seis carpetas por separado. Entonces si ejecutamos esto nuestro nuevo proceso multi que sí pasando cualquier fichero sin collect lo que pasa es que vamos a probarlo. Lo que está sucediendo es que nuestro proceso multi que sí se ha ejecutado seis veces. En cambio teniendo collect está juntando todos los ficheros en un único elemento entonces este elemento hará que multi que sí se ejecute una sola vez. Esta herramienta por si no lo conocéis sirve para analizar la calidad de los ficheros y puede analizar varios ficheros simultáneamente por esto en este caso queremos darle todos los ficheros juntos y efectivamente nuestro multi que sí solo se ha ejecutado una vez. Podemos pasar al script número siete y en este caso tenemos todos nuestros nuestros procesos con lo workflow igual que antes pero lo que hemos añadido es este on complete. Qué es lo que hace esto es que una vez se ha ejecutado la workflow una vez se ha completado nuestro workflow va a ejecutar lo que esté dentro de esta closure de estos cloud. Entonces aquí estamos definiendo que queremos que lo punto info. Es decir que tengamos un mensaje de lo que igual que teníamos aquí que hemos decidido al principio. Un mensaje de lo que tendremos aquí otro mensaje. En el caso de que nuestro workflow sea un suces es decir si hay ejecutado correctamente vamos a querer imprimir por pantalla dan output a por la following folder es decir hablamos la la carpeta con los repos y damos el nombre de la carpeta que estará en nuestro Outdoor y el report se llama multi que si report.html en el caso contrario en el caso de que la workflow haya fallado imprimiremos ups algo ha ido a mal vamos a ver qué pasa si ejecutamos ya que vemos que otra vez más hemos ejecutado otra vez no hay el asterisco en este caso no es tan importante hemos ejecutado todos nuestros clases y al final al terminar una vez ya ha terminado toda la ejecución de nuestro workflow y ha sido buena terminada sin ningún error vemos aquí dan open the following folder y nos da el resultado esto se puede abrir es un fichero HTML es decir se podría abrir con el browser entonces si seguimos con el tutorial si he visto una vez completado tenemos aquí para para definir notificaciones con email es decir que una vez que se haya terminado de ejecutar nuestra workflow nos envíen email esto no es fácil probarlo en dentro de kitpot se puede probar en el caso que estéis ejecutando lo localmente pero podemos ver cómo funciona básicamente pues definimos usando esta palabra clave mail y tenemos todas las opciones que podemos ir ir definiendo para enviar este mail una vez se haya completado nuestra workflow y aquí también podéis acceder y ver más más documentación el siguiente punto es usar scripts customizados scripts personalizados entonces lo que vamos a hacer es usar aquí hemos estado usando siempre programas y existentes pero también como hemos dicho antes podemos usar cualquier tipo de script scripts que ya hemos programado nosotros mismos con cualquier lenguaje entonces vamos a crear un script que se va a llamar fastqc.sh y voy a copiar el contenido que nos sugiere en el tutorial como veis seguramente eso os recordará a nuestro proceso fastqc es exactamente lo que tenemos aquí entonces tenemos este script que se ha generado aquí en la carpeta donde nos encontramos dentro de nf3n lo que vamos a hacer es ejecutar estas líneas para hacer el script ejecutable básicamente lo que estamos haciendo es cambiar los permisos para que sea ejecutable luego hemos creado una carpeta bin que está aquí y hemos movido este script fastqc.sh dentro de nuestra carpeta bin lo que es que lo tenemos aquí esa carpeta bin es una carpeta que nexlo reconoce y detecta en nuestro proyecto automáticamente puede acceder a ella y la monta en cada ejecución entonces todos los scripts que estén dentro de bin estarán siempre disponibles para nuestros procesos entonces como hemos visto lo que estamos haciendo dentro de fastqc.sh es lo mismo que estamos haciendo aquí en la sección de script de nuestro proceso fastqc entonces lo que podemos hacer es en lugar de esto ejecutar nuestro script y aquí tenemos que darle los argumentos que piden en ese caso le damos samplity y reads que hemos definido aquí pasarles dos argumentos samplity y reads si ejecutamos nuestro script ahora multiplicado debería pasar exactamente lo mismo que antes debería ejecutarse pero en este caso en lugar de ejecutar el código que teníamos aquí antes está usando el código de nuestro script fastqc.sh efectivamente como veis ahora fastqc ya no está catch porque hemos tenido un cambio en el código y está ejecutando este código diferente perfecto ahora sí ya la última sección la penúltima sección perdón es tener records tenemos todas estas opciones que le podemos pasar a nextflow de hecho with docker ya no hace falta hemos visto porque lo hemos configurado en nextflow.conf esas diferentes opciones with report with trace, with timeline, and with dag y en este caso with tag le damos el nombre nos crearán todas las métricas todos de ficheros con información sobre cómo ha sido la ejecución de este script ahora voy a cambiar esto sólo para de demostración para tener un poco más unos cuantos más, un poco más de datos para hacerlo más interesante como veis los reports se van se deben ir generando aquí que tenemos trace que se ha generado, luego lo hemos pedido también, esperamos que termine vale perfecto tenemos otros html aquí no es tan fácil de verlo pero se podría abrir se podría abrir en un browser y por ejemplo tag sí que puede ser más interesante bueno con trace veis que tenemos aquí las carpetas de work y información básicamente de información de cómo ha sido la ejecución de nuestros varios procesos y aquí en tag tenemos una representación de nuestra pipeline con los procesos que tenemos cómo se conectan entre ellos por canales nuestros inputs que hemos proporcionado una representación de nuestra pipeline y ahora sí, bueno aquí también podéis ver más información sobre todas estas opciones y ahora sí que vamos ya a la última sección podemos ejecutar workflows o pipelines en lugar de ahora que estamos ejecutando nuestras pipelines que habíamos creado nosotros podemos ejecutar código directamente de github código que está disponible en github entonces lo que vamos a hacer es copiar este comando y en este caso como veis pues esta pipeline nextflow guion io rnc guion nf no la tenemos nosotros no la tenemos aquí en local sino que se está accediendo a este enlace este link de github y está ejecutando la pipeline de rnc entonces podríamos acceder aquí vemos nuestra el código que hemos ahora hemos cogido de github y hemos ejecutado y aquí podéis ver el código entonces también podemos por ejemplo tenemos esta r de revision aquí estamos usando la versión 2.1 si vamos aquí las branches vemos todas las existentes por ejemplo si quisiéramos ejecutar la versión de desarrollo pues podríamos usar guion rdep y no serviría para ejecutar otra versión de esta misma pipeline ahora sí que hemos ya llegado al final de esta sesión al final de esta sesión 1 mañana con la siguiente sesión con la sesión 2 lo que vamos a hacer es no vamos a usar este mismo tutorial sino que lo que vamos a hacer es hablar más profundamente de nfcore pues vamos a ver qué es nfcore y cómo podéis beneficiaros de esta comunidad así pues hasta la sesión 2