Use Cases

Use Cases: Tokamak edge physicist

They are early career, and to progress they need to build a professional reputation by publishing papers, supporting UKAEA’s research programmes and supervising students. They are a competent developer and experienced HPC user, though they do not gain any credit directly from developing software.

In their research work, they study different models for the tokamak edge, and so require code flexibility and a user-friendly DSL to allow them to rapidly prototype different equation sets. This work would require quick iterations – perhaps 5 minute simulations performed on a desktop. They will also develop their own algorithms and add infrastructure to the code. While they will do this with an understanding of performance implications, they would expect to perform these developments at a higher level that raw performance loops (but at a lower level than the physics model).

They would expect to contribute their changes back to a community repository, and also to benefit from changes that other code users have made. They would be involved in the community – perhaps raising issues, making and reviewing git pull requests, answering queries, and having input into future code releases – but would not be involved “project management” tasks, like maintaining the repository.

They will also value a user-friendly interface and active user community when it comes to working with their students. In this context it is valuable to have software that will run at a high level and produce sensible results without needing to specify the details of the implementation. This allows the student to learn about physical systems without simultaneously having to learn the details of numerical implementations. The active community allows their student to get support and ask (perhaps trivial) questions without being dependent on their supervisor.

Finally, in support of experiments, they will need to perform high-fidelity simulations of tokamaks. These will be highly computationally expensive, either because they are high-resolution simulations of specific shots, or because they are parameter scans or UQ campaigns. The simulations will be long-running, perhaps in the range of a week to a few months, on whichever HPC system that they have access to. The software must therefore be performance portable in order to facilitate high performance on a range of systems. The software also needs to be robust to numerical instabilities, hardware node failures, etc, as one may not have the resource allocation to repeat failed runs.

Use Cases: Engineers

As a thermomechanical engineer I:

  • • work with a large range of open source and proprietary codes which requires bindings to other tools, eg:̇

    • – FMU

    • – Python (Jupyter and regular)

    • – OptiSLang

    • – Twinbuilder

  • • work with CAD software to generate geometries which I want to propagate through my workflow.

  • • am interested in heat fluxes in all forms: from time and space averages to high resolution 3D time and data.

  • • need to be able iterate on designs quickly and in an automated way.

  • • am neither an HPC expert nor a plasma / tokamak physicist.

and I want to:

  • • know, given a sensible physics model provided by other experts, what the transient peak and average heat loads are on plasma facing components.

  • • not have to understand software dependencies and be able to install and run easily eg. “in the cloud”.

  • • be able to configure the software to undertake parameter scans.

  • • have a handle on the sensitivity of the solution to the inputs and sources of error / uncertainty.

  • • be able to re-use the spatio-temporal heat fluxes as a model in more thermo-mechanical calculations. This means:

    • – reading in the solution after the calculation.

    • – using a fit to the data in the form of eg. a reduced order model of the heat fluxes, surrogates etc.

    • – being able to export CAD geometries and import solutions back into engineering tools eg. ANSYS.

  • • have reproducible workflows to save and share with colleagues (eg. databases of inputs / outputs / config).

  • • export results flexibly to inter-operate with multiple surrogate frameworks.

  • • be in the loop with development process so it is possible to keep other workflows up to date.

This would mean I can:

  • • design components with colleagues within eg. STEP.

  • • make use of the NEPTUNE software in combination with proprietary tools that engineers know inside out.

  • • be insulated, to a sensible extent, from the complexities of the numerics, plasma physics and HPC.

Use Cases: Particle Specialists

As a particle specialist I:

  • • am very familiar with particle based methods.

  • • may not be familiar with FEM implementation details but have a working understanding of the approach.

  • • may not be familiar with low level languages.

  • • may not be familiar with HPC hardware and architectures.

  • • understand how to describe complex physical processes such as radiation, recombination, ionisation, charge exchange using both particle and FEM data.

  • • may not have applied UQ techniques before but may have an understanding of distributions/ensembles from statistical mechanics.

I want to:

  • • describe particle based operations both collectively and per particle, eg. :

    • – creation and deletion of particles potentially from complex distributions.

    • – computation with particle data - per particle and collectively.

    • – identification of groups of particles.

    • – representation of arbitrary per particle data.

  • • visualise particle and FEM data - snapshots and trajectories.

  • • create new finite element functions on appropriate function spaces.

  • • add source/sink terms to governing equations (solved with FEM).

  • • define particle source and sink regions using the simulation domain geometry.

  • • define regions of interest, eg. surfaces, as part of diagnostics.

  • • identify particles near surfaces/points/volumes of interest.

  • • create and use global data structures for computation, eg. diagnostics.

  • • represent particle data as FE functions:

    • 1. through pointwise projection.

    • 2. line integration over particle trajectory.

  • • use non-trivial functions in my loops, eg. erfc, gamma.

  • • define functions using expansion coefficients, eg. ionisation rate function approximated by an exponential expansion.

  • • evaluate these functions using both particle and FEM data.

  • • describe pairwise operations that implement physical processes.

  • • describe and sample from non-trivial statistical distributions.

  • • perform simulations in a reproducible manner.

So that I can:

  • • use particles as a kinetic description for plasma and neutrals.

  • • represent highly-collisional regimes by fluid approximations.

  • • describe plasma-neutral and plasma-plasma interactions.

  • • use abstractions/DSLs to write once, run anywhere as much as possible.

  • • experiment with models quickly and efficiently.

  • • perform ensemble computations and averages.

  • • perform UQ and verification.

Use Cases: Finite Element Background

I am a user with perhaps some grasp of plasma physics but with a more extensive knowledge of finite-element software (I might be an experienced user / developer of Nektar++). My background may be either physics or engineering; I may be a new recruit to the NEPTUNE team and needing to learn the code with a view to taking a future role as a NEPTUNE developer.

I need the interface / DSL to provide access to typical FEM parameters eg. choice of intra-element basis functions and their polynomial order, continuous / discontinuous Galerkin, choice of numerical flux, stabilization options; also whether diffusion and advection terms are explicit or implicit. In line with eg. Nektar++ I expect the choice of time-stepper to be largely “orthogonal” to most details mentioned above (the exception is explicit / implicit choice). I would like the option to specify the timestep in terms of the CFL number. In addition I require control over relevant meshing parameters eg. element spatial density and approximation order of any curvilinear elements. I would like the DSL to be able to generate a range of regular meshes internally (at least for trivial cases eg. boxes meshed with quads).

I should like some simple, physically-motivated canonical examples that might assist with learning plasma physics.

I expect the performance of the code to be at least commensurate with other FEM packages eg. Nektar++ and to remain so going forward (and obviously must be scalable to the latest hardware, which means foreseeably an efficient GPU implementation, supporting ideally NVidia, AMD, and Intel Xe / Ponte Vecchio).

I am unused to velocity-space effects. I would like the particles aspects of the code to be expressible, insofar as is possible, in FEM language: the conversion from discrete to continuum should ideally not be visible to me eg. converting particles to FEM forcing terms. Further to this, it would be good if a set of default particle parameters could be produced based on FEM parameters, as required (perhaps a reasonable value for the number of particles can be derived automatically based on FEM resolution).

If there is an issue from PIC compatibility (eg. constrained choice of basis functions), the DSL should make this clear in an explicit error message, plus hopefully advice how to remedy.