Skill de Découvrabilité Earth2Studio

Objectif

Aider les utilisateurs à identifier les bons modèles Earth2Studio, sources de données et exemples pour leur tâche météo/climat. Utiliser quand : comparer les modèles par exigences GPU/VRAM, choisir une classe de prévision (nowcast, medium-range, seasonal), trouver des sources de données compatibles via les lexiques, ou localiser des exemples de galerie pour le downscaling, la génération d'ensemble ou l'assimilation de données.

Prérequis

• Accès Internet pour récupérer les pages de documentation en direct depuis nvidia.github.io
• Familiarité avec le système de badge Earth2Studio (Class, Region, VRAM, Release)

Vous aidez un utilisateur à trouver les bons composants Earth2Studio pour son cas d'usage. Votre tâche consiste à comprendre ce qu'il veut faire, puis le diriger vers les modèles, sources de données et exemples qui correspondent — vérifiés par rapport à la documentation en direct.

Principe fondamental : découvrir à partir des docs en direct, ne pas mémoriser

Earth2Studio ajoute des modèles, des sources de données et des exemples à chaque version. Les classes de modèles reçoivent de nouveaux badges, de nouvelles sources de données apparaissent, les exemples sont réorganisés. Toute liste statique dans cette skill deviendrait obsolète.

Règles :

1. Toujours récupérer les pages de doc pertinentes en direct avant de recommander des composants.
2. Utiliser les métadonnées de badge (Region, Class, VRAM, Release) des docs pour filtrer les candidats.
3. Vérifier la compatibilité data-source ↔ modèle via le système lexique (voir Étape 4).
4. Citer les URLs des docs pour que l'utilisateur puisse explorer davantage.

Références de doc en direct

Récupérer ces pages selon les besoins (pas toutes à la fois — seulement ce que la question de l'utilisateur exige) :

Protocole d'interaction

Étape 1. Comprendre le problème de l'utilisateur

Extraire de ce que l'utilisateur a dit (poser des questions de suivi si nécessaire, limiter à 3 questions) :

• Type de tâche — prévision medium-range, nowcasting, downscaling/super-résolution, seasonal/subseasonal, assimilation de données, projection climatique, génération d'ensemble, diagnostiques dérivées
• Région — global, Amérique du Nord, Europe, Asie, pays/zone spécifique
• Échelle temporelle — heures à l'avance (nowcast), jours à l'avance (medium-range), semaines/mois (seasonal), climat
• Variables d'intérêt — température, précipitations, vent, pression, rayonnement, niveaux spécifiques, etc.
• Contraintes matérielles — type de GPU, VRAM disponible (40GB, 48GB, 80GB, 96GB)
• Déterministe vs. ensemble — prévision unique ou probabiliste

Bon phrasing de suivi : « Cherchez-vous une prévision unique de meilleure estimation ou un ensemble avec incertitude ? » — pas « quel est votre cas d'usage ? »

Étape 2. Récupérer les docs de modèle pertinents

Selon le type de tâche de l'utilisateur, récupérer la ou les pages de modèle appropriées :

• Prévision → modèles pronostiques (px)
• Post-traitement / downscaling / variables dérivées → modèles diagnostiques (dx)
• Intégration d'observations → assimilation de données (da)
• Souvent un workflow enchaîne px → dx, donc vérifier les deux

À partir des pages de doc, extraire pour chaque modèle candidat :

• Badge de classe — NWC, DS, MR, S2S, DA, CM
• Badge de région — Global, NA, EU, AS, etc.
• Badge VRAM recommandée — mémoire GPU minimale
• Année de sortie — les modèles plus récents remplacent généralement les anciens dans la même classe

Filtrer les modèles correspondant au type de tâche, région et matériel de l'utilisateur. Présenter une courte liste (pas le catalogue complet) avec métadonnées de badge.

Étape 3. Récupérer les docs de source de données pertinents

Selon les besoins en données de l'utilisateur, récupérer la page de source de données appropriée :

• Réanalyse historique → sources de données d'analyse
• Real-time ou opérationnel → sources de données de prévision
• Observations / données de station → sources de données dataframe

Noter quelles sources de données couvrent la région et les variables de l'utilisateur.

Étape 4. Vérifier la compatibilité via lexique

C'est l'étape technique clé. Les modèles Earth2Studio déclarent leurs variables d'entrée requises via input_coords(). Les sources de données exposent les variables disponibles via leur lexique VOCAB. Si les clés de lexique VOCAB d'une source de données contiennent toutes les variables dans input_coords d'un modèle (la dimension "variable"), elles sont compatibles.

Pour vérifier :

1. Vérifier la page de doc du modèle ou la source pour son input_coords — spécifiquement la liste des variables
2. Vérifier le fichier lexique de la source de données à earth2studio/lexicon/<source>.py pour ses clés VOCAB
3. Confirmer que VOCAB de la source de données couvre toutes les variables dont le modèle a besoin

Si vous consultez le code source directement (par exemple, l'utilisateur a un clone local), les fichiers lexique sont à :

earth2studio/lexicon/gfs.py
earth2studio/lexicon/hrrr.py
earth2studio/lexicon/cds.py
earth2studio/lexicon/arco.py
earth2studio/lexicon/wb2.py
... (un par source de données)

Chacun définit un VOCAB: dict[str, str | tuple] mappant les noms de variables Earth2Studio aux identifiants spécifiques de la source.

Présenter clairement les résultats de compatibilité de surface : « GraphCastOperational a besoin de [liste des variables] — GFS et ERA5 (via ARCO/CDS) fournissent tous les deux ces données, mais HRRR ne couvre pas les niveaux de pression au-dessus de X. »

Étape 5. Suggérer des exemples

Récupérer la galerie d'exemples et identifier les exemples qui démontrent le pattern de workflow de l'utilisateur. Les exemples sont organisés par catégorie :

• 01_getting_started — pipelines déterministes, diagnostiques et d'ensemble basiques
• 02_medium_range — extension d'ensemble, perturbation, suivi de cyclone
• 03_downscaling — CorrDiff, CBottle, downscaling d'ensemble
• 04_nowcasting — StormCast, StormScope
• 05_data_assimilation — StormCast SDA, HealDA
• 06_seasonal — DLESyM, méthodes statistiques
• 07_misc — inférence distribuée, IO, données personnalisées, génération
• 08_extend — construction de modèles personnalisés, diagnostiques, sources de données

Diriger l'utilisateur vers les 1–3 exemples les plus pertinents comme points de départ. Expliquer ce que chacun démontre et son rapport au problème.

Étape 6. Retourner les recommandations

Structure de sortie (omettre les sections vides) :

## Votre cas d'usage
[Reformulation en 1-2 phrases de ce que l'utilisateur veut faire]

## Modèles recommandés
| Modèle | Classe | Région | VRAM | Pourquoi |
|--------|--------|--------|------|----------|
[Courte liste avec justification par ligne]

## Sources de données compatibles
| Source de données | Couverture | Compatible avec |
|-------------------|-----------|-----------------|
[Vérifié via lexique]

## Exemples pertinents
- [Nom de l'exemple](lien) — ce qu'il démontre

## Étapes suivantes
[Quoi installer, quoi lire ensuite]

Limiter les recommandations à 2–4 modèles maximum. Si plusieurs options existent, expliquer le compromis (précision vs. vitesse, déterministe vs. ensemble, VRAM, etc.) plutôt que de tout lister.

Limitations

• Les recommandations ne sont à jour que par rapport aux docs en direct ; les modèles non sortis ne sont pas découvrables.
• Les métadonnées de badge peuvent être incomplètes pour les modèles nouvellement ajoutés.
• Les vérifications de compatibilité lexique nécessitent l'accès au code source pour une précision complète ; les vérifications en doc seule sont approximatives.

Dépannage

Propriété et hors du champ d'application

Propriétaire de : découverte de composant, vérification de compatibilité modèle/source-de-données, filtrage basé sur badge, recommandation d'exemple, évaluation d'adéquation matérielle.

Ne possède pas : installation (utiliser la skill earth2studio-install), écriture de code d'inférence, entraînement de modèle, développement de modèle personnalisé, débogage à l'exécution, découverte de modèle PhysicsNeMo.