William.Hatheway
Well-known member
WRF Is Not Finished: What the GitHub Backlog Says About WRF, MPAS, and What Comes Next
As of August 18, 2026, WRF had 188 open issues and 32 open pull requests. WPS had 35 issues and 12 PRs. OBSGRID had six issues and two PRs. The separate WRFDA repository had four issues and no PRs, but that number is misleading because modern WRFDA development is inside the main WRF source tree.
Those numbers do not mean WRF has 188 confirmed scientific bugs. GitHub issues include bug reports, questions, enhancement requests, build failures, and reports that still need to be reproduced. What matters is what is showing up in the queue.
That is why I do not consider WRF finished software. It is mature software, but those are not the same thing. Physics schemes are still being corrected. Parallel behavior is still being investigated. New compilers and architectures still expose old assumptions. If I am starting a long WRF experiment, I want to know whether there is already an open issue involving the exact physics package, compiler, or workflow I plan to use.
WPS tells a different story. A lot of its problems come from the world around it changing. DWD, ECMWF, ERA5, GRIB2 packing, Jasper, compiler toolchains, processor architectures, and data sizes keep changing. A workflow can work for years and then fail because an upstream provider changes a format. Current WPS work includes newer compiler and AArch64 support, large-file handling, ERA5/IFS updates, CMake fixes, and attempts to modernize ungrib. That is not glamorous work, but it matters for automated and reproducible forecasting systems.
OBSGRID is much smaller, but it shows another problem. Smaller utilities can get left behind while the main model gets most of the attention. Its open queue includes crashes, sorting problems, installation issues, and compiler support. If your workflow requires OBSGRID, it does not matter that WRF itself compiles perfectly if the supporting tool does not.
NSF NCAR itself says MPAS currently contains only a small fraction of the capabilities available in WRF, even though more capabilities are expected to move over with time. That point matters because WRF is much more than wrf.exe. Decades of work have created WRFDA, WRF-Chem, WRF-Hydro, WRF-Fire, WPS, OBSGRID, moving nests, urban applications, specialized physics, chemistry, hydrology, fire-weather workflows, operational cycling, and a huge amount of community code and knowledge.
MPAS is building out many of these areas, and it already has important Earth-system and data-assimilation paths. But demonstrating a capability is not the same thing as having a mature, validated, documented, and widely used replacement for an established WRF workflow.
The same argument applies to coupling. MPAS has atmosphere, ocean, sea-ice, and broader Earth-system development, which is important. But WRF has had decades for specialized chemistry, hydrology, fire, data assimilation, urban modeling, nesting, and operational workflows to mature. MPAS is not yet a one-for-one replacement for all of that.
I also want to be clear about something else: NSF NCAR is not currently saying WRF is about to be shut down. NCAR says it is not planning to retire WRF or step away from support and maintenance in the foreseeable future. At the same time, development resources are increasingly focused on MPAS, and NCAR has said community feedback should help guide future decisions.
If you use WRF-Chem, what is still missing in MPAS? If you use WRF-Hydro, what coupling and workflow features are required? If you depend on WRFDA or WRF-DART, what must be mature before you can move? What replaces moving nests for hurricane workflows? What happens to fire-weather applications, urban physics, observation processing, specialized microphysics, restart and cycling systems, or the community-developed tools that have no obvious migration path?
Those are not complaints. They are requirements. If MPAS already does everything you need, say that too. If it does not, be specific about what is missing, why it matters scientifically, who uses it, and what would have to exist before migration is realistic.
I do not think WRF should be preserved forever just because it is familiar, and I do not think MPAS should be rejected because it is different. The transition should be based on capability. If MPAS eventually provides the physics, coupled systems, data assimilation, preprocessing, operational reliability, documentation, and validation history users need, researchers will move because it makes sense.
What I do not want to see is WRF support decline faster than those replacement capabilities mature. WRF represents decades of work by NCAR, NOAA, universities, government agencies, operational centers, private companies, and individual researchers. There is too much scientific infrastructure tied to it to assume that everything can simply be moved later.
So my challenge to the WRF and MPAS community is simple: go through your workflow and ask what you can do in WRF today that you cannot yet do, or cannot yet do reliably, in MPAS. Then put that on the forum. Bring it to workshops. Open focused GitHub issues where appropriate. Make the requirements visible.
Do not wait until somebody announces the end of WRF to start listing everything that still depends on it. NCAR says WRF is not being retired in the foreseeable future. Good. That means there is still time to decide what needs to be preserved, ported, redesigned, or replaced before any future shuttering decision is made.
The community needs to have that conversation now.
The GitHub backlog
I have been going through the official NSF NCAR GitHub repositories for WRF, WPS, WRFDA, and OBSGRID, including the open issues and pull requests. I think more WRF users should do this because the issue tracker gives a much better picture of where the modeling system stands than simply looking at the latest release number.As of August 18, 2026, WRF had 188 open issues and 32 open pull requests. WPS had 35 issues and 12 PRs. OBSGRID had six issues and two PRs. The separate WRFDA repository had four issues and no PRs, but that number is misleading because modern WRFDA development is inside the main WRF source tree.
Those numbers do not mean WRF has 188 confirmed scientific bugs. GitHub issues include bug reports, questions, enhancement requests, build failures, and reports that still need to be reproduced. What matters is what is showing up in the queue.
WRF is mature, not finished
Recent WRF reports include OpenMP race conditions, non-reproducible behavior, uninitialized variables, urban-model problems, microphysics corrections, WRFDA build problems, and land-surface fixes. The pull-request queue also includes active work on NSSL-MP, WDM7, UDM, NTU microphysics, Noah-MP, the RUC LSM, PBL physics, compiler support, CMake, and WRFDA. Several are already tagged for a possible WRF 4.8.1 maintenance release.That is why I do not consider WRF finished software. It is mature software, but those are not the same thing. Physics schemes are still being corrected. Parallel behavior is still being investigated. New compilers and architectures still expose old assumptions. If I am starting a long WRF experiment, I want to know whether there is already an open issue involving the exact physics package, compiler, or workflow I plan to use.
WPS tells a different story. A lot of its problems come from the world around it changing. DWD, ECMWF, ERA5, GRIB2 packing, Jasper, compiler toolchains, processor architectures, and data sizes keep changing. A workflow can work for years and then fail because an upstream provider changes a format. Current WPS work includes newer compiler and AArch64 support, large-file handling, ERA5/IFS updates, CMake fixes, and attempts to modernize ungrib. That is not glamorous work, but it matters for automated and reproducible forecasting systems.
OBSGRID is much smaller, but it shows another problem. Smaller utilities can get left behind while the main model gets most of the attention. Its open queue includes crashes, sorting problems, installation issues, and compiler support. If your workflow requires OBSGRID, it does not matter that WRF itself compiles perfectly if the supporting tool does not.
Why MPAS is not a full replacement yet
The bigger discussion, though, is MPAS. I am not against MPAS. MPAS has major advantages, especially its variable-resolution mesh and global-to-regional framework. It is clearly where a lot of future development is going. But being newer does not automatically make it a complete replacement for the WRF ecosystem.NSF NCAR itself says MPAS currently contains only a small fraction of the capabilities available in WRF, even though more capabilities are expected to move over with time. That point matters because WRF is much more than wrf.exe. Decades of work have created WRFDA, WRF-Chem, WRF-Hydro, WRF-Fire, WPS, OBSGRID, moving nests, urban applications, specialized physics, chemistry, hydrology, fire-weather workflows, operational cycling, and a huge amount of community code and knowledge.
MPAS is building out many of these areas, and it already has important Earth-system and data-assimilation paths. But demonstrating a capability is not the same thing as having a mature, validated, documented, and widely used replacement for an established WRF workflow.
DART and coupling matter
DART is a good example. One correction I want to make is that DART, the Data Assimilation Research Testbed, is an NSF NCAR system, not a NASA system. However, DART has a mature WRF interface, and NASA-supported research has used WRF-DART and WRF-Chem/DART. That shows how far WRF has spread beyond the core model itself. Replacing WRF means replacing or migrating those interfaces too, not just producing a new atmospheric solver.The same argument applies to coupling. MPAS has atmosphere, ocean, sea-ice, and broader Earth-system development, which is important. But WRF has had decades for specialized chemistry, hydrology, fire, data assimilation, urban modeling, nesting, and operational workflows to mature. MPAS is not yet a one-for-one replacement for all of that.
I also want to be clear about something else: NSF NCAR is not currently saying WRF is about to be shut down. NCAR says it is not planning to retire WRF or step away from support and maintenance in the foreseeable future. At the same time, development resources are increasingly focused on MPAS, and NCAR has said community feedback should help guide future decisions.
The community needs to speak up now
That is exactly why the WRF and MPAS community needs to speak up now. The official forum should not only be a place to ask why real.exe crashed or which namelist option to use. Forum members should also be documenting what they actually need from the next generation of the modeling system.If you use WRF-Chem, what is still missing in MPAS? If you use WRF-Hydro, what coupling and workflow features are required? If you depend on WRFDA or WRF-DART, what must be mature before you can move? What replaces moving nests for hurricane workflows? What happens to fire-weather applications, urban physics, observation processing, specialized microphysics, restart and cycling systems, or the community-developed tools that have no obvious migration path?
Those are not complaints. They are requirements. If MPAS already does everything you need, say that too. If it does not, be specific about what is missing, why it matters scientifically, who uses it, and what would have to exist before migration is realistic.
I do not think WRF should be preserved forever just because it is familiar, and I do not think MPAS should be rejected because it is different. The transition should be based on capability. If MPAS eventually provides the physics, coupled systems, data assimilation, preprocessing, operational reliability, documentation, and validation history users need, researchers will move because it makes sense.
What I do not want to see is WRF support decline faster than those replacement capabilities mature. WRF represents decades of work by NCAR, NOAA, universities, government agencies, operational centers, private companies, and individual researchers. There is too much scientific infrastructure tied to it to assume that everything can simply be moved later.
So my challenge to the WRF and MPAS community is simple: go through your workflow and ask what you can do in WRF today that you cannot yet do, or cannot yet do reliably, in MPAS. Then put that on the forum. Bring it to workshops. Open focused GitHub issues where appropriate. Make the requirements visible.
Do not wait until somebody announces the end of WRF to start listing everything that still depends on it. NCAR says WRF is not being retired in the foreseeable future. Good. That means there is still time to decide what needs to be preserved, ported, redesigned, or replaced before any future shuttering decision is made.
The community needs to have that conversation now.
Last edited: