Order of sections written by `write_inp`

[dleutnant]

#44 shows a model which runs fine using the swmm5-engine but errors with the SWMM5 GUI.

1. Does the order of sections cause the "List index out of bound(0)" Error?
2. If 1 is true, what is the correct and expected order of the SWMM5 GUI?

[dleutnant]

@maltehenrichs Did you also encounter this error the other day?

[ghost]

Thanks a lot for your fix, if it can help you on p. 274 of the SWMM user manual states that "The sections can appear in any arbitrary order in the input file, and not all sections must be present. Each section can contain one or more lines of data....". In the case, however, the correct order of the sections is as follows (pag. 272-273):

[TITLE]
;;Project Title/Notes

[OPTIONS]
;;Option             Value

[EVAPORATION]
;;Data Source    Parameters

[RAINGAGES]
;;Name           Format    Interval SCF      Source    
     
[SUBCATCHMENTS]
;;Name           Rain Gage        Outlet           Area     %Imperv  Width    %Slope   CurbLen  SnowPack        

[SUBAREAS]
;;Subcatchment   N-Imperv   N-Perv     S-Imperv   S-Perv     PctZero    RouteTo    PctRouted 

[INFILTRATION]
;;Subcatchment   CurveNum              DryTime   

[JUNCTIONS]
;;Name           Elevation  MaxDepth   InitDepth  SurDepth   Aponded   

[OUTFALLS]
;;Name           Elevation  Type       Stage Data       Gated    Route To        

[STORAGE]
;;Name           Elev.    MaxDepth   InitDepth  Shape      Curve Name/Params            N/A      Fevap    Psi      Ksat     IMD     

[CONDUITS]
;;Name           From Node        To Node          Length     Roughness  InOffset   OutOffset  InitFlow   MaxFlow   

[PUMPS]
;;Name           From Node        To Node          Pump Curve       Status   Sartup Shutoff 

[WEIRS]
;;Name           From Node        To Node          Type         CrestHt    Qcoeff     Gated    EndCon   EndCoeff   Surcharge  RoadWidth  RoadSurf   Coeff. Curve

[XSECTIONS]
;;Link           Shape        Geom1            Geom2      Geom3      Geom4      Barrels    Culvert   

[CONTROLS]

[POLLUTANTS]
;;Name           Units  Crain      Cgw        Crdii      Kdecay     SnowOnly   Co-Pollutant     Co-Frac    Cdwf       Cinit     
    
[LANDUSES]
;;               Sweeping   Fraction   Last      
;;Name           Interval   Available  Swept     
                               
[COVERAGES]
;;Subcatchment   Land Use         Percent   

[LOADINGS]
;;Subcatchment   Pollutant        Buildup   

[BUILDUP]
;;Land Use       Pollutant        Function   Coeff1     Coeff2     Coeff3     Per Unit  

[WASHOFF]
;;Land Use       Pollutant        Function   Coeff1     Coeff2     SweepRmvl  BmpRmvl   

[DWF]
;;Node           Constituent      Baseline   Patterns  

[CURVES]
;;Name           Type       X-Value    Y-Value   

[TIMESERIES]
;;Name           Date       Time       Value     

[PATTERNS]
;;Name           Type       Multipliers

[REPORT]
;;Reporting Options

[TAGS]

[MAP]
DIMENSIONS 
Units      

[COORDINATES]
;;Node           X-Coord            Y-Coord           

[VERTICES]
;;Link           X-Coord            Y-Coord           

[Polygons]
;;Subcatchment   X-Coord            Y-Coord           

[SYMBOLS]
;;Gage           X-Coord            Y-Coord 

[ghost]

PROBLEM SOLVED! by ordering the sections of the data.struct before the write_inp function, the GUI does not return the error "List index out bounds (0)"! I simply used the end of the shp_to_inp function code as follows:

section_order <-  c("title", "options", "evaporation", "raingages", "subcatchments",
                    "subareas", "infiltration", "aquifers", "groundwater",
                    "LID_controls", "LID_usage", "junctions", "outfalls", "storage",
                    "conduits", "pumps", "weirs", "xsections", "controls",
                    "pollutants", "landuses", "coverages", "loadings", "buildup",
                    "washoff", "dwf", "inflows", "curves", "timeseries", "patterns",
                    "report", "tags", "map", "coordinates", "vertices", "polygons",
                    "labels", "symbols", "backdrop")

PAULLO <- PAULLO[section_order[section_order %in% names(PAULLO)]]
class(PAULLO) <- "inp"

#controllo la struttura del file convertito
summary(PAULLO)

#salvo il file .inp nella directory di output
write_inp(PAULLO, file.path(out_dir, "PAULLO.inp"))

so at this point, although the manual allows you to insert the sections in any order, you should implement a reordering within the write_inp function so as not to incur this error using the GUI. Thanks always for the availability and help! Enrico

[dickinsonre]

I asked Lew Rossman and this is what he said...

Bob,

The command line executable should be able to handle input sections in any order since it makes two passes through the file as follows:

The first pass counts the number of each type of object that has an ID label and puts the ID label and the object’s index into a hash table. The arrays that hold each object’s data are allocated. The second pass parses the data items for each object and stores them in the object’s data array.

This allows the input sections to be in any order. For example, if the [CONDUITS] section comes before the [JUNCTIONS] section in the file the second pass will be able to look up the start and end junction indexes of the conduit from their ID names in the node hash table.

Things are different for the GUI since it was assumed back in the beginning that the GUI would be processing input files that were saved by the GUI. The GUI saves the data sections in the following order:

 ExportTitle(S);

ExportOptions(S);

ExportFiles(S);

ExportEvaporation(S);

ExportTemperature(S);

ExportRaingages(S);

ExportSubcatchments(S);

ExportSubAreas(S);

ExportInfiltration(S);

Ulid.ExportLIDs(S, Tab);

Ulid.ExportLIDGroups(S, Tab);

ExportAquifers(S);

ExportGroundwater(S);

ExportSnowpacks(S);

//*****************************************************

// These sections must be exported in the order as shown

//******************************************************

ExportJunctions(S);

ExportOutfalls(S);

ExportDividers(S);

ExportStorage(S);

ExportConduits(S);

ExportPumps(S);

ExportOrifices(S);

ExportWeirs(S);

ExportOutlets(S);

//******************************************************

ExportXsections(S);

ExportTransects(S);

ExportLosses(S);

and so on ….

It only makes one pass when reading the file since when one object refers to another object (e.g., the end nodes for a conduit) it can always find the object referred to since it was read in previously. (Some objects, like Curves, are simply stored by name so a Pump can refer to a Pump Curve before the [CURVES] section gets processed.)

The attached modified version of the example1 data set has its [CONDUITS] section appearing before any of the Node sections. It will run OK in the command line executable but will generate a bunch of errors when loaded into the GUI.

Lew

[ghost]

Thank you so much for the detailed answer, the problem is finally clear! Enrico