Modeling the Energy Infrastructure for the State of Iowa

1. Modeling the Energy Infrastructure for the State of Iowa DEC09-02 Mubarak Abbas (E E) Austin Lyons (E E) Muhammad Rahim (E E) Mohammed Ahmed (E E) Faculty Advisor James McCalley

2. Problem/Need Statement • The state of Iowa needs to make investment decisions to meet increasing demands on its energy infrastructure. To make educated decisions, a comprehensive and interactive model of the state’s energy infrastructure is needed. Such a model currently does not exist.

3. Audience • Engineers • Government • City/Regional/State Planners • Entrepreneurs • Educators • Ordinary Citizens

4. Market/Literature Survey • First project of it’s kind for the state of Iowa • Based on a similar project on the national level (NETSCORE 21) • Used our advisor (a principal investigator for NETSCORE 21) as our main reference

5. Concept Description • Solution • Acquire energy data for Iowa • Create a system for visualizing this data • Integrate data with existing software to perform analysis

6. System Description

7. Functional Requirements • Data • Create an interactive database of Iowa energy data from 2001 to 2006 • Visualization • Design a system for visualizing • power generation, transmission line, energy resource data • System will need to be: • interactive, easy to use, free, platform independent • Analysis • Use Wien Automatic System Planning Package (WASP-IV) with generation data to perform generation system expansion planning

8. Non-Functional Requirements • Data • Energy Resources • type • coal • hydro • wind • biomass/bio-fuel • solar • capacity • investment costs • operating costs • efficiency • expected life • reliability

9. User Interface Description • Data & Visualization: User interface must be easy for anyone, regardless of prior knowledge, to interact with • Analysis: Determined by choice of existing software (WASP-IV)

10. System Description • Data • Develop an inventory of the existing energy infrastructure of Iowa by acquiring data and storing it in .csv files • Visualization • Use Google Earth to visualize data • Create data conversion program to convert .csv file to a format which Google Earth can read (.kml) • Analysis • Use Wien Automatic System Planning Package (WASP-IV) with generation data to perform generation system expansion planning

11. Operating Environment • Data: platform independent • Store data as comma separated value (.csv) files • Can edit .csv files in Microsoft Excel or any other spreadsheet software. Can also edit in any text editor. • Visualization: platform independent • Google Earth can run on a PC, Mac, or Linux • Data conversion program (will be discussed later) is written in Java, which runs on PC, Mac, or Linux • Data can be viewed in a web browser • Analysis: Determined by existing software • WASP-IV – Windows

12. Work Breakdown • Acquire data • Get maps & data from EIA, IOWA UTILITY, MEC (through Dr. McCalley) • Convert data into .csv format • Manually converted map to spreadsheet by writing down the starting and ending cities for each line, then looking up the coordinates for each city • Write, test, document data conversion program • Learn how to create Java GUI • Create website for viewing data • Integrate data with WASP-IV • Obtain and install WASP-IV • Figure out how to use WASP-IV • Obtain any missing data regarding the LDC, spinning reserves, forced outage rates, and other specific information regarding plants • Create presentations, reports, and fulfill other Senior Design requirements

13. Visualization • Data conversion program • How it works • How it was created • How it was tested • Documentation • Website • Deliverables

14. VISUALIZATION – How It Works • Data conversion program • Input: .csv (comma separated file) • Output: .kml (Google Earth file) CSV file KML file

15. VISUALIZATION – How It Works • Reads the .csv file and stores each row of data as a Point object or a Line object • Point object • Name, Longitude, Latitude, Description • Line object • Start City, End City, Start Longitude, Start Latitude, End Longitude, End Latitude

16. VISUALIZATION – How It Works • Ex: Line Data • Check whether input file exists and can be opened • Check if input file actually contains line data • Parse data one row at a time, storing correctly formatted rows as a line object • If data incorrectly formatted, print to error log • Open output file, print KML header • For each stored line object, print data in KML form • Finish & close KML file • Let user know if successful or not

17. VISUALIZATION – How It Works Psuedocode while(ArrayList<Line> has more elements) LineObject = ArrayList<Line>.removeObject() print to file “<coordinates>” + LineObject.getStartLatitude(), LineObject.getStartLongitude(), LineObject.getEndLatitude(), LineObject.getEndLongitude() + “</coordinates>”

18. VISUALIZATION – Network Data

19. VISUALIZATION – location data

20. VISUALIZATION – How It Works • Error handling • Input file can’t be opened, doesn’t contain line/point data • Skip incorrectly formatted data (don’t output to KML) • Print message to error log (name_of_file_errorLog.txt)

21. Visualization – How It Was Created • Created using NetBeans IDE • Written in Java • Aimed for concise code that is easy to maintain and easy to extend • ~1200 lines of code total

22. Visualization - Testing • Test all possible input scenarios according to formatting guidelines • Create a spreadsheet for each test • Run program, check that program doesn’t blow up and that output is correct • Example • Test003.csv: Allow empty “Start City” (no name for start city) • Test005.csv: Throw out element if “Start Latitude” is missing or is not a number between -180 and 180 – print error to log • Test016.csv: Check that additional data is appended in the “description” section

23. VISUALIZATION – Website

24. Visualization Documentation & Deliverables • Documentation • Line data formatting guide • Point data formatting guide • Basic instructions • Testing instructions • Javadoc • Deliverables • Data conversion program • Source code • Executable • Tests • Documentation • Website • Source code • Documentation

25. Future Work • Add functionality for visualizing gradient maps • Create a web based version of data conversion program

26. Analysis • Wien Automatic System Planning (WASP-IV) • How it works • How it was tested • Documentation • Deliverables

27. Analysis - How it works • WASP-IV takes in the data for LOADSY, FIXSYS, VARSYS, CONGEN, MERSIM and DYNPRO to perform generation system expansion planning • Focus was primarily on LOADSY, FIXSYS, and VARSYS

28. Analysis - How it works (LOADSY) • LOADSY describes the load characteristics of the system for each year of the study period Input Output

29. Analysis – How it works (FIXSYS) • FIXSYS describes the committed (fixed) state of the generating system for each year in study Input Output

30. Analysis – How it works (VARSYS) • VARSYS describes the alternative plants which can be used for system expansion Input Output

31. Analysis - Testing • The testing for the analysis will be made by using the forecasted data for 2008 and comparing it with the actual data for 2008. If the energy demand data is correctly forecasted within +/-10-15%, it will prove that the software and the input data are accurate (or very close)

32. Analysis - Documentation • Detailed instructions for • LOADSY • FIXSYS • VARSYS • Testing instructions • CONGEN • MERSIM • DYNPRO

33. Analysis - Deliverables • Documentation • All accumulated data from 2 semesters • WASP-IV Input Data • Output • Results • Testing

34. Future Work (Analysis) • Add and input data for the remaining routines/subroutines

35. Lessons Learned • Calling Mid-American Energy, introducing yourself as (Mohammed, Muhammad, Mubarak), and asking for power line data is a bad idea. • Working with and utilizing real data for practical purposes.

36. Conclusion • In conclusion, we obtained energy infrastructure data for the state of Iowa and created a system for visualizing and analyzing this data.

37. Questions?