Raingage section awkward when many gages using same input file

[MitchHeineman]

As radar-derived rainfall data becomes ubiqitous (e.g. https://www.nssl.noaa.gov/projects/mrms), it is becoming more practical to have one rain gage per subcatchment. SWMM handles this properly, but the [Raingages] section becomes awkward and unwieldy, as the user must specify hundreds or thousands of nearly identical input lines specifying the same input file, e.g.

[RAINGAGES]
;;Name Format Interval SCF Source
;;----------- --------- ------ -------------
BARA_01_C VOLUME 1:00 1 FILE "QPE.dat" BARA_01_C IN
BARA_02_C VOLUME 1:00 1 FILE "QPE.dat" BARA_02_C IN
BARA_03_C VOLUME 1:00 1 FILE "QPE.dat" BARA_03_C IN
...

It seems it would not be hard to configure the model with an option to read many rainfall timeseries for a single master "gage". This would work immediately if there was an option that told the program to read a multi-gage file and assume the same characteristics for all the timeseries found within.

Perhaps this belongs as a discussion...

[MdoubleDash]

This would be a great .

[cbuahin]

This sounds like an enhancement that could be implemented in the near term if we come up with a solution that actually reduces the burden. I think this issue is along the lines of #31, so let us keep it here for now. We could come up with a master "gage" that reads a multi station rain gage file. However, the real burden of assigning the hundreds to thousands of resulting stations to their respective sub-catchments will remain unless we consider the geospatial frame. We could map the rain gages to sub-catchments by their names but that seems like an inelegant solution to me as there is a lot that goes into sub-catchment naming and limiting it to rain gage name/station id seems inappropriate.

Overall, we are thinking about an explicit geospatial frame for SWMM, which might make it possible to automatically distribute/assign the rain gages via various user specified methods like nearest neighbor, natural neighbor, IDW, etc., and reduce the duplicative effort of specifying the same file over and over again. We are also looking into pre-caching some of the timeseries values in memory ahead of time instead of the line by line reading to improve performance.

[MitchHeineman]

Thanks for the thoughtful response. It's obviously a balancing act to prioritize short-term vs. long-term improvements. I'm also considering using the binary rainfall interface file in my model, although that does not preclude the need to include the long, repetitive [Raingages] input section. Funny thing is, I was only marginally concerned about this until I hit a problem which has since been identified by Tiehong as issue #165