Changes to ZoneBudget?

[porterma]

Back in April Iworte some code to calculate zone budgets:

zbud = ZoneBudget('{}/{}.bud'.format(d, model_name), zones.astype(int))
kstpkper = zbud.kstpkper
ts, spd = zip(*kstpkper)

columbia_in = zbud.get_dataframes(names=['CONSTANT_HEAD_IN']).sum(axis=1)
columbia_out = zbud.get_dataframes(names=['CONSTANT_HEAD_OUT']).sum(axis=1)
columbia = columbia_in.values + columbia_out.values
umatilla = zbud.get_dataframes(names=['RIVER_LEAKAGE_OUT'], zones=['ZONE_3', 'ZONE_4', 'ZONE_5'])
drains = zbud.get_dataframes(names=['DRAINS_OUT'], zones=['ZONE_6', 'ZONE_7'])
storage_in = zbud.get_dataframes(names=['STORAGE_IN']).sum(axis=1)
storage_out = zbud.get_dataframes(names=['STORAGE_OUT']).sum(axis=1)
recharge = zbud.get_dataframes(names=['RECHARGE_IN']).sum(axis=1)

I got a new computer and installed flopy 3.2.9. Now the above code does not work. I now have the following code:

zbud = ZoneBudget('{}/{}.bud'.format(d, model_name), zones.astype(int))
kstpkper = zbud.kstpkper
ts, spd = zip(*kstpkper)

columbia_in = zbud.get_dataframes(names=['FROM_CONSTANT_HEAD']).sum(axis=1)
columbia_out = zbud.get_dataframes(names=['TO_CONSTANT_HEAD']).sum(axis=1)
columbia = columbia_in.values + columbia_out.values
umatilla = zbud.get_dataframes(names=['TO_RIVER_LEAKAGE'], zones=['ZONE_3', 'ZONE_4', 'ZONE_5'])
drains = zbud.get_dataframes(names=['TO_DRAINS'], zones=['ZONE_6', 'ZONE_7'])
storage_in = zbud.get_dataframes(names=['FROM_STORAGE']).sum(axis=1)
storage_out = zbud.get_dataframes(names=['TO_STORAGE']).sum(axis=1)
recharge = zbud.get_dataframes(names=['FROM_RECHARGE']).sum(axis=1)

I do not know the previous version of flopy I was using. It appears there has been a change in ZoneBudget, is that correct?

My issue is that in my previous version of flopy zbud = ZoneBudget('{}/{}.bud'.format(d, model_name), zones.astype(int)) loaded and calculated zone budgets on 36 GB file in less than an hour. Now I have been waiting over 12 hours for the same code to process the same 36 GB cell-by-cell file. Do you have any thought s on what might be causing this? Is it likely something on my end? Is there a more efficient way to use ZoneBudget to get my variables of interest for all time steps and stress periods for large cell-by-cell files?

I'm really just baffled that my code worked efficiently at a previous time and now I am having this issue. Any thoughts would greatly be appreciated. Thanks.

[jbellino-usgs]

Hi Mark, there were a couple of bugfixes submitted for zonebudget after the release of 3.2.9. Are you on the official release? The "develop" branch has the most current version. I haven't noticed any significant changes in the amount of time it takes to process budget files—I have an 8GB budget file that takes about 9 and a half minutes. In fact, I had tried to optimize the code a bit, but wasn't able to make much progress due to a structural roadblock in the code that will take some thinking about.

[porterma]

Jason, Thanks for the quick reply. I installed the develop version of flopy. I am currently running ZoneBudget on a 6 GB file and it has been running for over a half hour. I ran ZoneBudget on a 2 GB file and it took 15 minutes. I guess if you aren't seeing a decrease in performance, then it is likely something on my end. I'll keep digging around to see if I can figure this out. If I wanted to branch and go back to a previous version, do you know how far back I would need to go?

On Wed, May 23, 2018 at 9:15 AM, Jason Bellino notifications@github.com wrote:

Hi Mark, there were a couple of bugfixes submitted for zonebudget after the release of 3.2.9. Are you on the official release? The "develop" branch has the most current version. I haven't noticed any significant changes in the amount of time it takes to process budget files—I have an 8GB budget file that takes about 9 and a half minutes. In fact, I had tried to optimize the code a bit, but wasn't able to make much progress due to a structural roadblock in the code that will take some thinking about.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/modflowpy/flopy/issues/339#issuecomment-391385329, or mute the thread https://github.com/notifications/unsubscribe-auth/ARR0xbLt7x2ZTXn0LKFFeyMbRzGlCeaNks5t1Xz3gaJpZM4UKn2B .

[jbellino-usgs]

Mark, you can try checking out tag 3.2.8, but I would be cautious as I found some bugs related to constant head cells not getting accumulated properly and the use of non-sequential zone numbers. Let me know if you see speed ups with the earlier version.

[porterma]

Jason, I am definitely seeing an performance difference for ZoneBudget between versions 3.2.8 and 3.2.9. In 3.2.8 ZoneBudget processed my 6 GB file in 3.2 minutes and my 36 GB file in 62 minutes. I'll use 3.2.8 for now. I'd be happy to send you my modflow files if you think it will help you further test the issue.

Thanks!

On Wed, May 23, 2018 at 9:52 AM, Jason Bellino notifications@github.com wrote:

Mark, you can try checking out tag 3.2.8, but I would be cautious as I found some bugs related to constant head cells not getting accumulated properly and the use of non-sequential zone numbers. Let me know if you see speed ups with the earlier version.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/modflowpy/flopy/issues/339#issuecomment-391399052, or mute the thread https://github.com/notifications/unsubscribe-auth/ARR0xScSGd-bWPRGanOVoQaB5XtO13foks5t1YXBgaJpZM4UKn2B .

[jbellino-usgs]

Mark, I downloaded your budget and zone files and ran them with the flopy 3.2.8 and 3.2.9 official release tags. The run times were identical on my machine so I'm not sure where things are going awry for you. I'm using numpy version 1.13.1 and pandas version 0.20.3.

[jdhughes-usgs]

@porterma and @jbellino-usgs is this resolved?

[jbellino-usgs]

@jdhughes-usgs I haven't pursued this any further since I wasn't able to duplicate his problem with long processing times.

[jdhughes-usgs]

@jbellino-usgs I am going to close it unless you want it left open

[jbellino-usgs]

@jdhughes-usgs that's fine with me, Joe.