I started with a simple question: if the US Environmental Protection Agency makes its models freely available, why does preparing an air dispersion study still involve moving between multiple programs, data sources and file conversions? Why could the whole journey not be managed in one place? That question became AERMOD Studio, and after months of development the idea became a platform that could be accessed through a browser.
The difficulty was bigger than running the model
Anyone working in air dispersion knows that pressing Run is only one part of the job. Before that, we need source characteristics and emission rates, surface and upper-air meteorology, terrain and land cover. We then prepare and check the inputs. After execution, we still have to organise results, maps and the report.
Each stage used to send me to a different program or website. Repeating the sequence made project organisation a substantial task in its own right. I was not trying to create a new mathematical model or alter AERMOD. I wanted to bring its supporting tools and datasets into a coherent workflow, from project creation to delivery.
One interface for the complete journey
My aim was for users to start in a browser and follow a connected path through data preparation, processing, execution and results. They would not have to install a collection of programs or purchase commercial interface licences to try the workflow I provided. Browser access also made the platform available across different devices, including a phone for tasks supported by the interface.
One essential input must still come from the user: a defensible Emission Rate for each source. Organising the surrounding workflow does not automatically establish the correct emission rate, units or source characteristics. That evidence is the starting point on which the remaining stages depend.
Connecting the data sources
For meteorology, I provided access to surface station observations through GHCNh and upper-air data through IGRA. These offer extensive international coverage, but selecting a representative station and checking its record remain technical decisions rather than a matter of choosing the closest name on a map.
I also connected the workflow to SRTM elevation data and ESA WorldCover land cover. My launch post referred to the terrain source as SRTM30. The actual product and resolution should be recorded in each project: that name does not automatically identify a 30-metre grid. Bringing data closer to the user should not hide what the data represent.
The processors in the announced version
The version described in my launch post used the following EPA releases. These numbers document that implementation; they are not a claim that every later deployment will use the same versions:
AERMET v26135 for meteorological processing; AERSURFACE v26135 for relevant surface characteristics; AERMAP v24142 for terrain processing; BPIPPRM v04274 for building-effect inputs; and AERMOD v26135 for dispersion calculations.
Combining the tools in one interface preserves a useful distinction: the platform manages files and dependencies, while each processor retains its own purpose, inputs and outputs. Those files belong in the project record. EPA provides documentation for reviewing the modelling system and its processors. [1][2]
Why the experience follows a sequence
I designed the workflow so that each stage depends on completion of the preceding requirements. The platform checks that necessary inputs are available before allowing the user to move on, rather than leaving a missing file or incomplete setting to emerge at the end.
For a learner, this makes the connections between meteorology, terrain, sources, receptors and the AERMOD run more visible. For repeated project work, it also makes progress easier to follow. Neither benefit removes the need to judge whether the inputs are suitable or to interpret the result critically.
What users receive after a run
The announced outputs included KMZ files for Google Earth, PDF outputs and a Word report bringing together project information, inputs and results. I also made the original Input and Output files available so users could retain them or include them in the study handover.
Preserving the original files was an important part of the concept. A project should not end with a coloured image or a value in an interface. Reviewers need to see what went into the calculation, and the user may need to revisit a scenario or update the evidence later.
Accounts, privacy and project administration
I gave each user an account and associated projects with that account, with the design intention that other users would not be able to access them. In the original explanation, I distinguished administrative platform management, including deletion where necessary, from the user’s ownership of project content.
That distinction matters for a cloud service handling client studies. Exact administrative access rights, data retention and privacy arrangements should be established in the platform’s actual policy. A short launch description should not be stretched into a broader security guarantee than has been verified.
The role of cloud computing
Cloud computing supplied the resources I needed: servers, operating systems, development tools, databases, storage, execution and access-management services. Having those resources in a connected environment made it easier to implement the processing chain and generate deliverables than I had initially expected.
Operating the platform also costs money. At launch I therefore announced trial limits of three projects per user, up to three sources and a 5,000-receptor grid, with point sources supported in that version. These figures describe the version in the original post; coverage and usage conditions may change as development continues.
Making the workflow accessible while keeping the science visible
Alongside the launch, I announced a session introducing air pollution modelling and platform use. My intention was to make the tools and data available through an understandable sequence, so users could see how the stages connect rather than spend most of their time finding and moving files.
For me, AERMOD Studio is a way to organise access to an established modelling system and preserve reviewable deliverables. A simpler interface does not make the environmental question or data quality less important. It creates more room to concentrate on them.
References & original writing
Adapted and expanded from the author’s LinkedIn writing. Technical references are listed below.
