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 CWL

Los flujos de trabajo escritos en Common Workflow Language, o CWL, ofrecen una funcionalidad similar a los flujos de trabajo escritos en WDL y Nextflow. Puede utilizar Amazon S3 o el HealthOmics almacenamiento URIs como parámetros de entrada.

Si define la entrada en un archivo secundario de un subflujo de trabajo, añada la misma definición en el flujo de trabajo principal.

HealthOmics los flujos de trabajo no admiten los procesos de operación. Para obtener más información sobre los procesos operativos en los flujos de trabajo de CWL, consulte la documentación de CWL.

La mejor práctica es definir un flujo de trabajo de CWL independiente para cada contenedor que utilice. Le recomendamos que no codifique la entrada de DockerPull con una URI de Amazon ECR fija.

Convierta los flujos de trabajo de CWL para usarlos HealthOmics

Para convertir una definición de flujo de trabajo de CWL existente y utilizarla HealthOmics, realice los siguientes cambios:

Opte por no participar en la tarea, vuelva a intentarlo usando omicsRetryOn5xx

HealthOmics admite reintentos de tareas si la tarea ha fallado debido a errores de servicio (5XX códigos de estado HTTP). De forma predeterminada, HealthOmics intenta reintentar hasta dos veces una tarea fallida. Para obtener más información sobre cómo volver a intentar una tarea HealthOmics, consulte. La tarea se reintenta

Para excluirse del reintento de tareas por errores de servicio, configure la omicsRetryOn5xx directiva en la definición del flujo de trabajo. Puede definir esta directiva en los requisitos o en las sugerencias. Recomendamos añadir la directiva como sugerencia de portabilidad.

requirements:
  ResourceRequirement:
    omicsRetryOn5xx: false

hints:
  ResourceRequirement:
    omicsRetryOn5xx: false     

Los requisitos anulan las sugerencias. Si la implementación de una tarea proporciona un requisito de recursos en sugerencias que también se proporcionan en los requisitos de un flujo de trabajo adjunto, los requisitos adjuntos tienen prioridad.

Si el mismo requisito de tarea aparece en distintos niveles del flujo de trabajo, HealthOmics utiliza la entrada más específica de requirements (ohints, si no hay ninguna entrada). requirements La siguiente lista muestra el orden de prioridad que se HealthOmics utiliza para aplicar los valores de configuración, de menor a mayor prioridad:

El siguiente ejemplo muestra cómo configurar la omicsRetryOn5xx directiva en los diferentes niveles del flujo de trabajo. En este ejemplo, el requisito de nivel de flujo de trabajo anula las sugerencias de nivel de flujo de trabajo. Las configuraciones de requisitos en los niveles de tarea y paso anulan las configuraciones de las sugerencias.

class: Workflow
# Workflow-level requirement and hint
requirements:
  ResourceRequirement:
    omicsRetryOn5xx: false

hints:
  ResourceRequirement:
    omicsRetryOn5xx: false  # The value in requirements overrides this value 

steps:
  task_step:
    # Step-level requirement
    requirements:
      ResourceRequirement:
        omicsRetryOn5xx: false
    # Step-level hint
    hints:
      ResourceRequirement:
        omicsRetryOn5xx: false
    run:
      class: CommandLineTool
      # Task-level requirement
      requirements:
        ResourceRequirement:
          omicsRetryOn5xx: false
      # Task-level hint
      hints:
        ResourceRequirement:
          omicsRetryOn5xx: false      
    

Ejemplos

El siguiente es un ejemplo de un flujo de trabajo escrito en CWL.

cwlVersion: v1.2
class: Workflow

inputs:
in_file:
type: File
secondaryFiles: [.fai]

out_filename: string
docker_image: string


outputs:
copied_file:
type: File
outputSource: copy_step/copied_file

steps:
copy_step:
in:
  in_file: in_file
  out_filename: out_filename
  docker_image: docker_image
out: [copied_file]
run: copy.cwl            
    

El siguiente archivo define la copy.cwl tarea.

cwlVersion: v1.2
class: CommandLineTool
baseCommand: cp

inputs:
in_file:
type: File
secondaryFiles: [.fai]
inputBinding:
  position: 1

out_filename:
type: string
inputBinding:
  position: 2
docker_image:
type: string

outputs:
copied_file:
type: File
outputBinding:
    glob: $(inputs.out_filename)

requirements:
InlineJavascriptRequirement: {}
DockerRequirement:
dockerPull: "$(inputs.docker_image)"      

El siguiente es un ejemplo de un flujo de trabajo escrito en CWL con un requisito de GPU.

cwlVersion: v1.2
class: CommandLineTool
baseCommand: ["/bin/bash", "docm_haplotypeCaller.sh"]
$namespaces:
cwltool: http://commonwl.org/cwltool#
requirements:
cwltool:CUDARequirement:
cudaDeviceCountMin: 1
cudaComputeCapability: "nvidia-tesla-t4" 
cudaVersionMin: "1.0"
InlineJavascriptRequirement: {}
InitialWorkDirRequirement:
listing:
- entryname: 'docm_haplotypeCaller.sh'
  entry: |
          nvidia-smi --query-gpu=gpu_name,gpu_bus_id,vbios_version --format=csv   

inputs: []
outputs: []