Neutral Gas Dynamics in the Edge: Guidelines for Code Leaning
This content discusses the code leaning process for the EIRENE-NGM module in E-TASC, focusing on modernizing the code for high-performance computing use, parallelization optimization, improved data collection, and interface with other codes. The main ideas include segregation of the core, universal parallelization, and HPC-conform interfaces. It also explores the use of new technologies like JSON input and HDF5 output, and debates OOP implementation. Various considerations such as OOP adoption, language transition, application case selection, and future extensions are addressed.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
TSVV Task 5 Neutral Gas Dynamics in the Edge EIRENE: guidelines for discussion on the code leaning D. Borodin et al.
From EIRENE to neutral gas module in E-TASC EIRENE EIRENE as NGM inside EUROFusion E-TASC - - - Solid math basis Well established code Strong AMNS data collection - Suitable for highly radiative divertor, huge amounts of cells, including photon-tracing and other effects Time-dependent mode Modernized code well suitable for HPC use. MPI- OpenMP parallelization with good weak scaling (GPU use may evolve with support from Hub) Revisited code structure including segregating of a compact core and domain decomposition Universal interface to other codes (IMAS-based) Improved A&M database more data, more parameters, more validation, more systematic, Numerical algorithms including FKH - - - A&M data and tools: AMJUEL,HYDHEL,H2VIBR, . . . - - Manual, visualization, Git repository - - - Interfaces to CFD codes: B2 (SOLPS), Edge2D, EMC3 - - Improved I/O (pilot TSVV): JSON input, HDF5 output New: portfolio of simulation cases with related catalogued central storage of runs and systematic CI cases D.Borodin | TSVV-5 VC#9 | 09.07.2021 | Page 2
EIRENE-NGM: code leaning For details see TSVV-5 FP-9 proposal: D1.a, D1.b, D4.a, D4.c, D4.d Code-camp like event is expected in Sep 2021 Main ideas: Segregation of the compact numeric core and starter/interfaces part The core should be free of any branching (geometry, specific parameters for the application cases etc.) core input should be minimized to really need to know . The core should be sufficiently flexible for domain decomposition and load balancing schemes; suitable for all variations of the code including FKH. Parallelization optimisation should be universal, probably with some parameters and clear procedures for their adjustment. Details are still under debate We need a strategy letting all other development to go in parallel Providing HPC-conform interfaces to the codes from the other TSVVs CFD-EIRENE from TSVV-3 (B2 as part of SOLPS) are first to go. EMC3 (3D!) is also very important to ensure the variability. Kinetic ions (tracked on EIRENE side), FKH, etc. may lead to challenges!.. Expertise and support from the ACH can be very valuable! Utilizing new programming/IT technologies JSON input and HDF5 output (future: parallel writing on HPCs?) Under discussion: using of OOP (modern Fortran or even C++?) D.Borodin | TSVV-5 VC#9 | 09.07.2021 | Page 3
Ideas for the code leaning (VC#7) a. Do we wish OOP?.. What will be the OOP concept of the code? Strategy for transition? b. Keep FORTRAN or move to C++? c. Selection of basic application case(s) for development d. Unit tests for particular modules?.. e. Convert part of the pre/post processing routines to flexible script high-level languages to avoid direct interaction of users with the core. f. Where and how to draw the line between the starter and the core?.. i. Precisely define the goals. Link the means and the goals. g. Naming conventions and other style issues h. Future extensions e.g. multiple particles? BGK?.. Note to keep the structure flexible enough. D.Borodin | TSVV-5 VC#9 | 09.07.2021 | Page 4
Shaping the code-camp-like event 1. It should be during 1 week (2 weeks), but not necessarily the whole day; in fact in case of virtual event morning/afternoon every 2ndday may be a good solution. 2. We still need to find the dates that will allow us to keep the focus; we should consider what else can be done for this purpose. 3. Long-lasting considerations should rather be completed before the event programming style and technology for instance. 4. We should select in advance the basis code version and application example(s?..) 5. We should provide, if possible, similar working environment/tools for the participants. 6. We should get a list of participants and discuss if necessary their roles. D.Borodin | TSVV-5 VC#9 | 09.07.2021 | Page 5
ACH supportbefore/during the leaning event 1. We should decide catalogue of runs, and documentation framework. 2. We should seek ACH expertise including direct participation in the discussions. This may include selection of tools, data formats, programming technology and even style. 3. We should take into the account IMASification and other standards imposed inside the E-TASC as well as actual and envisaged HPC requirements. 4. ?.. Populating this slide may be useful for further communication with ACH s D.Borodin | TSVV-5 VC#9 | 09.07.2021 | Page 6
Thanks for the attention! D.Borodin | TSVV-5 VC#9 | 09.07.2021 | Page 7
