Website: WRF Configuration Studio v1.0.0
A Configuration Problem That Begins Before WRF Ever Runs
The Weather Research and Forecasting Model is extraordinarily flexible, and that flexibility is one of the reasons it has become so important to research, operations, education, regional climate work, hydrology, atmospheric chemistry, fire weather, data assimilation, and many other applications. The same flexibility also creates a practical challenge: long before a forecast or experiment begins, a user has to translate a scientific objective into a large collection of interdependent configuration choices. Where should the domain be located? Which projection is appropriate? What grid spacing should be used? How should nests be placed? Which static geographic data are required? How should time controls, physics, dynamics, boundary conditions, input and output streams, data assimilation, and observation processing be configured? A WRF case can fail before model integration ever starts if those pieces do not fit together.
This is the problem WRF Configuration Studio is intended to address. It is not a replacement for WRF, WPS, WRFDA, or OBSPROC, and it is not an automated meteorologist. Instead, it provides a browser-based environment in which the configuration can be assembled, visualized, inspected, cross-referenced with metadata, and exported before the official programs are run. The emphasis is on transparency. A domain drawn on a map remains connected to the WPS values that describe it. A namelist option remains connected to Registry and documentation information. A compatibility warning is shown to the user rather than silently changing a scientific choice. The configuration remains visible as a scientific object rather than being hidden behind a wizard that decides everything on the user’s behalf.
That approach is especially useful because many real WRF workflows begin with an older namelist, a tutorial configuration, a colleague’s example, or a community-support discussion. Reuse is normal and often productive, but it can also carry settings into a new case without making all of their dependencies obvious. A comma in the wrong place, an array whose length no longer matches max_dom, a nest geometry that does not satisfy a parent-grid relationship, an incompatible physics combination, a missing external file, or a data-assimilation group stored in the wrong output file can cost hours or days. Configuration Studio is designed to move more of that review work to the beginning of the process, when mistakes are cheaper to find.
There is also an educational argument for visualization. WRF users eventually have to understand parameters such as ref_lat, ref_lon, stand_lon, truelat1, truelat2, dx, dy, e_we, e_sn, parent_grid_ratio, and parent_time_step_ratio. Seeing those values change beside an interactive domain makes the relationship between the text file and the geometry easier to grasp. The configuration file is never hidden; the point is to make it more understandable before the user sends it to WPS or WRF.
From WRF Standard Initialization GUIs to a Modern Browser Studio
WRF Configuration Studio has a clear technical lineage. Graphical configuration tools accompanied WRF from relatively early in the model’s history. NOAA Forecast Systems Laboratory work presented a WRF Standard Initialization graphical interface in 2004, with capabilities for domain localization, grid definition, static-surface characterization, boundary-condition preparation, projection controls, path management, validation feedback, and user guidance. Those tools addressed a problem that remains familiar today: many expensive modeling problems are actually configuration problems that occur before the model executable begins.
The WRF Portal and Domain Wizard work continued that graphical tradition. WRF Portal brought configuration, task execution, monitoring, and visualization into an integrated environment, while WRF Domain Wizard focused specifically on WPS domain selection, nesting, namelist.wps generation, execution support, and visualization. Jiří Richter’s browser-based WRF Domain Wizard later became the direct software foundation for the domain-design component that evolved into WRF Configuration Studio. The current project preserves that lineage and attribution while expanding the scope beyond domain generation.
Other projects, including GIS4WRF, demonstrated the value of connecting WRF configuration to modern geospatial interfaces and reproducible map-based workflows. WRF Configuration Studio sits in the same broad family of ideas, but its role is intentionally narrower than a full modeling portal. It does not launch the numerical model. Its focus is the configuration layer that sits between a scientific plan and the official modeling system.
That distinction matters. A full workflow manager has to handle job scheduling, model execution, data movement, monitoring, and postprocessing. Configuration Studio instead concentrates on the part of the workflow where geometry, projection, namelist structure, metadata, and documented compatibility relationships can be made visible. The result is a tool that can run in an ordinary browser on a laptop while the actual WRF simulation may later run on a workstation, server, cloud instance, or high-performance computing system.
How the Studio Is Built
WRF Configuration Studio is distributed as a static browser-based scientific software package. The application is composed of HTML, JavaScript, CSS, runtime JSON catalogs, bundled client-side dependencies, documentation, examples, and local launch utilities. It does not require compilation. For local use, the repository can be served through a lightweight HTTP server, while the public build can be hosted as a static website. This architecture keeps the configuration interface portable and separates it from the computing environment in which WRF itself is installed.
The software architecture reflects the same separation. The browser application contains the map and domain editor, WPS-oriented controls, the namelist.input editor, compatibility and metadata views, workflow presets, and save/export tools. Runtime catalogs provide Registry-derived field structure, documentation, defaults, option metadata, version support, and validated compatibility relationships. Export paths produce namelist.wps, namelist.input, and namelist.obsproc. Those files are then used downstream with the official WRF-family tools.
Registry information is treated as the primary structural source for namelist variables and source-proximate compatibility information. The WRF Users Guide provides secondary validation and explanatory context, while README.namelist and other official sources provide additional support. This source hierarchy is important because a configuration environment should not flatten all sources into one undifferentiated answer. The Registry describes what the software exposes; documentation explains how those choices are intended to be used; the user’s science case ultimately determines which valid configuration is appropriate.
The current codebase also separates large inherited domain-map logic from newer first-party modules that handle complete-catalog namelist editing, runtime metadata, compatibility evaluation, WPS helper behavior, polar-mode routing, and polar geographic overlays. That modular direction is especially visible in the polar implementation, where the browser’s display projection is deliberately kept separate from the WPS projection parameters that define the numerical domain.
Figure 1. WRF Configuration Studio configuration pathway. The browser interface is separated from runtime metadata and from the export paths that produce WRF-family configuration files; the official WRF executables remain external to the Studio.
The Domain Editor: Where Geography Meets the Namelist
The visual center of WRF Configuration Studio is the domain and WPS configuration environment. A user can create a parent domain, add nests, adjust grid dimensions, reposition domains, and inspect the values that will be written into namelist.wps. The map is not treated as decoration. It is a working representation of the relationship between geographic coordinates and the computational grid.
The Studio supports Lambert conformal, Mercator, Polar Stereographic, latitude-longitude, and regional rotated latitude-longitude workflows. The Domain Intelligence controls expose domain geometry, projection parameters, nesting information, and selected WPS-related settings. For Lambert configurations, true-latitude behavior can be reviewed directly. Nest geometry checks help users identify relationships among e_we, e_sn, and parent_grid_ratio before those values reach the official preprocessing tools.
The same interface supports a repeated 360-degree standard map view. When zoomed out, world-map copies repeat across the dateline, allowing domains to be positioned near or across display boundaries without forcing exported longitudes outside the canonical values expected by WRF. This is a browser visualization feature rather than a change to WPS mathematics, but it removes a practical obstacle for dateline-adjacent cases.
Regional latitude-longitude domains receive additional protections. A regional domain is not allowed to expand into a self-overlapping footprint or effectively consume a complete 360-degree span. Rotated latitude-longitude configurations are handled separately through rotated-pole parameters, which prevents the application from conflating rotated regional grids with Polar Stereographic grids.
Figure 2. Standard domain and WPS configuration view from the journal manuscript. The map and Domain Intelligence panel connect interactive domain geometry with the WPS parameters that describe the numerical grid.
Figure 3. Repeated 360-degree standard map view from the journal manuscript. This view supports dateline-adjacent inspection while keeping WRF longitude values canonical.
Polar Visualization: Treating the Arctic and Antarctic as First-Class Domain Design Regions
One of the defining capabilities of WRF Configuration Studio 1.0.0 is its dedicated high-latitude visualization system. Conventional web maps typically rely on Web Mercator. That is useful for most of the populated world, but it cannot display the geographic poles and becomes increasingly distorted at very high latitudes. A WRF user can certainly define a Polar Stereographic domain numerically without a polar browser map, but doing so makes interactive placement and geographic inspection unnecessarily difficult. Configuration Studio addresses that problem by providing dedicated Northern Hemisphere and Southern Hemisphere polar views.
The polar system deliberately separates two concepts that are easy to mix together: the browser coordinate reference system used to display and interact with the domain, and the WPS projection parameters that describe the numerical grid. The Northern polar display uses an Arctic-focused browser projection, while the Southern display uses an Antarctic polar projection. These browser coordinate systems exist to make the map usable. They do not replace WPS map_proj, ref_lat, ref_lon, truelat1, stand_lon, dx, dy, e_we, or e_sn. Export remains a WPS configuration problem, while the browser provides a more appropriate geographic lens through which to inspect it.
This architecture allows a user to begin in the ordinary world-map workflow and later move into a polar workflow without abandoning the domain. A case might begin as a standard regional design or in a Lambert-oriented configuration. If the user selects or accepts a Polar Stereographic configuration, the Studio can route the display into the appropriate hemisphere while preserving the domain and applicable WPS state. The reference latitude acts as the primary hemisphere authority, with the first true latitude available as a fallback when needed. A positive reference latitude routes to the Northern Hemisphere view; a negative reference latitude routes to the Southern Hemisphere view.
That behavior is important because projection choice often evolves during domain design. A scientist may begin by placing a region of interest, examining coverage, or exploring nest geometry before deciding that the final high-latitude case should use Polar Stereographic. The Studio does not force the user to start over merely because the viewing projection changes. The geographic domain state can survive the transition while the interface moves to a map better suited to the new projection.
The dedicated polar displays are focused on high latitudes, using an approximately 50-degree latitude boundary for the polar reference region. Within that region, the Studio supplements the basemap with compact geographic datasets designed for a static browser application. These include coastlines, lakes, national and subnational boundaries where available, populated-place labels, marine geographic labels, graticule lines, and Antarctic ice-shelf reference lines. The cartography is intended to provide physical context for domain placement rather than act as an authoritative scientific dataset.
Label placement is also treated as a usability problem rather than simply drawing every available name. Place and marine labels use collision-aware behavior so that important geographic references remain legible as the user zooms and interacts with the map. The result is a polar view that is useful for Arctic, Antarctic, Southern Ocean, and other high-latitude cases without turning the map into a wall of overlapping text.
The practical value of this capability is straightforward. Polar modeling often involves domains whose center, edges, or nests approach regions that are awkward to interpret in a standard web projection. By allowing the poles themselves to appear in the interactive map, the Studio gives high-latitude WRF users the same kind of visual domain-design workflow that midlatitude users have long taken for granted. The underlying scientific responsibility does not change: the exported namelist.wps still needs to be run through official WPS tools, and preprocessing logs remain the final authority on whether the numerical domain is valid. What changes is the quality of the configuration review before that step.
Key polar design principle: the browser projection is for visualization and interaction; the WPS projection parameters remain the numerical configuration exported to namelist.wps.
Beyond the Map: A Complete-Catalog namelist.input Editor
Domain geometry is only one part of configuring WRF. Once users move into namelist.input, the configuration space expands dramatically. Physics, dynamics, diagnostics, boundary controls, nudging, auxiliary inputs and outputs, chemistry, fire, stochastic options, data assimilation, and specialized extensions can all introduce additional variables and dependencies. WRF Configuration Studio therefore uses a complete-catalog approach: the browser exposes the full set of variables represented in its runtime catalog rather than limiting the interface to a small curated list of common settings.
The editor groups fields by namelist section and keeps advanced options visible. Users can search, expand groups, inspect individual fields, review documentation and source information, and see compatibility messages tied directly to relevant settings. This is intended to reduce a common problem in simplified interfaces: an option that is not shown can be mistaken for an option that does not exist. Configuration Studio instead makes the configuration space discoverable while allowing the user to decide how much of it is relevant to the case at hand.
The editor also receives selected values from the domain and WPS layers. When a field is mastered by domain geometry or WPS, the corresponding domain-derived value takes precedence over a generic catalog default. This cross-layer relationship is especially useful for values such as max_dom and other domain-dependent arrays because it reduces the chance that the visual domain and namelist.input silently drift apart.
A recent example is WRF time_step initialization. When an outer-domain grid spacing is available and the user has not manually entered a time step, the runtime can suggest a starting value based on the commonly used relationship of approximately six times the outer-domain grid spacing in kilometers. A 12-km d01 grid therefore suggests 72 seconds. This value is a starting point, not a scientific guarantee, and the user can override it. The important architectural point is that the WPS/domain layer can inform the namelist editor without taking ownership of the user’s final numerical choice.
Figure 4. Complete-catalog namelist.input editor from the journal manuscript. Namelist groups remain visible rather than being reduced to a small subset of commonly edited options.
Metadata and Compatibility Guidance Without Taking Away Scientific Control
WRF Configuration Studio 1.0.0 includes 184 validated compatibility rules. They are divided into 125 Hard relationships, 35 Workflow relationships, and 24 Soft relationships. The categories are intentionally different. A Hard rule represents a conflict or requirement that should be treated as an error. A Soft rule identifies a relationship where review is recommended but context may matter. A Workflow rule covers conditions involving external files, compile options, domain roles, or other process-level requirements that the browser cannot safely infer on the user’s behalf.
Examples include documented relationships among planetary-boundary-layer and surface-layer schemes, cumulus and land-surface choices, WRFDA radar-assimilation controls, external data requirements, and other companion settings. The compatibility engine reevaluates affected relationships when a user changes relevant values and associates messages with the fields involved. This makes the warning part of the editing context instead of a generic list that the user has to interpret after the fact.
The system is intentionally conservative. It does not attempt to encode every scientifically possible relationship in WRF, and an unflagged combination is not proof that a model configuration will run or that it is appropriate. Scientific suitability depends on scale, region, compiled capabilities, input data, model version, experiment design, and validation goals. The tool’s job is to surface documented relationships where there is strong enough evidence to be useful, not to invent universal meteorological answers.
This user-control-first philosophy extends to export behavior. Required fields can produce a warning when they are blank, but the user can still export a partial configuration when that is intentional. This is valuable for teaching, peer review, configuration development, and specialized research cases. The software distinguishes between ‘this is incomplete’ and ‘you are forbidden from saving it.’ That is a subtle but important choice for scientific software.
Minimize image
Edit image
Delete image
Figure 5. Required-field warning from the journal manuscript. The Studio identifies missing selections before export while still allowing an intentional partial configuration.
WRFDA and OBSPROC in the Same Configuration Environment
Data assimilation adds another layer of complexity because WRFDA uses many namelist.input groups that ordinary WRF users may rarely encounter. WRF Configuration Studio keeps those groups visible rather than separating them into an artificial configuration format. WRFDA settings, including wrfvar groups and supporting structures such as observation, radar-assimilation, and perturbation controls, remain part of namelist.input because that is where WRFDA expects them.
Version 1.0.0 also includes workflow presets that can populate related fields as starting points. The preset set covers conventional-observation 3DVAR, FGAT, conventional-observation 4DVAR, 4DVAR radar, 4DVAR precipitation assimilation, WRFDA-Chem surface observations, and three OBSPROC output modes. A preset is not a locked recipe. Once applied, every resulting field remains available for review and modification.
OBSPROC is handled differently because it has its own canonical output file. The Studio presents OBSPROC records alongside related configuration material for convenience, but during export those internal records are converted to the expected record1 through record9 groups and written to namelist.obsproc. WRF and WRFDA groups remain in namelist.input, and WPS fields remain in namelist.wps. The combined interface therefore does not blur the boundaries of the actual files consumed by the official programs.
This is one of the larger ideas behind the Studio: related configuration spaces can be brought together visually without changing the file contracts of the WRF ecosystem. The browser can help a user understand relationships among WPS, WRF, WRFDA, and OBSPROC while still exporting each configuration to the location and format expected downstream.
Who Is This For?
WRF Configuration Studio is intentionally broad because WRF itself is broad. A new user can use the map to understand how WPS geometry relates to a namelist. An experienced researcher can use the complete-catalog editor to inspect less common variables without losing access to source metadata. A data-assimilation user can work with WRFDA groups and OBSPROC records in the same interface while preserving the correct export file boundaries. An instructor can use the Studio to demonstrate how projection, nesting, grid spacing, and namelist structure fit together before students move to a Linux or HPC environment.
High-latitude users gain a particularly practical benefit from the polar views. Arctic, Antarctic, Southern Ocean, polar climate, sea-ice-adjacent, and other specialized applications can be inspected in a map that actually represents the pole. Midlatitude users retain the standard Lambert and Mercator workflows. Dateline-adjacent users can work in a repeated 360-degree world view. Regional latitude-longitude users gain geometry safeguards and rotated-grid support.
The separation between configuration and execution also means the Studio is useful when the person designing a case is not sitting on the machine that will run it. A configuration can be prepared in a browser on Windows, macOS, or Linux and then moved to the computing environment where WPS and WRF are installed. No specialized hardware is required for the configuration step.
The Larger Goal
WRF will remain scientifically complex because the atmosphere is complex and because the model is designed to serve many communities. A tool that tries to remove that complexity by hiding it would eventually become misleading. WRF Configuration Studio takes the opposite approach. It organizes the complexity so that more of it can be seen before a run begins.
That philosophy connects every major feature. The map makes domain geometry visible. Polar modes make high-latitude geometry visible. The repeated world map makes dateline behavior visible. The complete-catalog editor makes advanced namelist fields visible. Registry and documentation panels make provenance visible. Compatibility messages make documented relationships visible. WRFDA and OBSPROC support make file boundaries visible. Suggested values make cross-layer relationships visible without removing the user’s ability to override them.
The practical goal is not to guarantee a successful forecast. It is to reduce preventable structural errors, improve configuration transparency, support teaching and review, and allow scientists to spend more time on the meteorology and less time untangling avoidable setup problems. That is the role of a configuration studio: not to replace the model, but to make the path into the model clearer.
WRF Configuration Studio version 1.0.0 is connected to the manuscript titled “WRF Configuration Studio: A Browser-Based Configuration Environment for WRF Domains, Namelists, Data Assimilation Workflows, and Registry Metadata.” The public website and source repository make the software available for testing, transparency, reproducibility, and community feedback.
Software Access
Hosted application
1.0.0
License
GNU General Public License version 3.0 (GPL-3.0)