NCAR
Feature request: Forecast mode for DART
Use case
Discussion today (7/3/2025) at standup. Users want to run filter with no assimilation (evaluate only) and no inflation, to see the the forecast forward operator results.
Is your feature request related to a problem?
It is not clear to users that 'evaluate only' is sufficient for this forecast mode of running the model.
Describe your preferred solution
A 'forecast mode' for DART which sets any settings you need to do this (no inflation, no clamping of the state, evaluate only for obs - don't go into the assimilation loop).
Also, run in forecast this mode but with one ensemble member in filter (no need for PMO? Not quite because PMO creates synthetic obs with error).
Also run filter in filter mode but with one ensemble member (the reasons for this are things like EnOI). Currently you have to have >=2 ensemble members.
Describe any alternatives you have considered
- PMO mode aswell?
Forecast mode, PMO mode, Assimilation mode
Could be command line argument, so it is not another namelist setting. filter --mode forecast filter --mode PMO filter (default assimilation) - You could document how to run in forecast mode, but it is easy to miss one of the settings in input.nml
This would be such a great feature! A very general approach which would allow filter to do: PMO, EnOI, EnKF, hybrid filters, forecast, ensemble forecast, verification, ... Could make a good argument for renaming 'filter' into something more general, e.g., 'dart'
This is prompted by @hkershaw-brown comment in #888.
There is a lot of overlap between them, and the added applications would share a lot of that too, so I agree that it makes sense to put all of these applications into a consistent framework, which can also accommodate new applications that come up.
In that past when I've written code that operates in several related modes,
people have objected and we've divided the modes into separate programs, modules, ...
This can work fine if the shared code can be organized into clear units.
The advantage is that it's clearer what the each program is intended to do and how it does it.
A disadvantage is that there are more programs.
If we go down the road of a single 'dart' program, with a mode argument to it,
I'd argue for there being no default behavior. dart with no arguments should return a list of the modes
and instructions to pick one.
So what is DART's guiding philosophy; unite, divide, both, switch back and forth?
Related; cam-fv and cam-se common code strategy critiqued in #772. They started unified, then they were split, and maybe they will be re-united, or have the common code duplicated in each.