1 / 31

CCSM Software Engineering

CCSM Software Engineering. CCSM Software Engineering Group Model Porting and Performance. Documentation and Training. Software Engineering Practices. Lawrence Buja CCSM Software Engineering Group. CSEG. CCSM Software Engineering Group. Purpose

tovah
Download Presentation

CCSM Software Engineering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CCSM Software Engineering • CCSM Software Engineering Group • Model Porting and Performance. • Documentation and Training. • Software Engineering Practices. • Lawrence Buja • CCSM Software Engineering Group

  2. CSEG CCSM Software Engineering Group • Purpose • Core group responsible for CCSM software engineering development • Positions • CSEG Manager • CSEG Quality Assurance Lead • CCSM Component Liaisons

  3. CSEG • Member Position • Tony Craig CSEG Manager • Lawrence Buja QA Lead • Erik Kluzek ATM Liaison • Nancy Norton OCN Liaison • Mariana Vertenstein LND Liaison • Julie Schramm ICE Liaison • Brian Kauffman CPL Liaison

  4. Role of CCSM SE Manager • Software decision making within CCSM and single point of contact for all CCSM SE Issues • "allow the scientists to do science" • Prioritize and assign SE tasks • Track activities across CCSM Groups • Coordinate internal and external developers • Model release coordination and closure • Represent SE interests/issues on SSC • Create and Maintain SE plans • Schedule SE training

  5. 41secs 48 32 3 7 2 14 7 4 8 Critical path 8 37 32 8 3 7 8 53 secs/day total (~130 years/month) CCSM Performance • OCN • ICE • LND • ATM • CPL • NERSC T42/gx1v3 (128Pes)

  6. CCSM Ports • CCSM currently being tested/run on: • NCAR IBM SP • NCAR SGI Origin 2000 • NCAR Compaq ES-40 • LANL SGI Origin 2000 • NERSC IBM SP

  7. CCSM Documentation • CCSM Documentation Project: • -User and Developers Guide for each component • - Quick Start and User Guide for CCSM • - Internal Interface documentation • - Growing online library of CCSM SE documents

  8. CCSM Training • Quick-start tutorial June 2001 • - Half-day tutorial on building and running the CCSM • Week long workshop Fall 2002 • - Theory and practice of the CCSM

  9. Modern SE Practices • Why? • CCSM becoming increasing complex • Many new players in the development • Target architectures continue to evolve • Software Engineering Models • XP CX1 SEI/CMM • Extreme Construx Capability • Programming CXone Maturity Model • Too Light Just Right Too Heavy

  10. SE Coordination Plan • Change Review Board (CRB) • Repository • Testing • Status Accounting • Documents • Planning and Prioritization • Management • Other Issues

  11. CCSM2 Control Runs CCSM2 Experiments CCSM2 Documentation CCSMFreeze CCSM2 Release Work Shop CPL6 beta PaleoCCSM Roadmap to June • Dec Jan Feb Mar Apr May Jun

  12. Fini

  13. CCSM2 alpha tests CCSM2 beta CCSM2 Freeze SSC Oct 17 CSIM LSM POP NASA CAN due Nov 20 CCM Components, interfaces, grids should be close to final state NASA CAN Selections Feb 5 Roadmap to June • Oct Nov Dec Jan

  14. Freezing CSM-2 • Finalizing Component Configurations • Component Acceptance • Validation Procedure

  15. CCSM Issues • Code Development Process (this meeting) • Who defines process? • Who coordinates the efforts? • Integration with ACPI and NASA CAN efforts • Insufficient Software Education • Implementation of Software Engineering Plan • Testing/Validation procedures to be formalized

  16. Role of SW MGR/COOD • 1. Prioritization and assignment of the SE Tasks • 2. Tracking activities across CCSM Groups (interface mgmt) • 3. Coordination (external outside CCSM) • To obtain shared codes • To track + help coordinate research codes • Technology tracking in general • Across outside Collaborators (ACPI/NASA) • 4. Software Decision Making within CCSM • 5. Release Coordinating/accountability/closure • 6. Represent SE interests/issues on SSC • 7. Single point of contact for other groups • 8. Maintaining SE plans • 9. SE training • 10 responsible for setting SE protocols

  17. Action Items • 1. Erik write up CM procedure, Put in Developers Guide • 2. Internal meeting on building/testing. Bring desired features • 3. ACPI meeting. Extra day to iron out building/testing • Recommendations: • 1. SEI training for tech support • 2. Incrementally build up protocols and documents with goal of • better organizing the software process for ccsm. • 3. SE coordinator/manager added to present SSC

  18. Coordination/Management • Functions • Prioritization • Closure • Coordination • Scientific SE's working in "research mode" • Collaborate with/ reviewed by Scientists • Software/Utility SE's working on infrastructure development • Coordinated by Software Professional • Negotiation of time between scientists and coordinator • Coord has power to make decisions about how things are done.

  19. CCSM ORG Chart Coordinator SSC Software ATM OCN PALEO scientist programmer research infrastructure

  20. ORG Chart Move infrastructure work

  21. NCAR Strategic Plan THE PLAN: NCAR will organize the composition and management of its large modeling efforts to maximize the effectiveness of multidisciplinary teams. THE PLAN: NCAR will ensure that the organizational structure of its major modeling projects integrates the expertise of both physical and computer scientists. THE PLAN: NCAR and UCAR will develop a coordinated strategy for developing simulation models that allows the institution to be agile in allocating resources for the development and evolution of all aspects of the end-to-end simulation environment. THE PLAN: Management of major software projects will accommodate the broad constituency of the team effort, facilitated by project managers who have authority commensurate with their responsibility

  22. NCAR Strategic Plan • THE PLAN: NCAR will adopt software engineering practices that promote high performance and the efficient development of large simulation models and software infrastructure. • Establish formal software design procedures. • Develop layered software • Use software development tools. • Object-oriented techniques and frameworks.

  23. Scalar Processor Optimization Computer = processor and memory layout complexity = computation speed + data motion Performance obtained by minimizing complexity for a particular architecture and exploiting parallelism Memory access is quantized in cache lines (4-16 words) Pay cache load cost whether use 1 value or all values in line Registers fastest (on chip) L1 Cache (on chip, 2-3 clock cycles away) L2/L3 Cache (off chip) Local/remote memory

  24. CCSM Issues • Code Development Process (this meeting) • Who defines process? • Who coordinates the efforts? • What design docs are necessary? • Integration with ACPI and NASA CAN efforts • Insufficient Software Education • Implementation of Software Engineering Plan • Testing/Validation procedures to be formalized

  25. ACPI Update (rosinski) • Short duration DOE initiative to speed up climate models • Oak ridge, LLNL, ANL, NASA DAO NCAR, • 2-d decomp of ccm and modularize physics/dynamics • Initial focus on CPL and ATM (see drake web page) • Numerous targets completed (truesdale doing config manage) • 2-d specific problems: Transposition logic (FFT • Oak Ridge doing Eulerian spectral and Semi-lagrangian spectral parallelization • LLNL (rotman/lin/mirin) doing Lin-Rood parallelization • 5.5 Years/day on 64 Winterhawk II processors standalone • Little impact from NetCDF output • CPL: two tracks: Dec freeze track w/ classic cpl NGC track: In prototyping phase

  26. NASA CAN (deluca) • Increasing Interoperability and performance of Grand Challenge Applications in the earth, space, life and microgravity sciences • Testing/Validation crucial. Allows decision making and scheduling • Up Front Design is very important. • Structure: things that people deal with day-to-day • Process: How we do things. New stuff • Concentrate on structure things that help us do our job better.

  27. NASA CAN (deluca) • Increasing Interoperability and performance of Grand Challenge Applications in the earth, space, life and microgravity sciences • Testing/Validation crucial. Allows decision making and scheduling • Up Front Design is very important. • Structure: things that people deal with day-to-day • Process: How we do things. New stuff • Concentrate on structure things that help us do our job better.

  28. Summary

  29. NASA CAN (deluca) • Increasing Interoperability and performance of Grand Challenge Applications in the earth, space, life and microgravity sciences • Testing/Validation crucial. Allows decision making and scheduling • Up Front Design is very important. • Structure: things that people deal with day-to-day • Process: How we do things. New stuff • Concentrate on structure things that help us do our job better. • 1st start with pieces, then bring it all together.

  30. Misc items • 1. Configuration management • 2. Coding Convention • 3. Build procedures and user support • 4. Test scripts and validation • 5. Coupler interfaces

  31. Supervision • 1. Many Ses continuing to report to scientists • 2. Some report directly to se coord/mgr • 3. coord/mgr reports to maurice/ssc

More Related