How swmmr reads and writes SWMM files

Dominik Leutnant

2019-03-18

What is a inp file?

US EPA’s Stormwater Management Model (SWMM) stores all relevant data in the so called *.inp file. This plain ASCII coded file contains information about model structure (e.g., subcatchments) and model options (e.g. flow units, flow routing, simulation period). The file itself is structured into sections which starts and ends with opening and closing squared brackets ([, ]).

Which inp sections are allowed?

Currently, 51 sections are recognized. These are:

#>  [1] "aquifers"      "backdrop"      "buildup"       "conduits"     
#>  [5] "controls"      "coordinates"   "coverages"     "curves"       
#>  [9] "dividers"      "dwf"           "evaporation"   "events"       
#> [13] "files"         "groundwater"   "hydrographs"   "iiflows"      
#> [17] "infiltration"  "inflows"       "junctions"     "labels"       
#> [21] "landuses"      "lid_controls"  "lid_usage"     "loadings"     
#> [25] "losses"        "map"           "options"       "orifices"     
#> [29] "outfalls"      "outlets"       "patterns"      "pollutants"   
#> [33] "polygons"      "profiles"      "pumps"         "raingages"    
#> [37] "report"        "snowpacks"     "storage"       "subareas"     
#> [41] "subcatchments" "symbols"       "tags"          "temperature"  
#> [45] "timeseries"    "title"         "treatment"     "vertices"     
#> [49] "washoff"       "weirs"         "xsections"

What happens on read_inp?

swmmr’s inp parser walks through the file and separates the file into section blocks. A section is recognized if its name is enclosed by squared brackets. Each section has an own parsing scheme, which especially holds header information (i.e. colnames). The result of a parsed section is always a tibble, which subsequently leads to a list of tibbles for the entire inp file.

What happens on write_inp?

The benefit of parsing the inp file into a list of tibbles becomes clearly if a new inp file has to be written to disk: swmmr’s inp writer just walks through the inp object and writes each tibble (whitespace separated) into one file. However, column names of sections are not written to clearly indicate the origin of file (i.e. swmmr). If column names are really required, the new generated inp file can still be opened with SWMM and saved back with the GUI.

What is a rpt file?

After each SWMM simulation run, a report file (*.rpt) is generated containing status reports and result summaries.

Which rpt sections are parsed?

Currently, 34 report sections are recognized. These are:

#>  [1] "Element Count"                    "Pollutant Summary"               
#>  [3] "Landuse Summary"                  "Raingage Summary"                
#>  [5] "Subcatchment Summary"             "Node Summary"                    
#>  [7] "Link Summary"                     "Cross Section Summary"           
#>  [9] "Analysis Options"                 "Runoff Quantity Continuity"      
#> [11] "Runoff Quality Continuity"        "Groundwater Continuity"          
#> [13] "Flow Routing Continuity"          "Quality Routing Continuity"      
#> [15] "Highest Continuity Errors"        "Time-Step Critical Elements"     
#> [17] "Highest Flow Instability Indexes" "Routing Time Step Summary"       
#> [19] "Subcatchment Runoff Summary"      "LID Performance Summary"         
#> [21] "Subcatchment Washoff Summary"     "Node Depth Summary"              
#> [23] "Node Inflow Summary"              "Node Flooding Summary"           
#> [25] "Outfall Loading Summary"          "Link Flow Summary"               
#> [27] "Conduit Surcharge Summary"        "Link Pollutant Load Summary"     
#> [29] "Pumping Summary"                  "Groundwater Summary"             
#> [31] "LID Control Summary"              "Node Surcharge Summary"          
#> [33] "Storage Volume Summary"           "Flow Classification Summary"

What happens on read_rpt?

Report files are read in the same manner like inp files. The output will be a tibble for each summary, which results as a list of tibbles for a single rpt file.