METviewer

METviewer is a database-and-display system designed to work with the ASCII output statistics produced by the MET software. It loads that output into a relational database, gives you a web GUI to slice it with database queries, and turns the results into verification plots — plus a batch engine so the same plots can be regenerated, unattended, from a saved specification. It is the tool of choice when one verification dataset needs to be examined from dozens of angles.

What METviewer is

MET — the Model Evaluation Tools — runs verification and writes its results as plain ASCII tables: .stat files full of line types (rows of statistics like CTC, SL1L2, PCT), plus object-based output from MODE and MODE Time Domain. Those files are correct and complete, but they are not something you can explore. A single experiment can produce thousands of rows across many models, lead times, thresholds, regions, and dates.

METviewer closes that gap. It does three things:

Loads — A loader reads the MET ASCII output and inserts it into a relational database (MySQL or MariaDB), where every statistic becomes a queryable row.

Queries — A web application lets you build a plot by choosing axes, statistics, series, and constraints. Behind the scenes it writes the SQL that pulls exactly the rows you asked for.

Plots — The selected rows are aggregated and rendered into a verification plot — a PNG — and the whole specification is serialized to XML so it can be reloaded or run in batch.

It was developed at the Developmental Testbed Center (DTC) to serve both the research and operational communities — a common place where many people can interrogate the same verification results without re-running anything.

Who reaches for it

Anyone with a large MET verification dataset who wants to slice it many ways: compare two models across all lead times, break a score out by threshold and region, or stand up a shared database that a whole team queries through one web page.

How the pieces fit

METviewer is the hub of a small pipeline. MET writes ASCII; a loader fills a database; the web app queries that database; aggregation and plotting libraries turn the rows into pictures. The same engine can be driven by hand (the GUI) or unattended (the batch path), and both routes pass through the same XML specification.

Figure 1. MET ASCII output is loaded once into a database; the web app and the batch engine then query it repeatedly. Aggregation statistics come from METcalcpy and plots are rendered to PNG by R (or, in newer versions, METplotpy).

A note on the engine

METviewer installs alongside Java, Apache/Tomcat, and a MySQL/MariaDB database, plus the METdataio, METdbLoad, METcalcpy and METplotpy modules. Historically plots were rendered through the R statistical package; in newer releases the R path is deprecated in favor of Python (3.12) and METplotpy. The XML specification you build in the GUI is the same one the batch engine consumes, which is what keeps hand-made and scripted plots identical.

What it loads

Loading is driven by the mv_load.sh script (the METdbLoad component of METdataio), which reads a load-specification XML file — its top-level tag is <load_spec> — containing database connection details, a date list, file-path templates, and a set of flags that say which kinds of MET output to ingest. You can also restrict ingestion to particular <line_type> rows. The same script inserts, updates, and deletes data, and an optional header check prevents loading duplicates.

Flag	What it loads
<load_stat>	STAT data — the core .stat line-type statistics
<load_mode>	MODE object-based output
<load_mtd>	MODE Time Domain (MTD) output
<load_mpr>	Matched-pair (MPR) data
<load_orank>	Observation rank (ORANK) data

Data families the loader recognizes, each gated by a flag in the load specification.

The load entry point is mv_load.sh (often referred to simply as mv_load); it is invoked as mv_load.sh load_spec_file [-index], where the -index flag applies database indexing without loading new data.

Plot families

METviewer’s whole reason for existing is the catalog of verification plots it can draw from the rows in the database. Each plot family expects particular MET line types (METviewer reads the statistics MET already computed — it does not re-run verification). The User’s Guide devotes a chapter to each; the table below collects them.

Family	What it shows	Typical inputs
Series	A statistic traced against an ordered independent variable (e.g. forecast lead time), connecting one value to the next — the workhorse line plot.	any statistic
Bar	Comparisons among discrete categories, with categories on one axis and the measured value on the other.	any statistic
Box (box-and-whisker)	The distribution of a statistic — median, quartiles and spread — across a set of cases.	any statistic
ROC	Receiver Operating Characteristic curve: probability of detection vs. probability of false detection across thresholds — a measure of resolution, unaffected by bias.	PRC / PCT / CTC
Reliability	Conditional bias of probabilistic forecasts: forecast probability vs. observed event frequency; points on the diagonal mean perfectly reliable probabilities.	PCT
Performance diagram	Categorical skill in one view: detection vs. success rate, with radiating lines of equal frequency bias and curves of equal Critical Success Index (CSI).	CTC, NBRCTC, CTS
Taylor diagram	Correlation, variance and centered RMS difference of forecasts against a reference, summarized on a single polar plot.	summary statistics
Contour	A general two-axis plot whose value field is contoured — often statistics over time vs. height, or the difference between two models.	any statistic
Spread-skill	Ensemble diagnostic: spread vs. error of the ensemble mean (RMSE); a perfect spread/skill ratio is 1.	SSVAR
ECLV (economic cost/loss value)	Relative economic value curve for deterministic forecasts across cost-to-loss ratios, derived from a 2×2 contingency table.	ECLV
Equivalence Testing Bounds	Confidence intervals against user-defined tolerance bounds for an equivalence test — useful for checking that code produces equivalent output across environments.	CI-bearing statistics
Scorecard	A grid summarizing the significance and performance of a comparison between two models; XML-only (no GUI). Supports many line types.	CTC, SL1L2, SAL1L2, VL1L2, VAL1L2, PCT, GRAD, NBRCNT, ECNT, NBRCTC, RPS

Plot families documented in the METviewer User’s Guide (chapters 9–20).

Read this against the source

The “typical inputs” column lists the line types the User’s Guide names for each plot where it states them; some families accept a broader range of statistics than shown, and the exact set can shift between METviewer versions. Treat it as a confident starting point, not an exhaustive contract — confirm against the chapter for the release you run.

Figure 2. One worked example — the performance diagram packs detection, success, bias and CSI into a single panel. Closer to the upper-right corner is better.

A typical session

From raw MET output to a finished plot, a METviewer session looks like this:

1. Load the database. Write a <load_spec> XML file pointing at your MET output and database, then run mv_load.sh. Each statistic becomes a row you can query.
2. Open the web app and pick a database and plot type. Choose, say, a series plot against the database you just populated.
3. Build the query in the GUI. Select the dependent variable (Y-axis) and statistic, the series variables (the lines on the plot, e.g. one per model), fixed constraints (thresholds, time periods, domains), and the independent variable (X-axis, e.g. lead hour).
4. Generate. METviewer writes the SQL, pulls the rows, applies any aggregation, and renders the plot. Tabs let you inspect the XML, the SQL, the data, the plot script, and the log.
5. Save the specification. The plot’s XML can be saved and reloaded — and handed to the batch engine.
6. Run it in batch. Feed the saved <plot_spec> to mv_batch plot_spec_file [job_name] to regenerate PNGs unattended, with the same query and settings, alongside the R data and script it used.

Why the batch path matters

Because the GUI and the batch engine share one XML specification, an exploratory plot you made by clicking becomes a reproducible artifact. Encode the database query, aggregation and styling once, and a cron job or CI step can regenerate the figure on every new dataset — no manual clicks, identical output.

Deep dives

Two companion pages go further than this entrypoint.

Plot gallery & how to read them → Each plot family in detail — the line types it needs, what its axes mean, and how to tell a good forecast from a bad one at a glance. Series · ROC · reliability · performance · Taylor · scorecard · more

Database, loading & batch → The load specification, the MySQL/MariaDB schema, and the batch XML engine — everything behind reproducible, scripted plotting. mv_load · load_spec · plot_spec · mv_batch

Where it sits in the ecosystem

METviewer is a hub, not an island. It consumes a database that another component fills, and it leans on shared statistics and plotting libraries for the heavy lifting.

Ecosystem links

METviewer reads the database loaded by METdataio (its METdbLoad component runs mv_load.sh). It shares plotting with METplotpy and aggregation statistics with METcalcpy. If you want the same kind of database-backed verification display in a lighter, web-native package, compare it with METexpress.

---

A derived, human-readable re-presentation — not official documentation. Sources: METviewer User’s Guide — Overview