“Physics Lists”

1. “Physics Lists” First Working Group Meeting

2. Mandate • Communicate with physics working groups to maintain the physics lists etc and their parameter settings updated to current • Communicate with kernel working groups to make sure physics lists etc should be compatible with multithreading and other new features • Maintain the documentation, user guide, etc. • Communicate with example working groups to promote the proper use of updated physics lists etc. • Conduct physics performance monitoring and notice issues to relevant (physics) developers • Develop and maintain common tools for physics validation • Maintain the public web page of physics validation • Source: Proposal of creating Physics List Working Group

3. Working group name • We may choose our name, original proposal ‘Physics List’ reflects not all activities • Mandate also includes • Physics performance monitoring • Validation tools • Proposals? • Physics Lists and Validation Tools • Physics Lists and Tools

4. Regular Meetings frequency • Frequency • bi-monthly • regular • Which day, when in month

5. Plan of Work • See draft at http://edupad.ch/QmnikkyVKD • Finalize plan • Schedule work items per release or quaterly • Remarks: • How do we track progress • Geant4 Jira? • Consolidate code, less new or repetiton • E.g. two physics lists factories, no need for yaplf • Modular builds of G4 • Documentation and web: user centric

6. Prioritize Work Items • Development • Documentation, create & improve • User documents: create doc • Web pages, complete, consolidate, …. • Public web page for physics validation • Review web • Enhance tool used • References (histograms) for physics verification and regression testing • Ongoing activities • Physics performance monitoring

7. Web Pages • Merge existing pages at Geant4 – Twiki • Linked from geant4->Validation • Validation(twiki) • Physics lists (link) • Including processes and cross sections catalogs • Into new page • Using this twiki?

8. Reference histograms • Wish to compare results to reference results • Reference results will change with time • Developer decides on new set of reference data • Keep references for some time, maybe variable • References of releases will be kept for years • Reference data may be binary, like root files • Svn (@cern) explicitely forbids binary (root) files. • Use indirection, svn only keeps ‘link’ to binary data accessible e.g. via URL