Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

provide read/write interface to all INP sections #57

Open
43 of 57 tasks
aerispaha opened this issue Jun 19, 2019 · 3 comments
Open
43 of 57 tasks

provide read/write interface to all INP sections #57

aerispaha opened this issue Jun 19, 2019 · 3 comments

Comments

@aerispaha
Copy link
Member

aerispaha commented Jun 19, 2019

Summary

All INP sections that follow the common tabular structure with unique indices as the first column can be read via the swmmio.utils.create_dataframeINP function. However, only a limited number of these sections have been added as properties in the higher-level swmmio.core.inp object.

Add coverage for read/writing all INP sections from the swmmio.core.inp object. INP sections are defined currently as properties with setter/getters in the swmmio.core module here. List of INP sections described here in the OWA SWMM repo.

INP Sections to Cover

  • TITLE
  • OPTIONS
  • FILES
  • RAINGAGES
  • TEMPERATURE
  • EVAPORATION
  • SUBCATCHMENT
  • SUBAREAS
  • INFILTRATION
  • AQUIFER
  • GROUNDWATER
  • SNOWPACK
  • JUNCTIONS
  • OUTFALLS
  • STORAGES
  • DIVIDERS
  • CONDUITS
  • PUMPS
  • ORIFICES
  • WEIRS
  • OUTLETS
  • XSECTIONS
  • TRANSECTS
  • LOSSES
  • CONTROLS
  • POLLUTION
  • LANDUSE
  • BUILDUP
  • WASHOFF
  • COVERAGE
  • INFLOW
  • DWF
  • PATTERN
  • RDII
  • HYDROGRAPH
  • LOADING
  • TREATMENT
  • CURVES
  • TIMESERIES
  • REPORT
  • MAP
  • COORDINATES
  • VERTICES
  • POLYGONS
  • SYMBOLS
  • LABELS
  • BACKDROP
  • TAGS
  • PROFILES
  • LID_CONTROLS
  • LID_USAGE
  • GWF
  • ADJUSTMENT
  • EVENT
  • STREETS (new in SWMM 5.2)
  • INLETS (new in SWMM 5.2)
  • INLET_USAGE (new in SWMM 5.2)
@aerispaha aerispaha added this to the v0.4.0 milestone Aug 5, 2019
@aerispaha aerispaha changed the title provide interface to all INP sections provide read/write interface to all INP sections Aug 5, 2019
@aerispaha aerispaha modified the milestones: v0.4.0, 0.5.0 Apr 23, 2020
@aerispaha aerispaha linked a pull request Dec 4, 2020 that will close this issue
@aerispaha aerispaha removed a link to a pull request Dec 4, 2020
@aerispaha aerispaha removed this from the v0.5.0 milestone Dec 8, 2022
@BuczynskiRafal
Copy link
Collaborator

Hi,
I think I am using swmmio incorrectly or there was some issue in the code at the "Polygons" section.
The event occurs when using the "replace_inp_section" function.
The code I am executing:

def _add_coords(self, subcatchment_id):
    exist = [
        (self.model.inp.polygons["X"][-1], self.model.inp.polygons["Y"][-1]),
        (self.model.inp.polygons["X"][-2], self.model.inp.polygons["Y"][-2]),
        (self.model.inp.polygons["X"][-3], self.model.inp.polygons["Y"][-3]),
        (self.model.inp.polygons["X"][-4], self.model.inp.polygons["Y"][-4]),
    ]
    coords = pd.DataFrame(
        data={
            "X": [exist[0][0], exist[1][0], exist[2][0], exist[3][0]],
            "Y": [exist[0][1] - 5, exist[1][1] - 5, exist[2][1] - 5, exist[3][1] - 5],
        },
        index=[subcatchment_id for _ in range(4)]
    )
    coords.index.names = ['Name']
    self.model.inp.polygons = pd.concat([self.model.inp.polygons, coords])
    replace_inp_section(self.model.inp.path, "[Polygons]", self.model.inp.polygons)

I see that SWMM writes literally "Polygons" in the *inp file, swmmio modifies this name by writing "POLYGONS".

Here is the section I have in the file before executing the code

[Polygons]
;;Subcatchment   X-Coord            Y-Coord           
;;-------------- ------------------ ------------------
S1               777180.000         592590.000        
S1               777180.000         592585.000        
S1               777175.000         592585.000        
S1               777175.000         592590.000        

This is what the section looks like after the first execution of "replace_inp_section"

[POLYGONS]
;;   X          Y         
S1   777180.0   592590.0
S1   777180.0   592585.0
S1   777175.0   592585.0
S1   777175.0   592590.0
S2   777175.0   592585.0
S2   777175.0   592580.0
S2   777180.0   592580.0
S2   777180.0   592585.0

This is what the sections looks like after the second execution of "replace_inp_section"

[POLYGONS]
;;   X          Y         
S1   777180.0   592590.0
S1   777180.0   592585.0
S1   777175.0   592585.0
S1   777175.0   592590.0
S2   777175.0   592585.0
S2   777175.0   592580.0
S2   777180.0   592580.0
S2   777180.0   592585.0

[POLYGONS]
;;   X          Y         
S1   777180.0   592590.0
S1   777180.0   592585.0
S1   777175.0   592585.0
S1   777175.0   592590.0
S2   777175.0   592585.0
S2   777175.0   592580.0
S2   777180.0   592580.0
S2   777180.0   592585.0
S3   777180.0   592580.0
S3   777180.0   592575.0
S3   777175.0   592575.0
S3   777175.0   592580.0

In the code I execute I always use "[Polygons]", after the second execution of "replace_inp_section" the sections are duplicated.
The problem doesn't occur when I change the header to "[POLYGONS]" before executing the code, and in my function I also use "[POLYGONS]"

If I should post this thread in discussions I apologize and please delete.

@aerispaha
Copy link
Member Author

@BuczynskiRafal this is very interesting - I suspect that you've uncovered a bug. That said, I think we should continue this conversation in a new issue. Do you mind creating an issue and restating what you've described above?

If you've found a solution already (e.g. by changing the header to [POLYGONS]), please feel free to submit a pull request with your proposed changes.

Thanks for finding and documenting this issue so clearly!

@BuczynskiRafal
Copy link
Collaborator

I have created a separate issue, at my spare time I will prepare a PR in which I will propose a solution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants