Utilisation de Nx pour des projets multidisciplinaires d'optimisation (mdo)

Pour les projets MDO, les principales caractéristiques sont le graphique de dépendance, le mécanisme de cache et la capacité de mélanger plusieurs langues et de construire des outils dans un seul espace de travail. Nx traite chaque discipline comme un projet ou une bibliothèque, en respectant ses exigences uniques tout en fournissant une interface unifiée pour l'orchestration.

Principaux avantages de l'utilisation de Nx pour les projets d'ODM

Gestion centralisée et suivi des dépendances

Dans une configuration MDO traditionnelle, chaque discipline peut conserver son propre dépôt, suite de scripts et fichiers de données. Synchroniser les changements devient un processus manuel, sujet à erreur. Avec Nx, toutes les disciplines vivent dans un monorepo. Le graphe projet vous donne une carte en direct des interdépendances : une bibliothèque d'analyse aérodynamique peut dépendre d'une bibliothèque de géométrie partagée ; un outil d'optimisation structurelle peut dépendre des deux. Lorsque la bibliothèque de géométrie change, Nx sait instantanément quels autres modules doivent être reconstruits ou retestés.

Collaboration accrue entre les équipes

Les contraintes basées sur l'étiquette vous permettent de définir des limites – par exemple, un projet de structures ne peut dépendre directement d'une bibliothèque d'aérodynamique que par une interface publique. ► Les règles de lint Nx , qui empêchent le couplage accidentel, sont appliquées. Les révisions de code deviennent plus simples parce que le monorepo fournit une seule source de vérité et les commandes aident les examinateurs à se concentrer uniquement sur les parties modifiées.

Écailabilité pour l'optimisation à grande échelle

Les projets MDO impliquent souvent des centaines de modules, des milliers de fichiers et des chaînes de simulation complexes. Nx est conçu pour gérer des monorepos avec des dizaines de milliers de projets. Son mécanisme de cache fonctionne par tâche et par fichier, de sorte que même si vous avez de nombreuses disciplines, vous exécutez rarement le même calcul deux fois.

Outillage intégré pour la qualité et l'automatisation

Pour MDO, ces outils peuvent être appliqués non seulement au code, mais aussi aux fichiers de configuration, aux entrées de simulation et même aux scripts de validation. Vous pouvez, par exemple, créer un exécuteur Nx qui exécute un test de régression sur une sortie de solveur aérodynamique. Cela garantit que les optimisations n'introduisent pas de régressions.

Calcul de la cache – Un changement de jeu pour l'optimisation itérative

Un algorithme d'optimisation peut demander des dizaines ou des centaines d'évaluations de conception. Avec le cache Nx , si un code de discipline ou d'entrée n'a pas changé, sa sortie précédente est réutilisée sans re-démarrer le solveur. Ceci est particulièrement puissant lorsque différents cycles d'optimisation partagent des résultats intermédiaires communs. Le cache peut être local ou distribué via Nx Cloud, de sorte que même l'optimisation parallèle peut se faire sur plusieurs agents CI.

Intégration des langues et des outils croisés

Nx est un langage-agnostique au niveau des tâches. Vous pouvez définir un exécuteur qui produit un script Python pour la dynamique des fluides informatiques, un exécutable C++ pour l'analyse des éléments finis et un service Node.js pour l'assimilation des données. Toutes ces tâches sont gérées par le graphique des tâches Nx.

Mise en œuvre de Nx dans votre flux de travail MDO

La transition d'un projet multidisciplinaire en un monorepo Nx comporte plusieurs étapes. Ci-dessous est un guide pratique, illustré par un exemple aérospatial.

Étape 1: Mettre en place l'espace de travail Nx

Créer un nouvel espace de travail Nx en utilisant la commande :

npx create-nx-workspace@latest aerospace-mdo --preset=empty

L'espace de travail sera la maison pour toutes les disciplines. Choisissez le gestionnaire de paquets de votre préférence (npm, fil, pnpm) et engagez la structure générée au contrôle de la version.

Étape 2 : Structurer les disciplines comme projets ou bibliothèques

Chaque discipline majeure devrait devenir un projet Nx --. - Par exemple, créer une application pour l'emballage ou le pipeline d'optimisation globale, et des bibliothèques pour les analyseurs individuels:

• – une bibliothèque contenant la configuration du résolveur de dynamique de fluide et l'enveloppe.
• – une bibliothèque pour le solveur d'analyse structurelle.
• – une application qui orchestre la boucle d'optimisation.
• – une bibliothèque avec des définitions de géométrie communes et des utilitaires de conversion.

Utiliser ou pour générer des structures cohérentes. Les générateurs Nx font appliquer les meilleures pratiques et s'assurent que chaque projet a ses propres pour la configuration des tâches.

Étape 3 : Définir les limites et les étiquettes du projet

Utilisez des balises pour appliquer les règles de couplage de discipline. Modifiez les fichiers ou individuels pour ajouter des balises comme , , etc. Par exemple, vous pouvez créer une règle ESLint qui interdit à une bibliothèque d'importer directement depuis , seulement par . Cela permet de garder les dépendances propres et empêche les dépendances circulaires.

Étape 4: Intégrer les outils d'optimisation comme executeurs

Pour le résolveur d'aérodynamique, créez un exécuteur qui exécute un script Python. Pour le résolveur de structure, peut-être un exécutable C++. Exemple de configuration de l'exécuteur dans pour la bibliothèque d'aérodynamique:

{
 "targets": {
 "solve": {
 "executor": "nx:run-commands",
 "options": {
 "command": "python solvers/aero/main.py --input={projectRoot}/input.json --output={projectRoot}/output.json",
 "cwd": "{workspaceRoot}"
 }
 }
 }
}

Maintenant vous pouvez exécuter , et Nx gérera automatiquement la mise en cache et la commande de dépendance. Utilisez pour spécifier quels fichiers sont mis en cache (par exemple .

Étape 5: Automatiser la boucle d'optimisation

L'application d'optimisation peut définir une cible qui exécute l'ensemble du cycle MDO. Par exemple, une cible qui exécute le script d'optimisation, qui appelle à son tour des tâches Nx pour chaque discipline via les processus enfants Node.js ou en utilisant l'API programmatique Nx. Comme chaque résolveur de discipline est une tâche Nx, l'optimiseur peut utiliser Nx=25 et les résultats mis en cache pour accélérer l'itération.

Étape 6 : Mettre en place un CI avec les commandes touchées

Dans votre pipeline CI (GitHub Actions, GitLab CI, etc.), utilisez , et pour effectuer des vérifications uniquement sur des projets modifiés. Pour MDO, vous pouvez également vouloir une cible qui ne réexécute que les résolveurs pour des disciplines modifiées.

Étude de cas 1 : Optimisation aérodynamique et structurelle d'une aile d'aéronef

Le projet comprend trois disciplines principales : l'aérodynamique (prévoir le levage et la traînée), les structures (assurer le respect des contraintes de résistance et de poids) et un algorithme d'optimisation qui ajuste les paramètres de forme des ailes. Sans Nx, les ingénieurs conserveraient des dépôts séparés pour chaque solveur, transféreraient manuellement des fichiers géométriques et exécuteraient la boucle d'optimisation avec des scripts ad-hoc. Avec Nx, la configuration est unifiée.

L'espace de travail contient:

• – une bibliothèque qui définit la forme de l'aile (coordonnées de l'air, distribution de torsion, etc.). Elle produit un fichier JSON utilisé par les deux solveurs.
• – une bibliothèque avec un exécuteur qui exécute un code CFD (p. ex. OpenFOAM ou SU2). Cela dépend .
• – une bibliothèque avec un exécuteur qui exécute un résolveur d'éléments finis (par exemple, CalculiX ou Abaqus). Cela dépend également de .
• – une application qui exécute la boucle d'optimisation (par exemple, en utilisant un modèle de substitution ou une recherche directe).

Lorsqu'un ingénieur met à jour la bibliothèque de géométrie de l'aile, Nx marque les deux solveurs comme affectés. La prochaine itération d'optimisation (via ) reconstruise ou ré-ajuste automatiquement les solveurs. L'optimisation itérative devient rapide parce que Nx caches sorties solveur pour des entrées de géométrie données. Si la géométrie revient à une version antérieure, le cache est réutilisé sans recomputation. Cela entraîne une réduction de 60 à 80 % du temps total d'optimisation par rapport à un workflow non encadré.

Étude de cas 2: Optimisation thermique et structurelle de l'automobile

En ingénierie automobile, un pack de batterie EV doit être optimisé simultanément pour la gestion thermique et la résistance à l'écrasement structural. Les disciplines sont la simulation thermique (CFD/transfert thermique) et la simulation structurelle (FEA). Ils partagent un modèle CAO commun du pack de batterie. Nx est utilisé pour créer un monorepo qui comprend:

• – une bibliothèque qui gère le modèle CAO paramétrique (exporté sous forme de STEP ou de maillage).
• – une bibliothèque utilisant un exécuteur pour un résolveur thermique (par exemple, Star‐CCM+ ou un script Python personnalisé).
• – une bibliothèque avec un exécuteur pour un résolveur de dynamique explicite (p. ex. LS‐DYNA).
• – une application qui exécute un algorithme génétique multi-objectifs.

Avec Nx.S distribué en cache, un pipeline CI fonctionnant sur 32 agents parallèles peut évaluer simultanément plusieurs conceptions, en partageant les résultats thermiques mis en cache entre les agents. Le graphique du projet révèle que le résolveur de crash ne dépend pas directement de la sortie du résolveur thermique (seulement sur le CAO partagé), de sorte que les modifications apportées aux paramètres du modèle thermique n'invalident pas les caches de simulation de crash – une caractéristique essentielle pour l'efficacité.

Techniques avancées pour le MDO alimenté par Nx

Exécuteurs personnalisés pour outils non-JavaScript

Pour les solveurs écrits en Python, Fortran ou CUDA, créez un simple exécuteur qui exécute le binaire externe et capture stdout/stderr. Utilisez l'exécuteur ou créez un exécuteur personnalisé avec l'API Nx Executor. Cela vous permet d'appliquer le suivi de la mise en cache et de la dépendance pour les outils qui n'ont pas autrement la notion de constructions progressives.

Utilisation de Nx , Cache-caches avec des agents distants

Dans un contexte MDO, cela signifie que si un point de conception a déjà été simulé par un membre de l'équipe ou un travail de CI, le résultat est immédiatement disponible. Ceci est particulièrement utile pour explorer l'espace de conception avec des algorithmes d'optimisation comme des algorithmes génétiques ou des essaims de particules – de nombreux points de conception sont évalués en parallèle, et le cachage empêche les exécutions redondantes de solveur.

Production de code supplémentaire pour les modèles MDO

Les générateurs Nx peuvent être utilisés pour échafauder des modèles de code spécifiques à la discipline. Par exemple, créer un générateur personnalisé qui produit un nouveau projet de solveur aérodynamique avec la structure correcte du répertoire, la configuration de l'exécuteur et les stubs de test. Cela assure la cohérence et réduit le temps de configuration lors de l'ajout d'une nouvelle discipline à l'optimisation.

Intégration avec les outils de gestion de données

De nombreux projets MDO reposent sur un entrepôt de données ou un dépôt de conception (p. ex. Directus.Avec Nx, vous pouvez créer une bibliothèque qui agit comme client pour votre API de données. La bibliothèque peut être partagée dans toutes les disciplines, assurant une source unique de vérité pour les variables de conception, les contraintes et les métadonnées.

Surmonter les pièges communs

Éviter les dépendances monolithiques

Un risque de monorepos est que les disciplines deviennent trop étroitement couplées. Utilisez les balises Nxs et les restrictions d'importation ESLint pour faire respecter une architecture propre. Par exemple, ne permettre que bibliothèques à importer par plusieurs disciplines; chaque discipline devrait dépendre de types et interfaces partagés, et non d'une autre discipline.

Gestion des fichiers binaires de grande taille

Les solvants produisent souvent de grands fichiers de sortie (grids, champs de solution, etc.). Les caches Nx basés sur des haches de fichiers, donc le stockage de grandes sorties peut gonfler le cache. Solution : marquez la sortie du solveur comme un seul fichier de résumé (par exemple ] avec des indicateurs de performance clés) et cache qui au lieu de cela.

Assurer la reproductibilité

Les résultats MDO doivent être reproductibles. Avec Nx, l'espace de travail entier est mis en version, et la mise en cache des tâches comprend des entrées (fichiers sources, configurations, même variables d'environnement si déclaré). Cela facilite le retour à une itération de conception spécifique et réexécute l'optimisation de façon identique.