ESCOMP
Make st_archive archive river model+DART output files
Doing data assimilation with CESM+DART generates many new types of output files, which st-archive should archive, assuming they are named according to CESM conventions. Many of the new files will be handled by the esp component code, but others are more closely associated with the geophysical components and should be archived with their files. We've chosen new file names in such a way that this can be done with very small changes to $component/cime_config/config_archive.xml cime/CIME/XML/archive_base.py A second small change is to make st-archive handle compressed files (*.gz). This has no effect on model calculations or existing output.
We don't yet have an interface for doing data assimilation with mizuroute (or MOSART or RTM), but we hope to, and I'm updating the config_archive files for most of CESM's other components, so it seems efficient to do the river model(s) at the same time. I've read that RTM is only used in paleo contexts, and MOSART is deprecated, so I'd like advice about whether to make similar changes to the archiving in either of those.
I developed and tested the changes in a recent (2025-4-22) cesm3.0_alphabranch. I've committed them to a feature branch based on master and pushed it to my fork of mizuRoute. I can include more details here, or in a PR when it's time for that.
I don't have permission to add Assignees, Labels, etc., so I'm hoping that someone will fill those in, or give me permission to.
Cool, thanks @kdraeder. Can you make a PR to mizuRoute with the proposed change? I can see that you'll be adding just a couple new lines to config_archive.xml, but I'm not completely clear what it will look like. If you can create a PR, we can merge it in pretty readily. So your doing a PR would really help here.
And by the way, the same is true for CTSM, and technically if we see one example, we can figure it out for other submodules. But, it also helps if we have someone who creates the PR's for these things.
Oh, and @kdraeder we are in the process of upgrading the license to Apache 2.0, so we'll need you to agree that having your changes under that new license is fine. See #500 for more details on this. We probably will bring this in before the license update, so we need to know about this for sure beforehand. If we bring this in after the change -- we still need you to realize that it's under the terms of the Apache 2.0 license. If you are like me -- you might not care about all this. But, we have to ask...