Choose timezone
Your profile timezone:
BLonD code development meeting
→
Europe/Zurich
CERN
CERN
Video conferencing only
News
- Discussion forum to be created on the new website to allow for questions on BLonD usage
Ring object common implementation
Alex
- Pass a programme: 3 options
- label via keyword argument
- allow also other types? time, data
- Several sections
- Section lengths as list
- Synchronous data as ring_program(data1, data2, …) for instance
- User should be able to define different momentum arrays per section; possibility to generate programmes if all sections are the same
- ring_program(): should the pre-treatment be a generic data treatment? or use
Simon
- Reminder of numpy array functionalities
- subclass of numpy arrays
- interpolation
- Ring parameters:
- have same length
- pre-processed to define the number of turns
- convert between energy/momentum etc
- RF parameters:
- different time arrays for different voltages
- reshaped after momentum pre-processing done
- Discussion: should the input be uniform and particular operations be done upon assignment? -> Majority prefers the data input to be the same independent of the input data type
- Momentum vs momentum compaction: should the two be separated?
- Built-in functions:
- pre-processing requires knowledge of data structure
- tagging or not?
Discussion:
- Alex: supports datatype, with class name
- role of Ring/RF object to shape and combine different data types
- Helga: can we find a compromise? Not excluding each other e.g. use generic data types and Ring/RF definitions for tracking; for pre-treating different programmes, use specific data types as alpha, voltage etc.
- Can we all experiment with the dataTypes for next time? Heiko: can we collapse the remaining options?
FOR NEXT TIME, EVERYBODY: experiment with a generic data type and specific subtypes; try to break the implementation and bring up questions
Panagiotis: FFTs on GPUs
- RFFT and iRFFT functions tested
- As the size of the problem increases, the speed-up improves; for 1 M data points, up to 50-60x
- Sampling sizes tried: output_size = 1/2, 1, 3/2 x input_size
- Full tracking EX1 (kick, drift, slice) in GPU
- voltage*charge, omega_rf, and phi_rf only transferred if changed by host
- slice requires transfer of macro particles to CPU for fitting
- with fitting, speed-up very small, 1.5-2x
- without fitting, up to 16x speed up for 16 M particles
- Kostis: could we see the CPU/GPU breakdown to see whether time is consumed in transfer or function itself
- Alex: can we make a GPU implementation of RMS and FWHM?
- Full tracking EX2 (total induced voltage, kick, drift, slice) in GPU
- with induced voltage and inductive_impedance <- uses derivative, which is not fully implemented in GPU => some transfer required for now between CPU/GPU, but will be avoided in the future
- speed-up of 5-8x, even with transfer
- Helga: use more “real-life” examples (PS, SPS, LHC) for next time
There are minutes attached to this event.
Show them.