1 Quantitative Information Activities California Water Plan Analytical Tools and Data Workgroup June 3, 2005

2 Objectives for Meeting ● Morning – Discuss 3 groups of planned activities related to quantitative information ● Afternoon – Talk more about a proposed method to decide how to produce numbers for the California Water Plan

3 Context ● California Water Plan Update 2005  Volume 1: Chapter 5 Implementation Plan  Recommendation 11 – Improve Water Data Management and Scientific Understanding ● Lists an Action Plan and Intended Outcomes

4 Activities in Action Plan ● Develop a general checklist of issues, resources, data, and analytical tools as well as guidelines to aid regional integrated resource planning ● Select and/or develop analytical tools and data in support of California Water Plan Update 2010

5 Activities in Action Plan ● Develop the Water Plan Information Exchange (Water PIE) for collecting and sharing data, and networking existing databases and websites, using GIS software to improve analytical capabilities and developing timely surveys of statewide land use, water use, and estimates of future implementation of resource management strategies

6 Activities in Action Plan ● Participate in efforts by the CWEMF to develop and carry out a plan for long-term improvement of analytical tools and data for statewide planning.

7 Current Activities ● Collaboration – How can we work together effectively for long-term quantitative development? ● Information exchange – What role can state serve in sharing useful information for regional and statewide planning? ● Numbers for the Water Plan – How to produce Quantitative Deliverables?

8 Collaboration Cooperating for Quantitative Capability

9 Topics of Collaboration ● Partnering on near-term studies ● Institutional setting for quantitative work ● Sharing information, research, and analytical tools ● Document “state of knowledge” as it evolves ● Public involvement

10 Reasons to Collaborate ● Integrated resource planning requires multi-disciplinary information ● Want to improve understanding and access to useful information across the state at an appropriate resolution ● No single entity can develop the analytical tools and data needed to answer these broad questions

11 Some Current Partners ● Long-term quantitative development with California Water and Environmental Modeling Forum (CWEMF) ● Robust decision making under uncertainty with RAND ● Implications of climate change with Natural Heritage Institute (NHI) and EPA

12 Addressing Institutional Support ● Much interest in demonstrating performance for public investment ● Want acceptable means to report on system changes and benefits ● No system in place to fully support quantitative needs of integrated regional water management

13 CWEMF Draft Report ● California Water and Environmental Modeling Forum prepared a draft report entitled: “Strategic Analysis Framework for Managing Water in California” March 11, 2005 ● Available on CWP web site ● Suggested some ideas for possible institutional support

14 Examples to Consider ● CWEMF draft report offers several options to consider for institutional support  Some form of consortium  Separate research and development unit  Approved set of quantitative methods, tools, and data  Etc.

15 Institutional Considerations ● Division of Planning and Local Assistance is taking the lead to develop proposals in this area ● Interested parties please contact Kamyar

16 Information Exchange Sharing Information Across Regions and Statewide

17 Recommendations - Update 2005 ● Inventory existing tools and data and identify key gaps ● Design a conceptual framework to collect and share information related to statewide and regional water planning ● Begin implementation of an information exchange system

18 Recommendations - CWEMF ● Focus on developing a database system that will serve to manage data sets used as inputs to analytical tools ● Improve geographic representation of water related information ● Refine conceptual design for data management

19 Recent Progress ● California Land & Water Use database and web portal ● Created a relational database for information needed to complete water portfolios ● Linked to GIS system to view geographically ● Created a web portal for sharing

20 Database Description ● Contains water use estimates for three years of water portfolio data ● Organized at a DAU by county level of detail ● Contains crop ET, EP, ETAW, CF, and AW and urban water use by customer class and sources of supply

21 Data Queries ● Can obtain data by:  Hydrologic region  Planning area  County  Detailed analysis unit

22 CA Land & Water Use Web Portal

23 Discuss Information Exchange ● Considering how to proceed ● What is most useful information to host first? ● What role should state play? ● How does this affect upcoming grant cycles?

24 Numbers for the Water Plan How to produce Quantitative Deliverables?

25 Big Picture for Numbers ● Enhance shared understanding of California water management system ● Illustrate recent conditions ● Consider what changes are likely between now and 2030 ● Identify and test promising responses to expected changes

26 Quantitative Deliverables ● Water Portfolios  Describe where water originates, where it flows, and what it is used for based on recent data ● Future Scenarios  Describe expected changes by 2030 if water managers do not take additional action ● Alternative Response Packages  Describe packages of promising actions, predict expected outcomes, and compare performance under each scenario

27 Talk About Numbers ● In order to focus our discussion, we are calling the numbers we want to produce reporting metrics ● Reporting metrics are those items we are most interested in from the quantitative deliverables

28 Example Reporting Metrics ● Water delivery quantity by place and time ● Population by region and time ● Meteorological conditions ● Urban water supply reliability ● Agricultural production ● Ecosystem health

29 Building Blocks ● All reporting metrics consist of  observable data, or  some combination of observable data ● Analysis will focus on providing the relevant building blocks ● Basic information can be combined in various ways for different purposes or interests

30 How to Produce Numbers? ● We have agreed on a what we want ● Getting specific about how to produce them ● Consider near-term and long-term Task: Select or develop analytical tools

31 Parts of an Analytical Tool ● Conceptual model ● Theoretical model ● Numerical model ● Data ● Data management ● Software ● Hardware ● Administrative aspects

32 Before Selecting Tools ● We want to take a fresh look at our collective understanding of how the water management system works ● We want to interact with domain experts to make sure we capture the latest thinking ● Document our collective understanding of water management system domain(s)

33 Describing Reality ● We must describe the water management system and how we think it changes ● We can describe different views of what we “know” ● Describe using:  Observable data  Relationships This is not a skull.

34 Analysis Factor View Water Management System Geophysical Parameters Evaluation Criteria (Economic, Management, Societal) Evaluation Criteria (Economic, Management, Societal) Human and Environmental Water Demands Management Strategies Demand Drivers Water Management Objectives Organization Definitions Overview

35 Accounting View

36 Other Conceptual Views ● Existing analytical tools all include one or more conceptual models ● Examples include CALSIM, CALVIN, WEAP, IWR-MAIN, and CALAG

37 Current Goal for Numbers Activity ● Produce a set of “artifacts” that capture and document our knowledge of the domains necessary to produce meaningful reporting metrics ● Use the artifacts as guidance for developing and selecting analytical tools for next set of quantitative deliverables

38 How to Document Domain ● We are applying a technique widely used in commercial software development ● Rational Unified Process technique  Iterative approach used to define actors and their objectives  Leads to system requirements  Produces a number of artifacts

39 Object-Oriented Thinking ● Object-oriented analysis emphasizes finding and describing the objects or concepts in the problem domain ● Use a familiar way of human thinking and abstraction ● Describe abstract system in terms of entities, interactions, and responsibilities ● Can use the existing visual Unified Modeling Language

40 Example of Domain Model SailboatMast Hull

41 Summary ● Approaching quantitative work arranged in three activities:  Collaboration  Information Exchange  Numbers for California Water Plan ● After lunch we will discuss how to proceed towards developing and selecting analytical tools

42 Lunch Break

43 Select and Develop Analysis and Design to Produce Quantitative Deliverables

44 System Under Discussion (SuD) ● Want a quantitative system to produce desired reporting metrics contained in Future Scenarios & Alternative Response Packages ● Expect to develop some new analytical tools ● Expect to use some existing tools ● Working to decide what combination of new and existing

45 Guiding Principles ● CWEMF report proposes Principles for Development and Use of Analytical Tools and Data ● Principles address:  Strategy  Transparency  Technical Sustainability  Coverage  Accountability and Quality Control

46 Proposed Approach ● Focus on one reporting metric at a time (e.g., urban water supply reliability) ● Capture and document necessary domain components to compute reporting metric satisfactorily ● Interact with domain experts to create and refine domain model ● Select potential implementation techniques and test along the way

47 Common Artifacts from RUP ● Domain model ● Glossary ● Use-case model and supplementary specifications ● Design model

48 Analysis vs. Design ● Analysis – emphasizes an investigation of the problem and requirements, rather than a solution  Do the right thing. ● Design – emphasizes a conceptual solution that fulfills the requirements  Do the thing right.

49 e.g., Urban Supply Reliability ● First analyze what is required to compute the reporting metric ● Then design how to perform the computations

50 Getting Started ● Define urban water supply reliability ● Identify other reporting metrics required  Demand  Population  Delivery  Location  Etc.

51 About Objects ● Objects have an identity, behaviors, and attributes ● Objects can contain other objects ● Each object relies on the other objects to know how to do their own thing ● This allows us to do modular analysis and design that works together

52 Example Objects ● Climate ● Meteorology ● Dwelling ● Building ● Land ● Geographic area ● Metropolitan area ● Water supplier ● Water user ● Water infrastructure ● Government ● Water regulations ● Public interest group ● Water source ● Economic market ● Establishment

53 Sample Glossary ● Water user – entity with a desire to apply water to a beneficial use ● Economic market – entity that describes how to efficiently allocate resources

54 Brainstorming Example ActorResponsibilityCollaborate Water userDecide upon the resources desired to accomplish a beneficial use Supplier Economic Mkt. Government Facility Water supplier Deliver, obtain, & treat water Set prices Remain functional Water users Other suppliers Economic Mkt. Govt., etc.

55 Modeling Demand Describing Associations Water UserWater Supplier 1..* Sets-price Requests-quantity Delivers-water 1..*

56 Modeling Demand Describing a Water User 11..* Water User Person Dwelling LandBuilding 1 1 Infrastructure *1 Beneficial Use 1 1..*

57 Modeling Demand by Region Water User Metropolitan Region * Resides-in 1 quantityDemanded Meteorological Conditions Economic Market

58 Start with Coarse Model ● Begin with large domain subsets ● Capture key concepts ● This approach allows us to discuss a very complicated system in manageable chunks ● Each subset will be described and tested incrementally, expecting evolution ● Can refine each subset over time

59 Questions and Comments

60 Next Steps ● Continue to draft domain representation needed to compute urban water supply reliability ● Begin detailed interactions with domain experts for domain subsets ● Others?

61