CPP activities

1. CPP activities Outline: • Objectives • Members • CPP path • Activities status • Improvements • What’s next

2. CPP: objectives Goals: • Provide tools for integrated simulation of magnetic confinement fusion devices: framework/simulator/toolkit • Interfaces for the codes & data (with DCP) • Codes management: version handling, … Constraints: Time schedule October 06 Delivers a framework for the Fusion simulation project

3. Members 17 members • labs 3 ppy

4. CRONOS, ASTRA, JAMS Resources New technology Survey Long lasting architecture HPC Integrated Modelling XML, WS, ESB GRID Min. requirements Components, layers new requirements EU-US Web Existing frameworks Requirements Frameworks evaluation Choose a framework CPP path Code interfaces

5. Activities status Requirements Resources Existing frameworks Framework evaluation Code interfaces GRID Version handling, …

6. Last ITM-TF meeting (27 Oct) • 3rd draft • Improvements: documentation, clarification of the Code interfaces, tests, form • December • Call for participation Requirements

7. End User • Tools to define the simulation • Tools to run & monitor the simulation • Tools for post-processing • Developer • Integrate the codes • Debug & test • Administrator • Deploy the simulator • Monitor it • Manage the archive • Additional constraints Requirements

8. User requirements Codes scheduling Data

9. Example: geometry Requirement: define the geometry • Load the 3D files corresponding to the Tokamak and visualize them. • Do not intend to replace the CAD tools => geometry, materials, 3D display Constraints • The CAD files use various standards: Catia, VRML, Euclid, IGES, STEP, …. Consequences • Standard names, repository for the catalogues • The geometry tool must be able to read these CAD formats remotely

10. Example: workflow Requirement: define the workflow and the state-flow • Tool to assemble the codes (branch, loop, …). The codes could be remotely available. A graphical tool and a command line interface must be available. Component catalogues Components/codes

11. User Do a simulation Post-processing

12. Requirement: a DVD player-recorder • Functions similar to a DVD player User: do a simulation start pause fast forward backward abort Interactive mode is mandatory. The batch mode is also necessary Fast forward is used to give a glance at the full simulation (This mode is probably not applicable to any simulations: Monte Carlo, … It deserves further investigations) During the pause mode, the user is able to change a few parameters (add new components, change the chronology, …) Backward mode at least for a few time steps, could be an interesting option Automatic backup. Useful for the long run simulation when periodic checkpoints are mandatory Multi-run mode. In case of exploration of a large parameter set

13. User: monitor the simulation Requirement: monitor the simulation progress • A graphical tool is used to display the timeline and the component scheduling => components are able to send data to monitor their activities status time resources Interactive mode is mandatory

14. Developer Codes written in C, F77/95/.., C++, Matlab, IDL, Java, … Standard interface & simple => component (setService or getService) Requirement: use a component template • A template must be available for each language: C, C++, F77/95, … • Set of methods: • init: • doIt: run one time step • doItFast: simple version of doIt • rollback: one time step backwards • abort: • …

15. Administrator

16. Non-functional requirements

17. Simulation of a minute of an ITER heated discharge: Equilibrium 60 10  20 ~ 12 Tflops Linear MHD (non-resistive): 60 10  90 ~ 50 Tflops Core confinement: 60 0. 150 ~ 9 Tflops. Non-thermal ions: 60  5 ~ 300Tflops. H&CD source terms: 60  10  20  0.06~ 700 Tflops In total: ~ 1000 Tflops for 1 minute simulation On a typical workstation of 1.0 Gflops/s, this translates into about 11 days of CPU. Resources ITM estimation 2005 GRID, MPI, … • Gyrokinetic simulation: • Mesh: 512 512  256 x 64 x 10 • 4000 processors • CPU: more than 50 days • Memory: 1TB • Files: 700GB • 3D visualization: 200GB FSP 2002 final report

18. Existing frameworks

19. Possible test projects: • 3D views of the Tore Supra pumped limiter • Goals: Useful for TS, coupling to an existing simulator (CRONOS) , 3D visualization, CAD input files, data & parameters access • Don’t validate fully the framework • Integration of codes (IMP#1, IMP#5) • Goals: code => component, workflow, data access Framework evaluation To be discussed at this meeting

20. code code data data Code interfaces Communications between codes and also with the framework: • Call • Data transfer framework Universal access layer

21. Communication Will be discussed in the “Code interfaces and Code Platform” session

22. GRID Working with the GRID community: • EGEE-II: CERN (M-E Begin, B.Jones), CNRS (Wormser), CEIMAT (F.Castejon), Kurchatov Institute (I.Semenov), CEA (B.Guillerminet), … Meeting at Pisa (26th October) • DEISA: IPP Garching (?), CEA (V.Grandgirard) CPP goals: • Standards? • Requirements for the frameworks, for the user code Objectives: • Must be included in the ITM

23. Improvements Communications: • IM: Jabber? • Forum Who will do the job: • Up to now: periodical meetings at Cadarache + balloting draft (sequential work + local people) • Call for participation • // works: see next slide • Support for reporting

24. Works must be done in //: • Code interfaces • Tests of CCA, ESB, … • GRID • Requirements, tests • Requirements improvements • Interfaces, needs for heating systems, … • Send the requirements to the framework providers • Frameworks evaluations • How to do them • Install & test a few frameworks/toolkit What’s next