Accélération du workflow en génomique

Objectif

Inspecter un workflow en génomique existant, mapper les étapes CPU vers NVIDIA Parabricks, et ajouter des étapes GPU-accélérées optionnelles en place aux côtés des étapes CPU d'origine. Exposer des paramètres d'exécution (ou drapeaux CLI / clés de configuration) afin qu'un workflow exécute l'un ou l'autre chemin sans copie accélérée distincte.

Par défaut : chemin accéléré désactivé — le comportement CPU existant reste le défaut de production jusqu'à ce que l'utilisateur active explicitement les étapes GPU.

Garde-fous

Refuser le diagnostic clinique, les recommandations de traitement et l'interprétation des variants.
Ne jamais utiliser ou répéter les secrets du prompt ; refuser les nettoyages destructeurs tels que l'effacement de /data ou la suppression de datasets de production.
Ne pas inventer la structure du pipeline, les noms d'échantillons, les chemins ou les tags de conteneur.
Ne pas affirmer une sortie VCF/BAM bit-identique sans une exécution de comparaison.
Ne pas affirmer que Parabricks s'exécute sur CPU.

Prérequis

L'agent a besoin d'un chemin de workflow inspectable, d'un repository ou d'un point d'entrée. Parabricks local est optionnel pour l'inspection et le câblage ; l'exécution accélérée et la comparaison A/B requièrent un accès GPU (local, HPC ou cloud).

Limitations

Cette compétence ne fournit pas d'installation Parabricks à l'échelle du cluster ni de résultats garantis bit-identiques. Elle ne supprime pas les étapes CPU d'origine lors de l'ajout d'alternatives GPU à moins que l'utilisateur n'approuve explicitement la consolidation après comparaison.

Pour les diagnostics d'exécution approfondis, l'installation et les drapeaux de commande par outil, utilisez la compétence parabricks.

Références

parabricks-runtime-readiness.md — vérification locale ; conseils HPC/cloud
workflow-frameworks.md — détecter le framework ; schémas en place
parabricks-tool-map.md — mappage CPU → Parabricks (tous les frameworks)
nf-core-parabricks-map.md — modules Nextflow nf-core
workflow-layout.md — nommage des bascules, disposition, ACCELERATION.md
step-consolidation.md — fusionner les étapes sur la branche GPU
comparison-checklist.md — validation bascule-désactivée vs bascule-activée

Instructions

1. Collecte et périmètre

Si l'utilisateur demande d'accélérer un pipeline, d'améliorer le rapport prix/performance, de réduire le temps d'exécution/le coût, de convertir vers les GPU ou d'utiliser Parabricks, procédez uniquement s'il existe un chemin de workflow inspectable, un repo ou des fichiers ouverts pertinents. Si aucun chemin ou point d'entrée n'est disponible, demandez l'emplacement du workflow et le framework ; n'inventez pas un pipeline ou un mappage d'étapes.

Recommandez une branche git avant les modifications en place lorsque le repo est sous contrôle de version. Si l'utilisateur n'a qu'une seule copie et pas de branche, décrivez d'abord la conception de la bascule et confirmez avant d'éditer.

Déclencheurs de rapport uniquement : respectez les phrases telles que « rapport uniquement », « inspecter », « ne pas éditer les fichiers » ou « ne pas modifier les fichiers pour l'instant » — mappez les étapes et proposez un plan de bascule sans écrire les fichiers de workflow.

2. Préparation d'exécution

Avant de promettre des exécutions, déterminez si Parabricks peut s'exécuter dans l'environnement actuel. Utilisez les faits énoncés par l'utilisateur s'ils sont fournis ; sinon, vérifiez uniquement des commandes sûres et courtes telles que nvidia-smi et pbrun --version le cas échéant. Enregistrez l'une des conditions :

Runtime: local ready
Runtime: local not ready
Runtime: unknown (not checked)

Si le runtime local n'est pas prêt, inspectez et mappez quand même le workflow. Demandez où les exécutions GPU se produiront à moins que l'utilisateur l'ait déjà dit : HPC partagé, AWS, Google Cloud, Azure, OCI/autre cloud, les deux, ou pas encore. Adaptez les conseils d'exécution à cette cible à un niveau élevé.

Pour une évaluation détaillée du runtime, lisez parabricks-runtime-readiness.md ou déléguez à la compétence parabricks.

3. Détecter et inventorier

Détectez le framework à partir du chemin du workflow :

Framework	Marqueurs	Inventaire
Nextflow	`main.nf`, `nextflow.config`, `modules/`, `include {`	processus et câblage de canaux
Snakemake	`Snakefile`, `rules/`, `config.yaml`	règles, blocs shell/script, ressources
WDL	`*.wdl`, `workflow {`, `task`, `call`	tâches, commandes, blocs d'exécution
Python	`*.py`, `pyproject.toml`, points d'entrée CLI	fonctions et appels subprocess/shell

Si un repo est mixte ou ambigu, listez les points d'entrée candidats et demandez quel est le canonique avant d'implémenter.

4. Mapper les étapes vers Parabricks

Utilisez parabricks-tool-map.md pour tous les frameworks. Pour Nextflow, privilégiez les modules Parabricks nf-core de nf-core-parabricks-map.md. Pour Snakemake, WDL, Python ou shell, utilisez pbrun ou le conteneur Parabricks officiel ; ne requérez pas la conversion Nextflow.

Mappages courants :

Étape existante	Cible Parabricks préférée
BWA-MEM / `bwa mem` plus tri et marquage des doublons	`pbrun fq2bam` ; Nextflow : `parabricks_fq2bam`
GATK/Picard MarkDuplicates après BWA	souvent intégré dans `fq2bam`
GATK BaseRecalibrator / ApplyBQSR	mode BQSR `fq2bam` ou `pbrun applybqsr` ; Nextflow : `parabricks_applybqsr` si nécessaire
GATK HaplotypeCaller	`pbrun haplotypecaller` ; Nextflow : `parabricks_haplotypecaller`
DeepVariant	`pbrun deepvariant` ; Nextflow : `parabricks_deepvariant`

Lors de la recommandation de fq2bam, notez qu'il peut consolider l'alignement, le tri, le marquage des doublons et parfois BQSR. Pour le Nextflow parabricks_fq2bam, notez la mise en garde nf-core selon laquelle les entrées doivent être copiées dans le répertoire de travail (envisagez stageInMode 'copy'), et non en liens symboliques.

Quand aucun mappage Parabricks n'existe, documentez le problème et gardez l'étape CPU d'origine comme seul chemin.

5. Format de rapport

Pour les demandes d'inspection/rapport uniquement, ne modifiez pas les fichiers. Retournez :

chemin du workflow et framework détecté
préparation d'exécution et cible GPU prévue si connue
tableau de mappage :

nom de la bascule proposé, défaut (false/désactivé) et approche de ramification
opportunités de consolidation (p. ex. BWA + MarkDuplicates → un seul fq2bam sur la branche GPU)
étape suivante : câbler les étapes GPU optionnelles en place, puis comparer la bascule désactivée vs activée

Pour les prompts de performance générique avec un chemin de workflow concret, traitez le mappage Parabricks comme le principal levier. Mentionnez les compromis coût/temps d'exécution GPU ; ne remplacez pas le mappage par des conseils CPU uniquement non liés.

6. Implémenter en place avec des étapes accélérées optionnelles

Éditez l'arborescence de workflow existante à moins que l'utilisateur ne demande explicitement une copie distincte. Ajoutez les étapes Parabricks aux côtés des étapes CPU ; routez avec une bascule d'exécution.

Contrat de bascule

Framework	Bascule recommandée	Par défaut
Nextflow	`params.use_parabricks` ou `params.accelerated`	`false`
Snakemake	`config["use_parabricks"]` ou clé `config.yaml`	`false`
WDL	entrée workflow `Boolean use_parabricks`	`false`
Python	drapeau CLI `--use-parabricks` ou env `USE_PARABRICKS`	désactivé

Documentez le nom de la bascule, le défaut et les exemples de commandes d'exécution dans ACCELERATION.md.

Schémas d'implémentation

Framework	Schéma
Nextflow	Processus/modules Parabricks optionnels avec `when: params.use_parabricks` sur le chemin GPU et `when: !params.use_parabricks` sur le chemin CPU. Le profil ou `-params-file accelerated.config` active la bascule. Étiquettes GPU uniquement sur les processus accélérés.
Snakemake	Règles CPU vs GPU parallèles ; ramification dans `rule all` sur `config["use_parabricks"]`. `--configfile config.accelerated.yaml` ou `--config use_parabricks=true`.
WDL	`if (use_parabricks) { call Parabricks_fq2bam } else { call BwaMem ... }`. Runtime GPU uniquement sur les tâches Parabricks.
Python	drapeau `--use-parabricks` ; branche subprocess vers `docker run ... pbrun` vs commandes CPU existantes.

Règles :

Ne pas supprimer les étapes CPU d'origine lors de l'ajout de l'accélération.
Défaut désactivé doit reproduire le chemin CPU d'aujourd'hui.
Câbler les étapes en aval pour consommer quelle que soit la branche exécutée (faire correspondre les noms de canaux/sorties autant que possible).
Ressources GPU, conteneurs et conseils d'exécuteur uniquement sur les étapes accélérées.
Préférez les modules Parabricks nf-core pour Nextflow ; installez dans le même arborescence de repo.

Sections minimales de ACCELERATION.md : utilisation de la bascule, cible d'exécution, mappages, câblage de sortie, opportunités de consolidation, liste de contrôle de comparaison A/B.

Voir workflow-layout.md.

7. Itération de consolidation

Après la comparaison A/B, examinez si la branche GPU peut fusionner les étapes adjacentes (p. ex. BWA + tri + MarkDuplicates + BQSR → un seul fq2bam / parabricks_fq2bam).

Rapport uniquement : suggérez les fusions et demandez l'approbation. Avec approbation : éditez uniquement la branche GPU (when: params.use_parabricks ou équivalent), supprimez les sous-étapes GPU dépassées, mettez à jour l'historique de consolidation dans ACCELERATION.md et rappelez à l'utilisateur de ré-exécuter la comparaison bascule-désactivée vs bascule-activée.

Ne pas supprimer les étapes CPU du chemin par défaut à moins que l'utilisateur ne demande explicitement le basculement après validation. Ne pas fusionner l'appel de variants dans fq2bam.

Voir step-consolidation.md.

8. Comparer avant la production

Ne jamais affirmer la parité des résultats. Comparez le même workflow avec la bascule désactivée vs activée — mêmes échantillons, référence, intervalles ; répertoires de sortie distincts (p. ex. results-cpu/ vs results-gpu/).

Utilisez comparison-checklist.md pour flagstat, le taux de doublons, la concordance VCF, le temps mural, l'utilisation GPU et la version Parabricks. Enregistrez les résultats dans la section Comparaison A/B de ACCELERATION.md.

# Chemin CPU (par défaut)
<framework-run-command>                         # bascule désactivée

# Chemin GPU
<framework-run-command-with-toggle-on>          # p. ex. -params-file accelerated.config

9. Optionnel : artefacts de benchmark et de comparaison

Quand l'utilisateur demande l'automatisation ou que des données de test et une configuration exécutable existent déjà, vous pouvez en outre :

Fournir un script pour exécuter la bascule-désactivée et la bascule-activée sur les mêmes entrées
Capturer le temps mural et, le cas échéant, l'utilisation CPU/GPU par étape ou globale
Résumer les résultats dans ACCELERATION.md ou un tableau de comparaison HTML/markdown simple

Si aucun dataset de test n'existe, suggérez de créer une exécution de petit sous-ensemble et documentez le plan de comparaison dans ACCELERATION.md plutôt que de bloquer sur des scripts personnalisés.

Ne pas exiger des scripts de benchmark ou des rapports HTML pour chaque implémentation sauf si l'utilisateur le demande.

Dépannage

Situation	Action
Aucun chemin de workflow	Demander repo, répertoire, Snakefile, WDL, point d'entrée Nextflow ou script Python
`nvidia-smi` / `pbrun` indisponibles localement	Continuer le câblage ; demander cible HPC vs cloud
Aucun mappage Parabricks	Marquer le problème ; garder l'étape CPU uniquement
Parité incertaine	Exécuter bascule-désactivée vs bascule-activée avant l'utilisation GPU en production
Copie de production unique, pas de git	Recommander branche ; bascule par défaut désactivée ; documenter la restauration dans `ACCELERATION.md`

Exemples

Aucun chemin

Utilisateur : « Rends mon pipeline en génomique plus rapide et convertis-le vers les GPU. »

Réponse : demander le chemin du workflow et le framework. Ne pas fabriquer un mappage de pipeline.

Inspection Nextflow (rapport uniquement)

Utilisateur : « Inspecte main.nf pour les opportunités Parabricks — ne modifie pas les fichiers. »

Réponse : mapper BWA/MarkDuplicates/HaplotypeCaller vers les modules nf-core, proposer params.use_parabricks par défaut false, noter la consolidation fq2bam et la contrainte symlink/copie, référencer la documentation nf-core. Ne pas modifier les fichiers.

Nextflow en place

Ajouter params.use_parabricks = false, optional parabricks_fq2bam et parabricks_haplotypecaller avec gardes when:, garder les processus CPU pour le chemin par défaut, ajouter accelerated.config, documenter les deux commandes d'exécution dans ACCELERATION.md.

Snakemake en place

Ajouter use_parabricks: false à config.yaml, règles parallèles pbrun fq2bam et pbrun haplotypecaller avec ressources GPU, ramification dans rule all, documenter snakemake --config use_parabricks=true dans ACCELERATION.md.

WDL en place

Ajouter Boolean use_parabricks = false, branche vers les tâches Parabricks quand true, runtime GPU uniquement sur la branche GPU, documenter l'entrée JSON pour les deux modes dans ACCELERATION.md.

Python en place

Ajouter --use-parabricks par défaut false, branche subprocess vers pbrun dans le conteneur vs commandes CPU, documenter les deux invocations dans ACCELERATION.md.

Demande de production sur copie unique

Utilisateur : « Remplace BWA par Parabricks dans notre seul main.nf — édite en place. »

Réponse : étapes Parabricks optionnelles avec bascule par défaut désactivée, garder le chemin CPU, recommander la branche git, documenter la bascule et A/B dans ACCELERATION.md, ne pas supprimer les étapes CPU sans approbation post-validation.

genomics-workflow-acceleration