1. Comp 410 Client Meeting 11-5-11

2. Outline Revised Use Cases Design Concept Implementation on Azure Revised GUI Mockup Demo Future Meetings

3. Revised Use Cases Elizabeth Fudge

4. Basic User Typical member of public May have no knowledge of energy industry No authentication required “Free” to CFAE

5. Basic User Use Case Visits CFAE website, goes to simulation page Selects a predefined model with plan Views simulation results Views plan Views model

6. Authenticated User Has enough domain knowledge to make basic edits to model and/or plan Authenticates with credentials supplied by CFAE Costs money for each set of basic edits they save and for each simulation they run Paid for by user or by CFAE

7. Authenticated User Use Cases All use cases for Basic User and … Logs in Selects a predefined model with plan Changes numerical parameters of the model and/or plan May save numerical parameters for future use Runs simulation Views new simulation results

8. Expert Authenticated User Has enough domain knowledge to make advanced edits to model and/or plan Authenticates with credentials supplied by CFAE Costs money for each model they edit and save and for each simulation they run Paid for by user or by CFAE

9. Expert Authenticated User Use Cases All uses cases for Authenticated User and … Selects a predefined model with plan, or one of their own saved models with plan Uploads code and adds to model Runs simulation Views new simulation results

10. Clarification: Publishing Models/ Plans Would be confusing for Basic User to see all saved models/plans CFAE may want to change models/plans which are visible to Basic User Could have “publish” option for authenticated users, would have to be approved by CFAE Could have “publish” option for only some authenticated users (CFAE staff)

11. Clarification: Worst Case Plan Is worst case plan no change in current behavior? Or absolutely no actions taken? Ex., coal power plant goes offline from old age – is it replaced with another coal plant or not replaced at all?

12. Design Concept Andrew Emil

13. Design Concept Goals Flexible framework able to simulate wide variety of models Provide ability to run simulations of arbitrary complexity and size Allow for easy visualization and editing of models

14. Solution: Module-Based Modeling Modules can have any number of inputs and outputs Each module can be defined through 1.Code 2.Compositing Code-based Modules: – Essentially small programs

15. Composite Module Example Addition Module A B A + B A B C Addition Module A + B +C Composite Addition Module

16. Module Advantages: Complexity and Elasticity Modules allow for entire simulation to be broken into small pieces Simulation framework can maintain arbitrary number of modules for each simulation Encapsulation of work means that simulations are just a collection of modules and connections between them No need for centralized computing, work can be spread out as desired

17. Module Advantages: Flexibility Module definitions allow for varied internal behavior of modules Arbitrary connectivity relates modules to each other Any module may connect to any other module with compatible inputs and outputs

18. Module Advantages: Usability Concept of different levels of view High level understanding of a model is achievable without having to see details Easy to follow logic from high level to low level Encapsulation of sections of model – Can change one aspect of model without having to change others

19. Implementation on Azure Weibo He

20. Why Microsoft Azure? Scalability – Scalable computation power for simulations – Scalable visitor volume Cost-Performance – Low initial cost – Low maintenance cost Stability – Handling hardware failures

21. Revised GUI Mockups Jesus Cortez

22. Mockup Overview

24. UI Walkthrough: Basic Use Case

27. UI Walkthrough: Authenticated Use Case

32. Demo Robert Brockman

33. Future Meetings Update presentation Final presentation – Last day of classes for Rice is December 2 – Last day of exams for Rice is December 14

34. Backup Slides

35. Module Representation Producer Outputs: -Energy Supply -Energy price -Pollution Consumer Inputs: -Energy Supply -Energy price -Pollution Regulation Environmental Inputs: -Pollution from Producer Environmental Outputs: -Regulation for Consumer Producer module requires: -Initial price of energy -Initial supply of energy -Slope of initial supply curve Producer Inputs: -Demand for energy Environmental module requires: -Strength of regulation Consumer module requires: -Demand curve slope -Price of energy Consumer Outputs: -Energy demand At the start of the simulation:

36. Terminology Event: An external change to the behavior of the energy industry Model: A representation of the energy industry in terms of interconnected modules Module: A component which takes in a set of inputs and generates a set of outputs using some internal behavior Module Parameter: A numerical parameter associated with a particular module which affects the behavior of that module Plan: The set of all events for a given simulation