Normes de simulation
Meilleures pratiques pour la conception des expériences, les entrées/sorties et l’utilisation de QUEST
Conception de l’expérience
Lors de la mise en place d’une expérience de simulation, il convient de tenir compte du nombre de paramètres à modifier et de scénarios à exécuter. Il est rare qu’une seule grande simulation puisse fournir une réponse immédiate et qu’elle soit correctement configurée. Prévoyez plusieurs itérations qui s’ajoutent les unes aux autres pour acquérir de la confiance et une meilleure compréhension avant de mettre en place une expérience de simulation de plus grande envergure.
- Préparez un plan de simulation (liste des scénarios à exécuter) : quels sont les principales expériences de simulation que vous devez réaliser pour répondre à la question de recherche ? Quelles sont celles qui sont hors de portée ?
- Il peut être utile de créer une feuille Excel avec 1) les noms des paramètres et les valeurs pertinentes à explorer et 2) la combinaison des valeurs des paramètres qui définissent une expérience de simulation à exécuter. Un exemple est fourni [ICI]. Une utilisation plus avancée comprend également des notes sur le nombre de scénarios, les ressources informatiques et le temps nécessaire.
- Pilotez avant de passer à l’échelle supérieure : Commencez simplement et utilisez un scénario modèle qui a été validé, puis ajoutez l’intervention ou la caractéristique d’intérêt pour un ou quelques paramètres avant d’exécuter l’ensemble.
- La faisabilité technique avant les prédictions précises : Il n’y a pas de mal à utiliser des paramètres fictifs pour les simulations de test afin de développer votre code et vos scripts ; cependant, gardez une trace de ces paramètres et n’oubliez pas de les mettre à jour avec les paramètres corrects dès que les tests initiaux sont terminés.
- Dans les simulations pilotes et de test, veillez à examiner attentivement les fichiers d’entrée json et de sortie. Voir l’examen des fichiers d’entrée et de sortie ci-dessous.
- Donnez à vos expériences de simulation des noms significatifs qui peuvent être versionnés et suivis à travers les itérations. Par exemple, tout test peut inclure “test” dans son nom et avoir une v0, v1 ou une date ou similaire incluse dans le nom ou le dossier dans lequel vos simulations sont stockées.
Certaines meilleures pratiques pour le calcul scientifique sont décrites par PLOS Biology en plus de ce que nous recommandons spécifiquement aux membres de cette équipe.
Examen des fichiers d’entrée et de sortie
Lorsque vous concevez de nouvelles expériences, vous devez veiller à examiner les fichiers d’entrée et de sortie pour vous assurer que vos simulations font ce que vous pensez qu’elles font. Il peut être difficile de tout configurer correctement la première fois, même pour les utilisateurs expérimentés d’EMOD, c’est pourquoi ce processus de révision vous aidera à vérifier avant de passer à l’échelle supérieure. Les questions à vérifier lors de l’examen des nouvelles simulations sont les suivantes :
- Les campagnes ont-elles été effectivement déployées, à la bonne couverture et au bon moment ?
- À quelle fréquence les campagnes ont-elles été déployées ?
- Comment la population simulée évolue-t-elle dans le temps ?
- Lors de l’exécution avec burnin, le burnin a-t-il été effectivement “ramassé” avec succès ?
- Les petites simulations permettent d’établir des rapports sur les événements individuels. À quel âge et à quelle fréquence les individus ont-ils bénéficié d’une intervention ou ont-ils changé de propriété ?
- Examinez la même mesure (c’est-à-dire la prévalence) non seulement au niveau agrégé dans le temps, mais aussi mensuellement.
- Les tranches d’âge sont-elles correctement définies, extraites dans l’analyseur et agrégées ?
- Comment vos graphiques se comparent-ils à d’autres relations connues ?
Utilisation de QUEST
Quest est le cluster de calcul haute performance (HPC) de Northwestern sur lequel nous effectuons nos simulations EMOD. Quest est un HPC basé sur linux avec le gestionnaire de charge de travail slurm pour planifier les tâches entre ses utilisateurs. Chacun devra demander l’accès à l’allocation Quest de l’équipe, b1139, ici. Une fois l’accès accordé, vous disposerez de 80 Go d’espace dans votre répertoire personnel et vous aurez accès à l’allocation de l’équipe qui dispose de beaucoup plus d’espace. Nous recommandons de cloner les dépôts GitHub dans le répertoire personnel et de sauvegarder tous les résultats dans un dossier approprié sur l’allocation de l’équipe.
Partage des ressources
Comme tous les membres de l’équipe, ainsi que les participants au programme, utilisent b1139, nous devons être conscients du partage des ressources. Veuillez suivre les bonnes pratiques ci-dessous afin que chacun puisse avoir la meilleure expérience possible de l’utilisation du cluster.
- Soyez conscient de la durée d’exécution de vos tâches. S’ils prennent beaucoup de temps, il est préférable d’exécuter moins de simulations à la fois ou d’attendre des périodes de faible utilisation (comme les soirs ou les week-ends) pour commencer les travaux. Vous pouvez activer la notification par courrier électronique pour les travaux soumis, et également vérifier dans le terminal via squeue -u <nom d’utilisateur> ou squeue -A b1139.
- Si vous devez exécuter un “gros travail” avec de nombreuses simulations, discutez de tout besoin urgent pour le cluster car d’autres peuvent avoir des projets sensibles au temps. Soumettez moins de 100 travaux à la fois sur b1139 pour éviter d’engorger le cluster. Il est facile de limiter le nombre de travaux pouvant être exécutés en même temps avec idmtools, de sorte que vous pouvez soumettre tous vos travaux en même temps, mais seul le nombre “max_run_jobs” spécifié sera exécuté en même temps. Au fur et à mesure que les simulations se terminent, les suivantes démarrent automatiquement.
- Déboguez vos simulations avec de petits pilotes (voir plan d’expérience) pour vous assurer que vos simulations donnent les résultats escomptés avant de passer à l’échelle supérieure.
- Pour gérer l’espace disque, vous pouvez vérifier l’espace utilisé en tapant
homedu
oucheckproject b1139
dans le terminal. Les simulations doivent être stockées dans les dossiers de projet respectifs sur b1139 afin qu’elles soient accessibles aux autres membres de l’équipe pour le dépannage et en raison de la faible limite de stockage sur les répertoires personnels. Veillez à supprimer les anciennes simulations et/ou les simulations qui ont échoué lorsqu’elles ne sont plus nécessaires, car elles peuvent occuper beaucoup d’espace de stockage.