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

OOPNET #20

Open
goanpeca opened this issue Aug 28, 2016 · 8 comments
Open

OOPNET #20

goanpeca opened this issue Aug 28, 2016 · 8 comments

Comments

@goanpeca
Copy link

goanpeca commented Aug 28, 2016

I was just surfing around and found this OOPNET

Has this been considered as an option for epanet moving forward?

@samhatchett
Copy link
Member

yes, @eladsal has been in communication with the authors.

as for your question about moving epanet forward, are you asking specifically if this dev team has considered re-writing the engine in python (as the authors of the referenced paper suggest), or are you asking something else?

@goanpeca
Copy link
Author

goanpeca commented Aug 28, 2016

Hi @samhatchett, sorry I feel like am trolling this org with all my questions (I am just very happy this org exists :-) and I am looking forward to organizing how I can contribute, that is why I have been poking here and there).

as for your question about moving epanet forward, are you asking specifically if this dev team has considered re-writing the engine in python (as the authors of the referenced paper suggest), or are you asking something else?

My question was more like, would the authors of that paper be willing to open their work (maybe I misread, but they seem to have work already done in an internal git repo?) maybe as part of this organization in order to further develop OOPNET in python (as an alternative to EPANET-DEV?).

I guess rewriting the engine in python would not make a lot of sense, if there is already work in that direction (this is something I have always wanted to explore, that is why/how I found the paper I guess...). But probably I am just thinking aloud. With numba and the like having an engine in python that is close to a C engine (in terms of speed) but written in python would definitely make development much much easier (even if it is never as fast in terms of running the actual engine).

That paper touched a lot of ideas I had many years ago, even writing a GUI in Qt (with PyQt) for epanet (and swmm). I think there was some work on that already (with Qt in C++, I guess?), but then again PyQt is soooo much easier to code. I have quite some XP with PyQt from all the work I have done with Spyder.

@goanpeca
Copy link
Author

goanpeca commented Aug 28, 2016

I was very curious about OO engines after some (very) minimal exposure I had with http://research.ncl.ac.uk/noah/ when I was doing my MSc in hydroinformatics.

@goanpeca
Copy link
Author

Another question, is there an epanet-dev-python? Python bindings for the this new version? If not that is definitely something I would be more than happy to work with :-)

@samhatchett
Copy link
Member

@goanpeca : thanks for the suggestion. This project is in a state of flux regarding the OO paradigm (see #13 for more conversation on this) - as you might pick up on from that thread, allowing third-parties to use this code as OO was never a design goal, however the code is internally structured with an OO flavor. I have suggested that we evolve the code into a more traditional class library type of package, with separate utilities for loading/saving/etc. Still anticipating more feedback on this idea from the community, but I feel that it's both practical and inevitable.

Given all of that, it's probably a bit early to put too much work into Python bindings (unless we standardize on SWIG proxy classes for this purpose) since the public API is C-only and subject to change. Would you agree with that approach?

@goanpeca
Copy link
Author

Hi @samhatchett sure that makes sense.

Given all of that, it's probably a bit early to put too much work into Python bindings (unless we standardize on SWIG proxy classes for this purpose) since the public API is C-only and subject to change. Would you agree with that approach?

Yeah, SWIG would be the way for it

@qiujiaping
Copy link

Where can I download this oopnet

@DanielHabenicht
Copy link

Seems like it is opensourced here: https://github.com/oopnet/oopnet

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

No branches or pull requests

4 participants