Hadronic Code Maintenance: Summary John Apostolakis

Overview Experiences How: Methods and ideas What = Planning Presentation Mike Kelsey’s summarised experience from the major reengineering of the Bertini cascade Discussions On each approach and technical point

Experience and methods Methods used in the review / improvement of code modules Experiences Strengths & limitations of approaches / techniques Discussion topics Lessons Tools - old and new Ideas - brainstorming

Tasks and Priorities Needs: What is to be done Areas of concern Different experience of developers Common issues Establishing priorities Current plans (next 6-12 months) Next priorities First discussion

Types of Concerns Classes with very large methods ( e.g. > 1,000 lines) Code which has been copied and small changes made Code adapted from Fortran etc Using different utility classes ( vectors, particles, …) …

Tools for code improvement Bertini done "by-hand", Software (Eclipse has re-factoring tools, but not used) IgProf - memory and CPU profiler coming from CMS - finds memory leaks, memory churn. Experience For re-engineering, using it on unit tests is best!

Monitoring of results Checking large re-engineering or changes: Add code that dumps lots of state (eg by printing) check results before and after each change ANY changes of results are reason for review or rejecting the code changes. Use profiler (e.g. IgProf) with ‘big’ benchmarks, such as SimplifiedCalorimeter every ref tag One goal is to identify a list of models responsible for time, memory churn

Reducing memory churn Memory churn = repeated allocation and deallocation of memory (for the same code) Ideas for improving Use vector instead of vector as much as possible Pass by reference Consider using G4Allocator – to manage small objects

Next Areas to Improve Precompound large memory allocation seen from unit tests (priority to be confirmed) Bertini Most improvements already carried out De-excitation – evaporation Memory churn is significant (10s MB / 1k events) FTF Memory churn observed significant recent developments, large code changes / additions CHIPS Very long core methods – very hard to maintain in long term Edge physics models being re-engineered (quasi elastic,..)

Targets for improvement Using alternative classes for ‘standard’ methods is a real maintenance issue Extra code cost effort to maintain – if it can be ‘excused’ at all, it would need to have significant reasons; Move to full use G4 particle types, four-vectors, … in code which we maintain. How to find what is missing ? survey which parts do not use four-vectors, G4 particles, hadronic exception,.. “grep" for correct G4* classes/methods (will give us overview of what is not using, then discuss case by case)

Final remarks Code maintenance is important To improve performance (CPU, memory use) To make code more maintainable for the future (code that is unreadable by others will not survive in the long term.) Online notes of meeting Start an ongoing discussion on how to improve our code (not just today) Benefit from experience