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

to_shapefile() / reference.py::get_vertices() speed issue #69

Closed
ndeeds opened this issue Dec 1, 2015 · 2 comments
Closed

to_shapefile() / reference.py::get_vertices() speed issue #69

ndeeds opened this issue Dec 1, 2015 · 2 comments

Comments

@ndeeds
Copy link

ndeeds commented Dec 1, 2015

Love the "to_shapefile" functionality. Would like to suggest a fix that improved write time for me on a 362, 368 grid from 26m:31s to 1m:50s . My fix is probably a dumb approach, but I think the issue is real.

For large grids it appears to spend a lot of time in flopy_io.py::write_grid_shapefile() in the loop just prior to wr.save(filename), which I traced to the reference.py::get_vertices() call:

image

It appears to me (I am a python novice so forgive any stupidity that follows) that the reference.py::get_vertices() call that occurs over nrow by ncol is triggering an unnecessary recreation of the xgrid/ygrid properties every time it gets called:

image

I verified that this line (line 296) is the slow part of the method call. My ignorant way of fixing this was just to check whether xgrid/ygrid had been created during the property call, and to skip their recreation:

image

@langevin-usgs
Copy link
Contributor

I believe this was fixed on the develop branch, using the same approach that you are suggesting. Can you give that a try? We are working to get a release out sometime this week, if possible.

On develop branch in reference.py:

@property
def xgrid(self):
    if self._xgrid is None:
        self._set_xygrid()
    return self._xgrid

@property
def ygrid(self):
    if self._ygrid is None:
        self._set_xygrid()
    return self._ygrid

@ndeeds
Copy link
Author

ndeeds commented Dec 1, 2015

Well, that will teach me to check dev before spouting off. You are right, dev gives an identical result in terms of speed as my (actually, my colleague Marius') proposed change. At least it gave us an excuse to dig into the code a bit... =)

@ndeeds ndeeds closed this as completed Dec 1, 2015
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

2 participants