First off, happy summer, 2017! It’s about time for another update of what’s going on in the world of OpenAgua. This post will cover some recent outreach activities, and will be followed up in a subsequent post with updates on exciting feature developments.
Spring outreach adventures
This past spring, primarily during the month of May, 2017, yours truly (David R.) travelled to Monterrey (Mexico), Sacramento (California), and Wuhan (China) to present OpenAgua to various interested folks, including at the 2017 EWRI World Environmental and Water Resources Congress in Sacramento. In addition, Laura Garza, the leader of the Monterrey case study with OpenAgua (funded by CITRIS), also came to Sacramento for a Monterrey team meeting at UC Davis and to attend the EWRI Congress. The following is an account of David’s activities, written in the first person.
May 11-17: Monterrey, Mexico
In Monterrey, I presented OpenAgua to some students and faculty affiliated with the Water Center for Latin America and the Caribbean at Tecnologico de Monterrey. Attendees included Dr. Jurgen Malknecht, the Director of the Center, and Dr. Aldo Ramirez, the Principal Investigator of the CITRIS-funded effort (the Monterrey case study).
While the purpose of this trip was also to conduct a short training on how to use it, OpenAgua failed in an important way, preventing a successful completion of the training. Since the platform is still in the prototype development stage, this situation often occurs, resulting in the presentation and subsequent discussion being more important/valuable.
Other times in Monterrey were spent, well, further development of OpenAgua, as well as meeting old colleagues, etc.
May 19-25: Sacramento, California
On May 19, the core team for the CITRIS-funded Monterrey case study (myself, Laura, and Dr. Josue Medellin-Azuara) met at the University of California, Davis, to discuss progress and next steps for the Monterrey case study. Of particular importance is the need to develop a site tailored specifically to Monterrey. Though the site will be hosted by openagua.org, the branding will be entirely about Monterrey, just as one may host a WordPress blog on wordpress.com, yet have a custom URL and otherwise no mention of WordPress. Of course, for this project we want to emphasize OpenAgua, so we will do so, but the analogy remains and is one we will use to guide us going forward.
The following week, May 22-25, Laura and I absorbed the latest in water resources research at the EWRI congress, and I presented OpenAgua in an oral session.
As is usual at these conferences, much of the value was from the side conversations between sessions. In particular, I had numerous valuable conversations with researchers from various professional corners of the world to discuss our work and shared (or not!) research interests. In general, OpenAgua was very well received by those I talked to, though this wasn’t exactly a public unveiling. I don’t believe there will be a public unveiling – just a slow rollout on a project-by-project basis (initially), followed by more aggressive promoting down the road.
In addition, I also had particularly useful conversations with leaders in water modeling systems, including Dan Sheer, founder of HydroLogics and developer of OASIS, a widely-used water resources modeling tool, and Dr. David Purkey, director of the U.S. Center of the Stockholm Environment Institute, which develops WEAP, the most well-known desktop-based water system modeling tool today, and our chief inspiration and (hopefully) future competitor. I shall leave the details of these conversations private, though generally the former was an overview of OASIS, while the latter was about the state of water system models with respect to the movement of applications to the web, business models related to web applications, and what that means for water system modeling applications. While we may or may not collaborate with established players in the field of water system models, I believe it’s important to have these conversations, with the broader recognition that for the most part we are all interested in the same thing: advancing the ability of water (and energy) planners and investors to improve planning decisions.
May 28-June 3: Wuhan, China
Finally, I spent one week at Wuhan University, where I spent some time a few years ago researching e-flows and the Three Gorges Reservoir and learning Chinese. As before, I presented OpenAgua, this time at the State Key Laboratory of Water Resources and Hydropower Engineering Science of Wuhan University.
One PhD student there, Wenchao Wang, was particularly interested in the work, and had himself worked on his own web application to help real-time decision-making in the agricultural water sector using real-time information from water sensors.
Unexpectedly, I was also invited to present OpenAgua at the Changjiang Institute of Survey, Planning, Design and Research (CISPDR, of the Changjiang Water Resources Commission), which, among other activities, provides engineering services for water infrastructure development projects within China and globally; it is the organization that planned and designed the Three Gorges Reservoir, and are applying their experience overseas, much as the TVA did. (NB: this comparison is not so much about actual practices, but rather the simple notion of extending development capacity globally; a formal comparison of the CISPDR and TVA would make an interesting paper!). So, I gave the presentation, toured their facility, including a state-of-the-art 3D screening of some of their promotional materials, and was well fed.
The CISPDR uses WEAP and Mike Basin in their numerous international water planning activities, and so are particularly interested in OpenAgua, for web-based and open source (read: free) aspects, as well as for the new development paradigm (it can be made theirs). As Chinese companies are known for practices that do not follow Western ideals, there may be some concern for working too closely with a Chinese company. However, personally I believe engagement and collaboration a more effective way of promoting the very thing OpenAgua is seeking: collaboration and transparency in not only software development, but also water resources development.
Outcomes from this trip were not necessarily tangible, but rather included a better understanding of issues and concerns related to the continued development and use of OpenAgua. A few of the more important conclusions are as follows:
- A sustainability model is needed. In my numerous conversations, it was quite clear that a web application for water system modeling is needed and will be highly valued. However, this value will not necessarily translate into monetary value, as, more importantly, people are interested in a free web application. Indeed, most were excited for the possibility of a web application that was free of cost, leading me to consistently either stay quiet, or temper expectations, as there are costs that must be borne in a website. It’s just a matter of who pays. Hence, one of the main outcomes was the need to develop an application sustainability model. This is something that I have thought about extensively (and there are numerous options), but none of these ideas have been formalized with hard numbers to indicate the best options.
- We should identify areas where we should collaborate, and areas where we should compete. We will never have a single, do-it-all modeling platform, and there probably shouldn’t be. However, we also want to facilitate better water planning and management through insights from water system models, which requires some degree of collaboration so that we can transfer data and (possibly) models. In several discussions the issue of sharing data and models came up, and so we should identify standard ways of sharing these. One of the points that I continually made in my talks was that by using the Hydra Platform approach, whereby we separate models from data from GUIs, we can develop competing user interfaces that work with the same underlying databases/structures, as long as those data structures are standardized. Hydra Platform facilitates this standardization, but here are limitations, as there are some data structures that Hydra Platform does not attempt to address natively, such that as a water modeling community we need to identify and standardize these additional structures. A good example is GeoJSON-based representations of networks, which can be used in web mapping applications. How should we store GeoJSON and associated visual styling in Hydra Platform-based data structures, such that they can be interpreted among competing applications? Many other examples exist.
- The issue of a controlled water system vocabulary needs to be addressed. Dr. David Rosenberg, at Utah State University, is doing some interesting work to help translate water system vocabularies between different water system models. This is very much needed. In my discussions with him and his students, I’ve concluded that we will never have an agreed-upon vocabulary. But, what we can do is agree upon a vocabulary translation dictionary. For example, we can collectively, as a water modeling community, agree that “Dead Zone” in Platform A means “Inactive Pool” in Platform B, and develop translation tools around these.
- OpenAgua should support a wide range of different data input methods. Input options should range from copy-paste from, say, Excel, to simple functions, to advanced scripting. Even for advanced scripting, there are different languages that can be used: some prefer Python, others R, and yet others VBScript. WEAP does a great job at recognizing this, with an in-built custom expression language as the default, but with the ability to develop advanced scripts; while WEAP doesn’t allow you to copy-paste from Excel, it does allow you to easily read Excel and CSV files via its expression language. I strongly concur, and it’s my hope that in addition to all of these options, OpenAgua will eventually enable easy access to web resources for obtaining data (e.g., Dropbox, web services, Amazon S3 buckets, etc.). A common concern I heard in my presentations was “what if someone doesn’t know Python [the default scripting language in OpenAgua] for inputting data?” My response has typically been, 1) “we will make it easy as possible to use Python with as little learning required,” 2) “Python is easy to begin with,” 3) “either way, one will likely need to learn/know some kind of problem formulation language, at some point, for a decidedly technical endeavor,” and 5) “I hear you! We’ll add a wide range of input options. You can already copy-paste from Excel to OpenAgua, and many more options will be added, including support for other scripting languages.”
That’s it! I was very excited about the initial reception near and far. While still in it’s beginning stages (and very much glitch-prone), OpenAgua shows promise not only in it’s capabilities, but also in its adoption by potential users.