My PhD advisor Dr. Jay Lund recently noted that much of what we do in our post-PhD research career is to tackle those challenges we faced as a PhD student. True words from him, as always. In my case, I struggled through building a simulation model of not just one, but 13 watersheds in the Sierra Nevada. Now, those 13 models were completely independent. While computing them efficiently, in parallel, and integrating results was probably the most important challenge (I used parallel virtual machines, as hinted at in our first blog post), simply managing them efficiently was also challenging. Oh how great it would have to group, view and edit them together as one, nearly seamlessly, in a modern mapping environment.
Because OpenAgua uses a single database approach – made much easier with the network-centric Hydra Platform and its data organization scheme – we can solve both of the latter issues relatively easily. This is demonstrated by two screenshots that I shared recently with colleagues, and which include examples from my own PhD work* (the 3-letter codes refer to specific watersheds in the Sierra Nevada, with MER = the Merced River watershed for reference; the Merced River flows through Yosemite Valley and is relatively un-regulated).
Being able to organize multiple networks in the same space with network thumbnails, as in Fig. 1, is very useful. However, this alone is not what drives this effort (after all, what’s the difference between this and storing model files in a folder on you computer?).
Where this will become incredibly powerful is when we can efficiently link multiple networks within a single modeling framework. We should be able to easily pass data between networks, share datasets between networks, etc. And this is not limited to water networks: we can (eventually) have multiple kinds of networks within the same modeling space: water networks, energy networks, food networks, etc.
Fig. 2 shows how we can now combine these multiple networks into a single mapping space. This is useful for visualization, of course, but also vastly increases modeling efficiency. One can quickly switch between different “active” networks for editing, and also toggle the visibility of other networks in the same project.
In this example, having the ability to view/edit adjacent networks in the same space is extremely useful. This will become even more useful when dealing with multiple kinds of networks. Imagine being able to view/edit both water and energy networks in the same workspace. Combine this with the planned ability to efficiently link networks in the modeling space, as mentioned above, and you should begin to realize the power of what we are doing. (It’s not that one cannot do this already – we are just making it trivial to do so).
None of this is to say we are where we want to be in terms of linking networks, or even computing. Even though we can technically model these systems in OpenAgua, the computing infrastructure is currently rudimentary at best, and the ability to link models simply doesn’t exist. But even being able to view/edit unlinked networks together in the same GUI is an incredible first step.
*Yes, OpenAgua can import WEAP models. This functionality is a work-in-progress, but importing the schematic mostly works. My PhD work was with WEAP, so creating this example was trivial (that’s the point!). More on importing from WEAP later.