View a markdown version of this page

Especificaciones de la definición del flujo de trabajo de Next - AWS HealthOmics

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Especificaciones de la definición del flujo de trabajo de Next

HealthOmics es compatible con Nextflow DSL1 y DSL2. Para obtener más información, consulte Compatibilidad con la versión de Nextflow.

Nextflow DSL2 se basa en el lenguaje de programación Groovy, por lo que los parámetros son dinámicos y la coacción de tipos es posible utilizando las mismas reglas que Groovy. Los parámetros y valores proporcionados por el JSON de entrada están disponibles en el mapa parameters () del flujo de trabajo. params

Usa los complementos nf-schema y nf-validation

nota

Resumen de la compatibilidad con los HealthOmics complementos:

  • v22.04: no hay soporte para complementos

  • v23.10 — admite y nf-schema nf-validation

  • v24.10 — admite nf-schema

  • v25.10, v26.04: admite, y nf-schema nf-core-utils nf-fgbio nf-prov

HealthOmics proporciona el siguiente soporte para los complementos de Nextflow:

  • Para la versión 23.10 de Nextflow, HealthOmics preinstala el complemento nf-validation @1 .1.1.

  • Para las versiones 23.10 y 24.10 de Nextflow, preinstala el complemento nf-schema @2 .3.0. HealthOmics

  • Para Nextflow v25.10, HealthOmics preinstala los complementos nf-schema @2 .6.1, nf-core-utils @0 .4.0, nf-prov @1 .7.0 y nf-fgbio @1 .0.1.

  • Para Nextflow v26.04, preinstala los complementos nf-schema @2 .7.2, nf-core-utils @0 .4.0, nf-prov @1 .7.0 y nf-fgbio @1 .0.1. HealthOmics

  • No puedes recuperar complementos adicionales durante la ejecución de un flujo de trabajo. HealthOmics ignora cualquier otra versión del complemento que especifiques en el nextflow.config archivo.

  • Para Nextflow v24 y versiones posteriores, nf-schema es la nueva versión del complemento obsoleto. nf-validation Para obtener más información, consulta nf-schema en el repositorio de Nextflow. GitHub

Especifique los URI de almacenamiento

Cuando se utiliza un HealthOmics URI o un archivo de Amazon S3 para crear un archivo o un objeto de ruta de Nextflow, el objeto coincidente está disponible para el flujo de trabajo, siempre que se conceda el acceso de lectura. Se permite el uso de prefijos o directorios para los URI de Amazon S3. Para ver ejemplos, consulte Formatos de parámetros de entrada de Amazon S3.

HealthOmics admite parcialmente el uso de patrones globales en los URI o URI de almacenamiento de Amazon S3. HealthOmics Utilice los patrones globales en la definición del flujo de trabajo para la creación de nuestros canales. path file Para conocer el comportamiento esperado y los casos exactos, consulteManejo de Nextflow del patrón Glob en las entradas de Amazon S3.

Directivas de Nextflow

Las directivas de Nextflow se configuran en el archivo de configuración de Nextflow o en la definición del flujo de trabajo. La siguiente lista muestra el orden de prioridad que se HealthOmics utiliza para aplicar los ajustes de configuración, desde la prioridad más baja a la más alta:

  1. Configuración global en el archivo de configuración.

  2. Sección de tareas de la definición del flujo de trabajo.

  3. Task-specific selectores en el archivo de configuración.

Estrategia de reintento de tareas mediante ErrorStrategy

Usa la errorStrategy directiva para definir la estrategia en caso de errores en las tareas. De forma predeterminada, cuando se devuelve una tarea con una indicación de error (un estado de salida distinto de cero), la tarea se detiene y HealthOmics finaliza toda la ejecución. Si se establece enretry, errorStrategy HealthOmics intenta volver a intentar la tarea fallida. Para aumentar el número de reintentos, consulte. Reintentos de tareas mediante MaxRetries

process { label 'my_label' errorStrategy 'retry' script: """ your-command-here """ }

Para obtener información sobre cómo se HealthOmics gestionan los reintentos de tareas durante una ejecución, consulte. La tarea se reintenta

Reintentos de tareas mediante MaxRetries

De forma predeterminada, HealthOmics no intenta reintentar una tarea fallida ni intenta reintentarlo si la configuras. errorStrategy Para aumentar el número máximo de reintentos, errorStrategy defina retry y configure el número máximo de reintentos mediante la directiva. maxRetries

El siguiente ejemplo establece el número máximo de reintentos en 3 en la configuración global.

process { errorStrategy = 'retry' maxRetries = 3 }

El siguiente ejemplo muestra cómo configurarlo maxRetries en la sección de tareas de la definición del flujo de trabajo.

process myTask { label 'my_label' errorStrategy 'retry' maxRetries 3 script: """ your-command-here """ }

El siguiente ejemplo muestra cómo especificar la configuración específica de una tarea en el archivo de configuración de Nextflow, en función de los selectores de nombre o etiqueta.

process { withLabel: 'my_label' { errorStrategy = 'retry' maxRetries = 3 } withName: 'myTask' { errorStrategy = 'retry' maxRetries = 3 } }

Opte por no participar en el reintento de la tarea con omics 5xx RetryOn

Para Nextflow v23 y versiones posteriores, HealthOmics admite los reintentos de tareas si la tarea falló debido a errores de servicio (códigos de estado HTTP 5XX). De forma predeterminada, HealthOmics intenta reintentar hasta dos veces una tarea fallida.

Puede configurarlo omicsRetryOn5xx para que excluya el reintento de una tarea en caso de errores de servicio. Para obtener más información sobre el reintento de tareas HealthOmics, consulte. La tarea se reintenta

El siguiente ejemplo configura omicsRetryOn5xx en la configuración global la opción de inhabilitar el reintento de tareas.

process { omicsRetryOn5xx = false }

El siguiente ejemplo muestra cómo realizar la configuración omicsRetryOn5xx en la sección de tareas de la definición del flujo de trabajo.

process myTask { label 'my_label' omicsRetryOn5xx = false script: """ your-command-here """ }

El siguiente ejemplo muestra cómo establecer omicsRetryOn5xx una configuración específica para una tarea en el archivo de configuración de Nextflow, en función de los selectores de nombre o etiqueta.

process { withLabel: 'my_label' { omicsRetryOn5xx = false } withName: 'myTask' { omicsRetryOn5xx = false } }

Duración de la tarea mediante la directiva de tiempo

HealthOmics proporciona una cuota ajustable (consulteHealthOmics cuotas de servicio) para especificar la duración máxima de una ejecución. Para los flujos de trabajo de Nextflow v23 y versiones posteriores, también puede especificar la duración máxima de las tareas mediante la directiva Nextflow. time

Durante el desarrollo de nuevos flujos de trabajo, establecer la duración máxima de las tareas te ayuda a detectar las tareas que se están agotando y las que llevan mucho tiempo ejecutándose.

Para obtener más información sobre la directiva de tiempo de Nextflow, consulte la directiva de tiempo en la referencia de Nextflow.

HealthOmics proporciona el siguiente soporte para la directiva horaria de Nextflow:

  1. HealthOmics admite una granularidad de 1 minuto para la directiva de tiempo. Puede especificar un valor entre 60 segundos y el valor máximo de duración de la ejecución.

  2. Si introduce un valor inferior a 60, lo HealthOmics redondea a 60 segundos. Para valores superiores a 60, HealthOmics redondea hacia abajo al minuto más cercano.

  3. Si el flujo de trabajo admite reintentos para una tarea, HealthOmics vuelva a intentarlo si se agota el tiempo de espera.

  4. Si se agota el tiempo de espera de una tarea (o se agota el último intento), HealthOmics cancela la tarea. Esta operación puede durar de uno a dos minutos.

  5. Cuando se agota el tiempo de espera de la tarea, HealthOmics establece el estado de ejecución y de la tarea en error y cancela las demás tareas en ejecución (para las tareas en estado de inicio, pendientes o en ejecución). HealthOmics exporta los resultados de las tareas que completó antes de que se agotara el tiempo de espera a la ubicación de salida de S3 que haya designado.

  6. El tiempo que una tarea permanece en estado pendiente no se tiene en cuenta para la duración de la tarea.

  7. Si la ejecución forma parte de un grupo de ejecución y el grupo de ejecución agota su tiempo de espera antes que el temporizador de la tarea, la ejecución y la tarea pasan al estado de error.

Especifique la duración del tiempo de espera con una o más de las siguientes unidades:ms,s, mh, od.

El siguiente ejemplo muestra cómo especificar la configuración global en el archivo de configuración de Nextflow. Establece un tiempo de espera global de 1 hora y 30 minutos.

process { time = '1h30m' }

El siguiente ejemplo muestra cómo especificar una directiva de tiempo en la sección de tareas de la definición del flujo de trabajo. En este ejemplo se establece un tiempo de espera de 3 días, 5 horas y 4 minutos. Este valor tiene prioridad sobre el valor global del archivo de configuración, pero no tiene prioridad sobre una directiva de tiempo específica para my_label una tarea en el archivo de configuración.

process myTask { label 'my_label' time '3d5h4m' script: """ your-command-here """ }

El siguiente ejemplo muestra cómo especificar las directivas de tiempo específicas de una tarea en el archivo de configuración de Nextflow, en función de los selectores de nombre o etiqueta. En este ejemplo, se establece un valor de tiempo de espera global para una tarea de 30 minutos. Establece un valor de 2 horas para la tarea myTask y un valor de 3 horas para las tareas con etiquetamy_label. En el caso de las tareas que coinciden con el selector, estos valores tienen prioridad sobre el valor global y el valor de la definición del flujo de trabajo.

process { time = '30m' withLabel: 'my_label' { time = '3h' } withName: 'myTask' { time = '2h' } }

Usa los perfiles de Nextflow

Los perfiles de Nextflow se denominan conjuntos de ajustes de configuración que puede seleccionar en tiempo de ejecución. Defina los perfiles en el profiles bloque de su nextflow.config archivo:

profiles { standard { process.cpus = 2 process.memory = '4 GB' } production { process.cpus = 16 process.memory = '64 GB' params.input = 's3://bucket/production-data.bam' } }

Al iniciar una ejecución, especifique uno o más perfiles mediante el engineSettings parámetro. HealthOmics pasa la -profile bandera al motor de Nextflow. Para obtener más información, consulte Especifique la configuración del motor Nextflow.

aws omics start-run \ --workflow-id workflow-id \ --role-arn role-arn \ --output-uri s3://bucket/prefix/ \ --engine-settings '{"profile": "production"}'

Cuando se especifican varios perfiles (por ejemplo,"test,docker"), Nextflow los aplica en el orden en que se especifican en la línea de comandos. Los perfiles posteriores anulan los anteriores en caso de configuraciones conflictivas. Para las versiones de Nextflow inferiores a 26, los perfiles se aplican en el orden en que están definidos en el archivo de configuración y no en el orden de la línea de comandos.

Tenga en cuenta lo siguiente:

  • La compatibilidad con los perfiles está disponible para todas las versiones HealthOmics compatibles de Nextflow.

  • Los perfiles pueden contener parámetros, directivas de proceso, includeConfig sentencias y anulaciones de manifiestos (incluidasmanifest.nextflowVersion).

  • Los parámetros de ejecución explícitos tienen prioridad sobre los valores de los parámetros definidos por el perfil.

  • Si especifica un perfil inexistente, HealthOmics devuelve un error de validación.

  • Los perfiles se deben definir en el archivo zip de definición del flujo de trabajo. HealthOmics no permite obtener definiciones de perfil de fuentes externas.

  • Si no especificas un perfil, la ejecución usa el standard perfil si está definido en los perfiles de la definición del flujo de trabajo. De lo contrario, la ejecución usa la configuración predeterminada (de nivel superior).

  • Al usar perfiles, recomendamos fijar la versión de Nextflow en la definición de su flujo de trabajo manifest.nextflowVersion para garantizar un comportamiento uniforme de las aplicaciones de perfiles en todas las ejecuciones.

Exporte contenido a nivel de flujo de trabajo

Para Nextflow v25.10 y versiones posteriores, puede exportar archivos producidos fuera de tareas individuales, como los informes de procedencia o los DAG de tramitación. Para exportar estos archivos, escríbalos en. /mnt/workflow/output/ HealthOmics exporta los archivos ubicados en este directorio al output/ prefijo de la ubicación de salida de Amazon S3 de su ejecución.

El siguiente ejemplo muestra cómo configurar el nf-prov complemento para escribir un informe de procedencia en él. /mnt/workflow/output/

prov { formats { bco { file = "/mnt/workflow/output/pipeline_info/manifest.bco.json" } } }

También puedes pasar esta ruta como parámetro en el JSON de entrada de tu ejecución. Este enfoque es común en los flujos de trabajo de nf-core que utilizan. params.outdir

{ "outdir": "/mnt/workflow/output/" }

Exporta el contenido de las tareas

Para los flujos de trabajo escritos en Nextflow, defina una directiva PublishDir para exportar el contenido de las tareas a su bucket de Amazon S3 de salida. Como se muestra en el siguiente ejemplo, defina el valor de PublishDir en. /mnt/workflow/pubdir Para exportar archivos a Amazon S3, los archivos deben estar en este directorio.

nextflow.enable.dsl=2 workflow { CramToBamTask(params.ref_fasta, params.ref_fasta_index, params.ref_dict, params.input_cram, params.sample_name) ValidateSamFile(CramToBamTask.out.outputBam) } process CramToBamTask { container "<account>.dkr.ecr.us-west-2.amazonaws.com/genomes-in-the-cloud" publishDir "/mnt/workflow/pubdir" input: path ref_fasta path ref_fasta_index path ref_dict path input_cram val sample_name output: path "${sample_name}.bam", emit: outputBam path "${sample_name}.bai", emit: outputBai script: """ set -eo pipefail samtools view -h -T $ref_fasta $input_cram | samtools view -b -o ${sample_name}.bam - samtools index -b ${sample_name}.bam mv ${sample_name}.bam.bai ${sample_name}.bai """ } process ValidateSamFile { container "<account>.dkr.ecr.us-west-2.amazonaws.com/genomes-in-the-cloud" publishDir "/mnt/workflow/pubdir" input: file input_bam output: path "validation_report" script: """ java -Xmx3G -jar /usr/gitc/picard.jar \ ValidateSamFile \ INPUT=${input_bam} \ OUTPUT=validation_report \ MODE=SUMMARY \ IS_BISULFITE_SEQUENCED=false """ }

Para Nextflow v25.10 y versiones posteriores, como alternativapublishDir, puede usar las salidas del flujo de trabajo para exportar el contenido de las tareas. El siguiente ejemplo muestra cómo definir un output bloque de flujo de trabajo que exporta los resultados de las tareas a Amazon S3.

process myTask { input: val data output: path 'result.txt' script: """ echo ${data} > result.txt """ } workflow { main: output_file = myTask('hello') publish: results = output_file } output { results { path '.' } }

Para obtener más información sobre los resultados del flujo de trabajo, consulte los resultados del flujo de trabajo en la documentación de Nextflow.

Genere informes de ejecución de Nextflow

Nextflow puede producir cuatro informes integrados para cada ejecución: un informe de ejecución (report), un cronograma (timeline), un archivo de seguimiento (trace) y un diagrama de flujo de trabajo (dag). HealthOmics Para exportar estos archivos a la ubicación de salida de Amazon S3 de tu ejecución, configura cada uno de ellos para que escriba el resultado /mnt/workflow/output/ en tu nextflow.config archivo:

report { enabled = true file = '/mnt/workflow/output/report.html' overwrite = true } timeline { enabled = true file = '/mnt/workflow/output/timeline.html' overwrite = true } trace { enabled = true file = '/mnt/workflow/output/trace.txt' overwrite = true } dag { enabled = true file = '/mnt/workflow/output/dag.html' overwrite = true }

HealthOmics exporta los archivos escritos con /mnt/workflow/output/ el output/ prefijo de la ubicación de salida de Amazon S3 de su ejecución. Para obtener más información sobre esta ruta de exportación, consulteExporte contenido a nivel de flujo de trabajo. Los informes escritos en el exterior no /mnt/workflow/output/ se exportan a la ubicación de salida de Amazon S3 de su ejecución.

Los contenedores de tareas deben incluir ps

Cuando el trace informe o está habilitado reporttimeline, Nextflow recopila las métricas por tarea invocándolas ps dentro de cada contenedor de tareas. La imagen del contenedor que especifiques con la container directiva debe incluir el comando. ps En la mayoría de las distribuciones de Linux, instálelo con el Debian/Ubuntu paquete procps procps-ng () o (Amazon Linux, Red Hat, Fedora). Si un proceso no declara una container directiva, HealthOmics ejecuta la tarea en un contenedor predeterminado que ya la incluya. ps

Formato de diagrama de flujo de trabajo

El dag informe admite varios formatos de salida, seleccionados por la extensión dedag.file. Los formatos HTML, Mermaid y DOT son renderizados directamente por Nextflow y no requieren herramientas adicionales. Los formatos PDF, PNG y SVG requieren Graphviz, que no está incluido en el motor Nextflow del sistema. HealthOmics Si dag.file se establece en una ruta PDF, PNG o SVG, Nextflow registra una advertencia y escribe el diagrama de flujo de trabajo como archivo .dot fuente en su lugar; la ejecución aún se completa correctamente. Recomendamos establecer una .html .dot ruta o dag.file para evitar la advertencia y generar el formato solicitado. .mmd

Especifique la versión de sintaxis de Nextflow

La versión 26.04.0 de Nextflow usa el analizador de sintaxis estricto (v2) de forma predeterminada. Este es un cambio radical para los flujos de trabajo escritos con la sintaxis antigua (v1), que es la predeterminada en la versión 25.10.0 de Nextflow y versiones anteriores. Para obtener información sobre la sintaxis de la versión 2, consulte Sintaxis estricta en la documentación de Seqera Nextflow.

Para ejecutar un flujo de trabajo creado con el analizador antiguo (v1), engineSettings.syntaxVersion configúralo en la solicitud: v1 StartRun

{ "engineSettings": { "syntaxVersion": "v1" } }

Para la versión 25.10.0 de Nextflow y versiones anteriores, HealthOmics no es compatible con el analizador de la versión 2.

Validación automática de la sintaxis durante la creación del flujo de trabajo

HealthOmics ejecuta automáticamente el estricto DSL2 linter (nf-lang/v2) integrado en Nextflow al crear o actualizar un flujo de trabajo DSL2 de Nextflow. CreateWorkflowEste CreateWorkflowVersion linter funciona durante y. Se aplica a todas las versiones de DSL2 compatibles (v22.04, v23.10, v24.10, v25.10 y v26.04). Los flujos de trabajo de la DSL1 no están limitados.

El linter funciona en modo sin bloqueo. Los hallazgos de Lint no impiden que el flujo de trabajo se active. Los resultados aparecen como JSON estructurado en el statusMessage campo de la GetWorkflow respuesta.

nota

El linter integrado valida la sintaxis de definición del flujo de trabajo en el momento de la creación. Es diferente del analizador sintáctico estricto disponible para la versión 26.04 de Nextflow, que está controlado por el comportamiento en tiempo de ejecución y lo afecta. engineSettings.syntaxVersion El linter comprueba la sintaxis de todas las versiones de DSL2 en el momento de la creación, independientemente del analizador que utilice el flujo de trabajo en tiempo de ejecución. En las versiones 22.04, 23.10 y 24.10 de Nextflow (gramática antigua), los resultados son recomendables. En las versiones 25.10 y 26.04 de Nextflow, los resultados reflejan los estrictos requisitos de sintaxis del modo.

Para obtener más información sobre el formato de salida lint y sobre cómo abordar los hallazgos, consulte. El flujo de trabajo apunta a HealthOmics

Cómo usar el almacenamiento desde cero de manera eficiente en Nextflow

La scratch directiva de Nextflow controla dónde escribe un proceso sus archivos de trabajo temporales. Cuando el almacenamiento efímero esté activado (scratchStorageMode: LOCAL), utilice la scratch directiva para dirigir desde cero I/O al rápido volumen local en el que se encuentra. /tmp

En la siguiente tabla se describen los valores de scratch directiva admitidos y su comportamiento en: HealthOmics

Valor Comportamiento en HealthOmics Recomendación
scratch true Usa $TMPDIR. Scratch I/O se dirige al volumen efímero local cuando scratchStorageMode está. LOCAL Recomendado
scratch '/some/path' Usa la ruta literal especificada como directorio virtual. Para usar el almacenamiento efímero, defina la ruta en /tmp o un subdirectorio de. /tmp La ruta debe existir en el contenedor y poder escribirse. Funciona cuando la ruta está por debajo /tmp
scratch 'ram-disk' Intentos de uso /dev/shm (tmpfs en la RAM). Esto no se recomienda para el almacenamiento virtual local en. HealthOmics No recomendado

El enfoque recomendado es establecer scratch true en la definición del proceso, que utiliza automáticamente $TMPDIR y no requiere ninguna configuración de rutas:

process my_process { scratch true disk '200 GB' script: """ my-tool --input ${input} --output ${output} """ }

Para obtener más información sobre el almacenamiento efímero y la disk directiva, consulte. Almacenamiento efímero para HealthOmics tareas de flujo de trabajo

Notas de la versión 26.04 de Nextflow

En las tablas siguientes se resume la HealthOmics compatibilidad con las nuevas funciones, mejoras y obsolescencias publicadas en la versión 26.04 de Nextflow.

Nuevas características y mejoras

Característica Desde la versión HealthOmics soporte Notas
Analizador sintáctico estricto (predeterminado) 26.04 Habilitado de forma predeterminada desde la versión 26.04. El analizador antiguo está disponible syntaxVersion: "v1" en la configuración del motor.
Tipos de registro 26.04 Para obtener más información, consulte Registros en la documentación de Seqera Nextflow.
Resúmenes de los resultados del flujo de trabajo 26.04 Imprime un resumen de los resultados del flujo de trabajo al finalizar la ejecución. El formato de salida se puede configurar mediante outputFormat los ajustes del motor. Para obtener más información, consulte Especifique la configuración del motor Nextflow.
Modo de registro de agentes 26.04 Configurable mediante los ajustes agentMode del motor. Para obtener más información, consulte Especifique la configuración del motor Nextflow.
Sistema de módulos (Nextflow Registry) 26.04 No HealthOmics los flujos de trabajo se ejecutan en una red aislada sin acceso saliente a Internet. Puedes incluir los módulos directamente en el zip de tu flujo de trabajo.
Escritura estática (vista previa) 26.04 No HealthOmics no admite funciones de vista previa.
Auto-load parámetros de recopilación de archivos 26.04 No Requiere escritura estática (vista previa), lo cual HealthOmics no es compatible.
Multi-revision pago de oleoductos 26.04 N/A No se aplica. HealthOmics no utiliza Git-based Pipeline Checkout.

Obsolescencias

Artículo obsoleto Desde la versión Impact Acción recomendada
Método de listFiles() 26.04 Advertencia de obsolescencia Sustituir por. listDirectory()
Indicador nextflow.enable.strict 26.04 Ya no es necesario Eliminar de la configuración. El modo estricto es ahora el predeterminado.
manifest.defaultBranch 26.04 Ya no es necesario Eliminar de la configuración. HealthOmics no usa Git-based Pipeline Checkout y nunca ha admitido esta opción.