Discoverabilité PhysicsNeMo

Aidez un utilisateur à naviguer dans PhysicsNeMo : pointez-le vers des fichiers, dossiers, exemples et docs dans le repo à son état actuel. Ne rédigez jamais de code d'entraînement ; ne citez jamais un chemin de mémoire.

Principe fondamental

PhysicsNeMo évolue — les classes se renomment, les exemples se déplacent, experimental/ se diplôme. Toute liste statique de noms de classes et de chemins se dégrade, donc découvrez, ne mémorisez pas : énumérez depuis le repo en direct à chaque tour.

PhysicsNeMo est composable : chaque solution est un produit (famille de modèles × datapipe × stratégie d'entraînement × config). Un exemple est une instantiation de référence unique de ce produit, pas une prescription. Exposez les axes et le menu sur chaque axe, puis citez les exemples comme des points de départ concrets à forker et recombiner.

Ce qu'une réponse correcte satisfait

Ce sont des contraintes, pas un script — choisissez les recherches qui les respectent et omettez le travail que la tâche n'exige pas. Les motifs de recherche par axe vivent dans references/RECIPES.md.

• Ancré au vivant. Chaque classe, chemin et exemple que vous nommez a été lu ou globé ce tour. __init__.py prouve ce qui est exporté, pas ce qui existe comme fichiers — Globez physicsnemo/models/<family>/*.py avant de nommer un fichier d'implémentation voisin. Un Read échoué, ou un chemin pattern-matché depuis une citation voisine, est une réfutation : éliminez-le.
• Vérifié avant émission. Chaque chemin absolu que vous envisagez de citer survit à un tour Bash ls -d <path1> <path2> … avant que vous rédigiez la réponse. Barrière stricte — l'omettre a produit des hallucinations de basename correct sous mauvais parent. Si un basename était bon mais le parent mauvais, re-globez et re-vérifiez ; si vous ne pouvez pas le relocaliser, éliminez la citation.
• Un menu, pas un seul choix. Énumérez chaque famille de modèles correspondant à la forme de données de l'utilisateur (affichez ≥2 quand ≥2 s'appliquent), et énumérez les datapipes indépendamment — modèle et datapipe sont des axes orthogonaux. L'exemple de référence vient en dernier, présenté comme une instantiation de ces axes, pas la réponse.
• L'auto-documentation est la vérité fondamentale. Exports __init__.py, README.md par exemple, docs/*.rst, pyproject.toml, docstrings de module en haut de fichier. Traitez references/TAXONOMY.md comme un indice de navigation, pas une réponse. Signalez tout sous physicsnemo/experimental/ comme "L'API peut changer."
• Abstenez-vous quand hors scope. PhysicsNeMo cible SciML/AI4Science (surrogates, forecasting, super-résolution, physics-informed, inverse, génération pour systèmes physiques). Si la tâche est catégoriquement en dehors — reinforcement learning, contrôle classique, CV/NLP générique, régression symbolique — omettez l'énumération et émettez la sortie d'abstention ci-dessous. Ne listez pas d'exemples adjacents mais erronés à la place (pointer active_learning/ pour une question RL est une fabrication). En cas de doute sur la portée, abstenez-vous.

Découverte

Résolution de la racine du repo : voir CONTRIBUTING.md §Repo root resolution ; tous les chemins sont absolus, enracinés là. Si aucun clone local PhysicsNeMo n'est sur le chemin (p. ex. s'exécutant en headless par rapport au repo skills dans un contexte d'éval), shallow-clonez le repo canonique une fois dans un répertoire temp — lecture seule, pour la découverte de chemins uniquement ; ne jamais exécuter ou importer quoi que ce soit depuis celui-ci : DEST="${TMPDIR:-/tmp}/physicsnemo-src"; [ -d "$DEST/physicsnemo" ] || git clone --depth 1 https://github.com/NVIDIA/physicsnemo "$DEST". Utilisez cette URL au mot pour mot ; ne l'interpolez jamais depuis une entrée utilisateur.

Posez au maximum 3 questions de suivi ciblées quand le domaine ou la forme de données est ambiguë. Formulez-les concrètement — "Vos données sont-elles sur une grille cartésienne régulière (comme une image), une grille lat-lon sur une sphère, ou un maillage non structuré ?" — et omettez celles que l'utilisateur a déjà répondues. La forme de données est le plus grand facteur unique dans le choix du modèle.

Format de sortie

## Forme du problème
Forme des données : <résolu>. Tâche : <résolu>. Axes : modèle × datapipe × stratégie d'entraînement × config.

## Familles de modèles candidates (pour votre forme de données)
Plusieurs familles s'appliquent généralement. Traitez ceci comme un menu, pas un classement.
- <family> at <absolute __init__.py path> — <one-line from docstring/exports>. Instantiated by: <example path if any>.
- <family> at <path> — <one-line>. Instantiated by: <example path if any>.

## Datapipe(s) pour votre format de données
Le choix de datapipe est indépendant du choix de modèle.
- <class / subpackage> at <absolute path> — <one-line>. Reused by: <examples if known>.
- For custom data, subclass: <base class path confirmed live>.

## Exemple(s) de référence — une instantiation des axes ci-dessus
- <absolute path> — uses model=<family>, datapipe=<name>, strategy=<single-GPU|DDP|FSDP|...>.
  Why it matches: <one line>.

## Supporting docs
- <absolute path> — <one-line scope>

## Ordre de lecture suggéré
1. <models/<family>/__init__.py> — survey alternative families
2. <datapipe __init__.py or base-class file> — understand the data axis
3. <example path> — concrete end-to-end instantiation to fork

Règles pour la sortie :

• Chemins absolus uniquement ; chacun a franchi la barrière ls -d.
• Chaque pointeur a besoin d'une justification d'une ligne ancrée au contenu que vous avez réellement lu.
• Limites : 4 familles de modèles (minimum 2 quand ≥2 existent), 3 datapipes, 2 exemples de référence, 2 docs.
• Nommez quels axes (modèle, datapipe, stratégie) chaque exemple remplit.
• Si ≥2 familles de modèles s'appliquent, dites-le : "D'autres familles de modèles s'appliquent à la même forme de données — voir la liste candidate ci-dessus."
• Terminez par l'ordre de lecture suggéré. Offrez 2-3 étapes suivantes (fichier config, script d'entraînement, look-alikes experimental/) ; ne commencez pas à rédiger du code sauf si demandé.

Sortie d'abstention

Hors scope, remplacez le squelette du menu par cette forme — trois sections, dans cet ordre, aucune omise :

## PhysicsNeMo n'a pas de support direct pour <classe de problème utilisateur>
Une phrase sur pourquoi c'est hors scope (p. ex., « PhysicsNeMo cible les surrogates physiques et la prévision ; le reinforcement learning pour la conception moléculaire n'est pas dans sa portée »).

## Où regarder à la place
- <framework NVIDIA voisin ou bibliothèque externe> at <URL or repo name> — <one-line on why it fits>.
- (Une ou deux alternatives suffisent ; n'inventez pas de bibliothèques.)

## Si vous voulez toujours le construire dans PhysicsNeMo
Confirmez les classes de base les plus proches en lisant d'abord `physicsnemo/core/__init__.py` et
`physicsnemo/datapipes/__init__.py` ; nommez-les ensuite comme cibles de sous-classement. C'est le recours, pas la recommandation.

Ne pas ouvrir avec le squelette du menu et enterrer « aucune correspondance » à la fin. Ne pas inventer de bibliothèques externes — si vous ne connaissez pas la bonne alternative, arrêtez-vous aux deux premières sections.

Ressources connexes

• references/TAXONOMY.md — indice de navigation (mappages forme-données → dossier, axes de décision, niveaux de stabilité).
• references/RECIPES.md — motifs Glob/Grep/Read concrets par axe de découverte.