Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Rsm Refactor April 2011


Published on

This is a presentation on the recent changes to the code of the Regional Simulation Model.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Rsm Refactor April 2011

  1. 1. RSM Refactor (Phase 1)<br />Refactor - Code refactoring is "a disciplined way to restructure code",[1] undertaken in order to improve some of the nonfunctional attributes of the software. –<br />Project goals<br />Clean up the code<br />Restructure into stronger object oriented model<br />Change No Functionality<br />
  2. 2. Team<br />Project lead – Joseph Park<br />Core Developers<br />Fahmida Khatun<br />Charles Haynes<br />Randy Vanzee<br />Additional development and consulting staff<br />Veera Karri<br />Raul Novoa<br />Eric Flaig<br />Wasantha Lal<br />Ruben Arteaga<br />Clay Brown<br />Sharika Senarath<br />Michael Martin (USACE)<br />
  3. 3. RSM Past<br />Canal-Mesh<br />Integration<br />Benchmarks<br />C++ Standard<br />gcc justification<br />WaterBody/<br />WaterMover class<br />ENP Model<br />Parallelization<br />DSS I/O<br />Vertical Soln<br />SCCS<br />PETSC<br />Sparse Matrix<br />Purify<br />C++ standalone<br />Documentation<br />+6<br />+ 2.3 Yrs<br />+ 4<br />Alpha controller<br />Rulecurves<br />PID controller<br />hse<br />FORTRAN – C++<br />Canal<br />Algorithm<br />XML<br />CVS<br />pseudocells<br />+ 3.2 Yrs<br />1998<br />1997<br />1999<br />2000<br />2002<br />2001<br />8/96<br />1996<br />Exception handling<br />Console logging<br />Basin WB<br />Bugzilla<br />Trigger Module<br />Assessor<br />MSE Network<br />WCU Assessors<br />Fuzzy control<br />pseudocell hub <br />WM control<br />MSE<br />User controller<br />GLPK<br />+7.7<br />HPMs<br />Special Assess<br />Iterations<br />WMM Assess<br />WCU Profiler<br />Basins EAA<br />Linked Basins/<br />WMM Assessors<br />.dtd version<br />stage based<br />LGMRES<br />ORM refactor<br />Canal decouple<br />STA WQ<br />2003<br />2004<br />2005<br />2010<br />2006<br />2007<br />2008<br />2009<br />
  4. 4. April 2009 Proposed RSM Developments<br />Lessons Learned<br />RSM Enhancement Program<br /><ul><li>Architecture review and design
  5. 5. Domain-specific attention
  6. 6. Improvement of model functions
  7. 7. Incorporation of new technologies</li></ul>+<br />Model Objective<br />C++ Coding Standard<br />RSM Refactor<br />
  8. 8. July 2009 Proposed RSM Developments (& Status)<br />HSE Kernel†<br />1. Investigate replacement of PETSC with internal GMRES solver. (IML++ solver was fully integrated & tested with GladesLECSA model in 2010. See next slide.)<br />2. Evaluation and enhancement of watermover Jacobians (Current).<br />† This does not directly address or design a solution for overland flow (2D) stability, or reformulation of the diffusion framework with the addition of inertia. <br />
  9. 9. IML++ Analysis - LGMRES<br />Implementation & testing of IML++ found that in comparison to PETSC, runtimes were slower and waterbudget residuals higher for GladesLECSA models. <br />However: it led to a better understanding of the LGMRES algorithm and through exhaustive testing resulted in the adoption of PETSC LGMRES with Kyrlov subspace restart parameterisations that:<br />1. Significantly reduced model runtimes<br />2. Give modelers control over solution tolerance / runtime tradeoff<br />
  10. 10. July 2009 Proposed RSM Developments (& Status)<br />RSM Refactor<br />1. Assess current code-base and class hierarchy. (2010)<br />2. Get Modeler input to identify needed and superfluous waterbodies, watermovers and functions. (2010)<br />3. Develop RSM Coding Standard. (2010)<br />4. Implement code cleanup based on Modeler criteria. (2011)<br />5. Assess code adherence to RSM coding standards. (2010)<br />6. Code refactor to correct deviations from RSM coding standards. (2011)<br />7. Assess functional integration of modules (HPMs, Trigger… etc.) (Future)<br />8. Refactor identified modules to uniform HSE/MSE integration standards. (Future)<br />
  11. 11. Bugzilla 2173 – RSM Refactor<br />A holistic cleanup and review of the RSM/HSE code base has not been conducted. There are varying styles and formats across the code-base which present barriers to assimilation by new developers and support by maintainers. There also exist sections of dead code, unnecessary header file dependencies and defunct benchmarks. <br />The Model Development Leads recommend:<br />1. Unifying the code-base with a coherent set of standards<br />2. Cleaning up dead code and benchmarks<br />3. Reducing header file dependencies<br />Project Goals<br />1. Code-base will be unified with a common look-and-feel<br />2. Source image will be reduced in size and complexity as header dependencies are removed<br />3. The pool of RSM developers will be expanded <br />4. No functional changes to model I/O, behavior or performance <br />
  12. 12. RSM Centric C++ Coding Standard<br />Version 1.1<br />February 24, 2011<br />Technical Committee<br />Joseph Park<br />Randy van Zee<br />Charles Haynes<br />The Coding Standard emphasized consistency, adherence to C++ standards and the reduction of header file dependencies.<br />
  13. 13. RSM Refactor Project Documentation <br />SVN: svn://dcluster1/rsm/RSM-Refactor-Docs <br />Web: http://dcluster2/viewvc/rsm/RSM-Refactor-Docs<br />RSM-Refactor-Docs/<br />acceptanceTesting/ - Model Implementation Validation<br />analysis/ - Code Analysis Tools and Results<br />codeReviews/ - Peer Review Comments<br />designData/ - Model Functional Design Criteria<br />designGuide/ - Coding Standard & Rules<br />status/ - Peer Review Spreadsheet & Changes<br />
  14. 14. RSM Refactor Results<br />122 Files Removed<br />600+ Files Edited & Reviewed<br />Header File Dependencies Significantly Reduced (makefile dependencies reduced by a factor of ~2.5) <br />Consistent Code Format & Comments<br />Doxygen Comment Strings <br />No Change in Model Implementation Performance<br />4 Benchmarks Reactivated<br />7 Benchmarks Depracated<br />Multi-process builds now supported at the top level directory<br />
  15. 15. What’s next?<br />Development tasks<br />Upgrading the C++ compiler to the latest GNU compiler suite<br />Further conversion of coding constructs towards object oriented design and methods<br />Reduce redundant code<br />Multi-process the benchmarks<br />Create application unit testing environment<br />Parallelize the code in a cluster friendly way<br />Explore coherent shared memory solutions<br />Create an API (Application Programmers Interface)<br />Technical/Scientific tasks<br />Upgrade the solver<br />Parallelize functionality within the solver<br />ILU preconditioner switch to JACOBI (ILU will not work in parallel)?<br />