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