WRFxctrl-inspired request flow
Launch a new fire simulation with a modern, operator-ready GUI.
This concept focuses on the two core components you described: a user submission workflow backed by Postgres, and a live-updating globe that highlights requested ignition points.
Active requests
8
Avg. queue time
37 min
System health
Operational
Ignition request
Submit a run, then the system admin can approve, queue, or retire it when completed.
Live request globe
Interactive projection showing queued ignition points. Updates every few minutes from the database.
Feature plan & data flow
Suggested implementation plan to keep the pipeline clean and auditable.
- Request intake API (POST `/api/ignitions`) validates fields, writes to Postgres, and returns job id.
- Queue service polls for new requests, triggers wrfxpy jobs, and updates status + log pointers.
- Globe updater reads request table every 2 minutes and streams deltas to the UI.
- Admin controls support cancel + archive actions, plus run metadata and audit trail.
- Notifications alert users on submit, start, completion, and failure.
Postgres core tables
- `ignition_requests` (id, lat, lon, model_type, ignition_time, status, created_at)
- `simulation_runs` (id, request_id, wrfx_job_id, status, logs_url, updated_at)
- `run_events` (id, run_id, event_type, payload, created_at)
Integration notes
This front-end assumes a REST API and Postgres backend. The globe and tables are wired to demo data today, but the JS is ready to swap in real endpoints.
Auth
Recommend SSO or token-based access for admin actions.
Data cadence
UI polls every 2 minutes, with optional websocket for live steps.
Outputs
Link wrfxweb visualization URLs directly from the run table.