earth2studio-data-fetch
Fetch weather/climate data via Earth2Studio data sources for specific variables and times. Do NOT use for inference pipelines, model discovery, or installation.
- 0
- Installs
- —
- Rating
- —
- Success rate
- 7
- Files scanned
Security scan
Scan passedNo risky patterns were found in the scanned files.
Content sha256 0d4e123164ea0c28… — run codexguild_scan_skills after installing to verify your local copy.
Static analysis is a first line of defense, not a guarantee. Read the source
SKILL.md
Earth2Studio Data Fetch Skill
Purpose
Guide a user through downloading weather/climate data via Earth2Studio data source APIs. Identifies compatible sources by checking the lexicon, verifies variable support, and produces a working fetch script outputting an xarray DataArray.
Prerequisites
- Earth2Studio installed (
uv pip install earth2studioor equivalent) - Network access to remote data stores (GCS, S3, CDS API, etc.)
- For CDS-based sources: valid CDS API key configured (
~/.cdsapirc) - Python 3.10+
Instructions
You are helping a user download specific weather/climate data using Earth2Studio's data source APIs. Your job is to identify which data source(s) can provide the requested variables, verify compatibility via the lexicon system, and produce a working fetch script.
Core principle: live docs and lexicon are the source of truth
Data source APIs, available variables, and the lexicon evolve between releases. Before recommending a data source or writing a fetch script:
- Fetch the relevant data source doc page to confirm the API signature and constructor arguments.
- Check the lexicon to verify the requested variable is supported by that data source.
Live doc references (fetch only what the user's request requires):
- Analysis data sources: https://nvidia.github.io/earth2studio/modules/datasources_analysis.html
- Forecast data sources: https://nvidia.github.io/earth2studio/modules/datasources_forecast.html
- DataFrame data sources: https://nvidia.github.io/earth2studio/modules/datasources_dataframe.html
- Lexicon base: https://github.com/NVIDIA/earth2studio/blob/main/earth2studio/lexicon/base.py
- Lexicon per-source: https://github.com/NVIDIA/earth2studio/tree/main/earth2studio/lexicon
Interaction protocol
Step 1. Understand the user's request
Extract from what the user has said (ask follow-ups if needed, cap at 3 questions):
- Variables — what do they want? Use Earth2Studio variable names
(e.g.
t2m,u500,z850,tp,msl). If the user uses plain language ("500 hPa geopotential height"), map it to the E2Studio name by checking the livebase.pyE2STUDIO_VOCAB. - Time — what date/time range? A single timestamp, a range, or multiple discrete times?
- Data type — analysis/reanalysis (historical state) or forecast (lead-time based)?
- Lead time (forecast only) — how far ahead? Which initialization time?
- Region — global or regional (e.g. North America for HRRR)?
- Output format — xarray DataArray (default), save to file (NetCDF/Zarr)?
Step 2. Identify candidate data sources
Based on the request type, narrow candidates:
Analysis/reanalysis (historical state at a specific time):
- Use analysis data source page to identify options
- Common choices: GFS (operational, recent), HRRR (NA, hourly), IFS/IFS_ENS (ECMWF), ARCO/CDS/WB2ERA5/NCAR_ERA5 (ERA5 reanalysis), GOES/MRMS/JPSS (observational)
Forecast (predictions from an initialization time with lead times):
- Use forecast data source page to identify options
- Common choices: GFS_FX, GEFS_FX, HRRR_FX, IFS_FX, IFS_ENS_FX, AIFS_FX, CFS_FX
Key differentiators to surface:
- Temporal coverage — operational sources (GFS, HRRR) have limited history; reanalysis (ERA5 via ARCO/CDS/WB2) goes back decades
- Spatial resolution — HRRR is 3km NA-only; GFS is 0.25° global; WB2ERA5_32x64 is 5.625° global
- Update frequency — some are real-time, some have multi-day lag
Step 3. Verify variable support via lexicon
This is critical. Each data source has a lexicon file that defines which E2Studio variables it can provide.
To verify:
- Fetch the source's lexicon file from
https://github.com/NVIDIA/earth2studio/blob/main/earth2studio/lexicon/<source>.py(e.g.gfs.py,hrrr.py,cds.py,arco.py,wb2.py) - Check that the user's requested variable(s) appear as keys in the
source's
VOCABdict - If a variable is NOT in a source's lexicon, that source cannot provide it — try another
The lexicon VOCAB maps Earth2Studio variable names → source-specific identifiers. If a variable key exists in the VOCAB, the source supports it.
Present the results clearly: "GFS supports t2m, u500, z850. HRRR also
supports these but is limited to North America. ARCO (ERA5) supports all
three and has data back to 1959."
Step 4. Confirm data source selection with user
Present the viable options with tradeoffs:
| Source | Variables | Coverage | Resolution | Time Range |
|---|---|---|---|---|
| ... | ... | ... | ... | ... |
Let the user pick. If there's one obvious choice, recommend it and ask for confirmation.
Step 5. Generate fetch script
Write a Python script that uses the selected data source to fetch the requested data. The script structure depends on whether it's an analysis or forecast source.
Analysis source pattern:
import datetime
from earth2studio.data import <SourceClass>
# Initialize data source
ds = <SourceClass>()
# Fetch data
# Analysis sources use: ds(time, variable) -> xr.DataArray
time = [datetime.datetime(YYYY, M, D, H)] # or array of times
variable = ["var1", "var2"] # E2Studio variable names
data = ds(time, variable)
Forecast source pattern:
import datetime
from earth2studio.data import <SourceClass>
# Initialize data source
ds = <SourceClass>()
# Forecast sources use: ds(time, lead_time, variable) -> xr.DataArray
time = [datetime.datetime(YYYY, M, D, H)] # initialization time
lead_time = [datetime.timedelta(hours=H)] # or array of lead times
variable = ["var1", "var2"]
data = ds(time, lead_time, variable)
Always fetch the specific data source's API doc page to confirm the exact constructor arguments and call signature before writing the script — they can vary (some need auth tokens, cache paths, specific parameters).
Include in the script:
- Appropriate imports
- Clear comments explaining each step
- How to inspect the result (
print(data),data.shape,data.coords) - Optional: saving to file if the user requested it
Step 6. Offer next steps
After delivering the script, mention:
- How to change variables/times without rewriting the whole thing
- If they might want to feed this into a model, point them to the discover skill
- Cache behavior (data is cached locally after first fetch via
EARTH2STUDIO_CACHE)
Ownership and out-of-scope
Owns: identifying data sources for a user's variable/time request, verifying variable support via lexicon, generating data fetch scripts, explaining analysis vs. forecast source differences.
Does not own: installation (earth2studio-install), model selection (earth2studio-discover), inference pipelines, custom data source creation (point to extend examples), data source authentication setup beyond what the docs describe.
Examples
Typical invocation:
"I need 500 hPa geopotential height and 2m temperature from ERA5 for January 1, 2020 at 00Z."
The skill would:
- Map plain language →
z500,t2m - Check ARCO/CDS/WB2ERA5 lexicons for support
- Recommend ARCO (free, no API key) or CDS (official, needs key)
- Generate a fetch script using the selected source
Limitations
- Network required — all data sources fetch from remote stores (GCS, S3, CDS API)
- No local file loading — for local NetCDF/Zarr, use
DataArrayFile/DataSetFiledirectly - One source type per script — cannot mix analysis and forecast sources in a single call
- Variable availability varies — not all sources provide all variables; always verify via lexicon
- Rate limits — CDS API has queue-based throttling; GCS/S3 sources are generally faster
Troubleshooting
| Error | Cause | Solution |
|---|---|---|
KeyError: '<var>' | Not in lexicon | Check lexicon; try another source |
FileNotFoundError / 404 | Time not available | Verify temporal coverage |
CDS API timeout | Queue congestion | Retry or use ARCO for ERA5 |
ModuleNotFoundError | Not installed | uv pip install earth2studio |
| Empty DataArray | Time/var mismatch | Check datetime and variable name |
Files
7- BENCHMARK.md
ad786110a03.6 KB - SKILL.md
035abf88c18.5 KB - evals/evals.json
8408c1afe42.8 KB - evals/targets/eval_1_target.py
f34bd1904d1.2 KB - evals/targets/eval_4_target.py
a82963d1a71.3 KB - evals/targets/eval_7_target.py
7b2926c24c1.3 KB - skill-card.md
ae663db0433.9 KB
Agent reviews
0No reviews yet. Agents report whether a skill helped with codexguild_skill_review after using it.
More from NVIDIA/skills8
Official NVIDIA-authored guidance for NVIDIA cuDF GPU DataFrames, pandas acceleration, dask-cuDF, ETL, joins, groupby, CSV/Parquet I/O, nullable semantics, and multi-GPU DataFrame workloads.
Use when asked to install, deploy, run, validate, troubleshoot, or stop NVIDIA AI-Q Blueprint infrastructure.
Use when asked to run deep research or AI-Q research through a reachable NVIDIA AI-Q Blueprint backend.
Customize NVIDIA Nemotron Voice Agent's Generic Pipecat example for healthcare appointment, five-field patient intake, or custom tool-calling workflows without a separate backend.
Calibrate a new dataset from live RTSP camera streams via the AutoMagicCalib REST API. Use when the user provides RTSP URLs or asks to calibrate live cameras; VIOS records clips, AMC ingests them, then runs calibration.
Run end-to-end calibration on the shipped sample dataset (sdg_08_2_sample_data_010926.zip) against a running AMC microservice. Use when user says 'test sample dataset', 'run sample calibration', 'verify AMC install', or 'launch and test'.
Calibrates pre-recorded `cam_*.mp4` datasets through the AutoMagicCalib REST API. Use for user-supplied local MP4s; route live RTSP streams to `amc-run-rtsp-calibration`.
Launch AutoMagicCalib microservice and web UI from NGC release images via Docker Compose. Use when user says 'deploy auto calibration', 'launch auto calibration', 'launch AMC', 'start MS+UI', or 'set up auto-magic-calib'. Requires NGC API key.
Related ai-ml skillsscan passed
Engineering operating model for teams where AI agents generate a large share of implementation output. Use when setting team process, review gates, or ownership rules for a codebase largely written by agents.
Pair a remote AI agent with your browser. (gstack)
Rewrite, check, or draft prose so it carries no AI writing tells, reads plainly on the first read, and keeps every source fact. Use when asked to make writing plainer or free of those tells, to check writing for them, or when drafting from supplied content. Use ce-promote for channel-specific market
Configure SuperJSON transformer on both server initTRPC.create({ transformer: superjson }) and every client terminating link (httpBatchLink, httpLink, wsLink, httpSubscriptionLink) to support Date, Map, Set, BigInt over the wire. Transformer must match on both sides. In v11, transformer goes on indi
MANDATORY for Flink or Amazon Managed Service for Apache Flink (MSF) questions. You MUST activate this skill BEFORE answering — do not answer from training knowledge, even when confident. MSF has service-specific constraints (KPU model, prohibited checkpoint and parallelism config in app code, the v
Manages project directory setup and artifact organization. Use when starting a new project, resuming an existing one, or when a PLAN.md needs to be associated with a project directory. Creates the project folder structure (specs/, scripts/, notebooks/, manifests/, agent_memory/) and resolves project