RSM Refactor (Phase 1)<br />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<br />Project goals<br />Clean up the code<br />Restructure into stronger object oriented model<br />Change No Functionality<br />
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 />
Incorporation of new technologies</li></ul>+<br />Model Objective<br />C++ Coding Standard<br />RSM Refactor<br />
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 />
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 />
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 />
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 />
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 />
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 />
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 />
A particular slide catching your eye?
Clipping is a handy way to collect important slides you want to go back to later.