BLonD code development meeting

Name: BLonD code development meeting
Start: 2022-09-23T10:30:00+02:00
End: 2022-09-23T12:00:00+02:00
Location: CERN

Friday 23 Sept 2022, 10:30 → 12:00 Europe/Zurich

CERN

Video conferencing only

93916228605

Helga Timko

Hide

Original model by Elena (2009), extended model by Felix (2022)
Peak-detected spectrum can be obtained from (i) profile, (ii) peak detector, (iii) synchrotron frequency distribution
For now, on Felix' fork, to be merged
Simulation model
- Take peak from within a window (modelling the Schottky diode) of the bunch profile
- Simplified circuit model for SPS and LHC
- Overview of PD Schottky Model() and Analyze() Modules implemented in BLonD
  - Using also utilities.py
- Example snippet
TODO: To be merged into BLonD master, within a new beam-instrumentation module

New CuPy BLonD implementation
Old GPU version repeated core functions in C++/CUDA, which is now not needed anymore
- Easier implementation, more code GPU-accelerated,
- Speed-up 23x w.r.t. 16-core CPU
For usage, use $ python blond/compile.py --gpu
- bmath module stores GPU and CPU globals dictionaries -> any function can be just called by bm.function_name()
- Example initialization
  - to_gpu() and to_cpu() functions that port arrays back and forth
Testing: on unittests (around 100 tests) and LHC, SPS, PS test cases
- Used AMD CPU vs NVIDIA V100, in double and single precision
Q: CuPy has an experimental backed for AMD GPUs, but the implementation has been tested on the CERN HtCondor
Q: How was it verified that the results are same as on the CPU? Within 8 significant digits, the results of GPU and CPU has been found equal - > both for unittests and integration tests
TODO: check failing unittests
Q: Time distribution similar in CPU/GPU, so speed-up seems to be general
- No GPUs available with MPI, but in HTCondor within a single node MPI (2/4 GPUs) could be used
- Mixed GPU/CPU version, where some core functions would be in CPU and some in GPU?
  - Transfer of data is sometimes an overhead, so some functions are kept on CPU
  - The others all benefit from GPU acceleration
  - For many million particles, MPI would be more beneficial
- Mixed CPU/GPU clusters are not envisaged at CERN in the near future, but GPUs will be more and more available

Implementing new code
- Just use CuPy to develop (or through CUDA and import)
- Register in bmath module to go back and forth from CPU/GPU
- Call your new CuPy function by some method and make sure that the arrays are transferred to GPU
  - Add your arrays in to_cpu() and to_gpu() functions
- See example
  - bm.use_gpu()
  - rf.to_gpu() etc. for all objects
New CuPy version a bit slower than heavily optimized CUDA version but much more maintainable and simpler to write
TODO: merge CPU/GPU versions into master
Q: CUDA version had architecture considerations, but CuPy does everything automatically? CuPy -> you cannot control it, it will automatically try to find the best configuration; if CUDA kernel available, sizes can be specified
Q: What is the easiest reachable GPU for access? HTCondor (or ml.cern.ch for notebook interface)

AOB

There are minutes attached to this event. Show them.