2023/03/09 1WP3 meeting
ChEESE 1st WP3 meeting (March 9th 2023, 14.00h)
- Agenda: Recall WP3 outlines and define first activities
- Follow the meeting online:link
- Access code: rAexyn
Presentation slides
WP3 Meeting presentation folder
Minutes
Attendees
• Filippo Mantovani (BSC) • Giorgio Amati (CIN) • Laetitia Le Pourhiet (SU) • Maria Jose Garcia (CSIC) • Marc Martinez (CSIC) • Mario Wille (TUM) • Marta Garcia (BSC) • Nathanael Schaeffer (CNRS) • Okba Hamitou (BULL) • Piero Lanucara (CIN) • Sebastian Wolf (TUM) • Stephan Jauré (BULL) • Vadim Monteiller (CNRS)
• Erwan Raffin (BULL)
Applications
- SeisSol : Sebastian Wolf (TUM)
- ExaHyPE : Mario Wille (TUM)
- Specfem3d : Vadim Monteiller (CNRS)
- Tandem : Alice Gabriel (LMU) - TBC
- HySEA: Jorge Macias (UMA) - TBC
- PTatin3d : Leatitia Le Pourhiet (SU)
- Xshells: Nathanael Schaeffer (CNRS)
Main points (see slides)
- Work package outlines
- Short terms activity
- Link with WP2, especially T2.1 (code audit): as POP not funded yet we should work with the application owner. An initial survey has been set up on application which include mini-apps existence for example. Next common actions to be discussed.
- Discussion around mini-apps identification and extraction, GPU, HBM and vectorization
Actions
- ChEESE-1P mini-app (mini-SeisSol, mini-SPECFEM3D (to update), mini-FALL3D): we can start gathering the needs regarding the software stack, including compiler toolchain, libraries, and its impact on the prototypes.
- ChEESE-2P mini-app (mini-xSHELLS, mini-HySEA, mini-Tandem and mini-pTatin3): Select a version of the code, associated relevant test cases (Small, Medium, Big), results validation
Q&A
- How to get a Roofline or arithmetic intensity?
→ With a tool like likwid for roofline portable solution and Intel advisor/vtune or by analyzing the algorithm
- question about mini-apps from Nathanael about CPU/GPU :
→ If GPU code is generic we can work with it, however if it is hardware specific((cuda/hip), better to work with cpu version (we can still play with gpu version)
- Question about portions of code which are memory bound, portions of code which are cpu bound
→ Analysis should be done on main hotspots hardware choice should consider application as a hole (tradeoffs)
- question about mini--apps from Laetitia about number of mini--apps
→ Focus on main hotspot, if a code may not have clear hotspots but may be a flat profile, in which case mini--apps could be developed by stripping code from IO and most dependencies