BLonD code development meeting

Name: BLonD code development meeting
Start: 2020-04-24T10:30:00+02:00
End: 2020-04-24T12:00:00+02:00
Location: CERN

Friday 24 Apr 2020, 10:30 → 12:00 Europe/Zurich

CERN

Video conferencing only

Hide

For tracking: Input parameters (momentum, voltage etc.) need to be known beforehand
Preparation e.g. of momentum program: should be done by design application
- E.g. for FCC from energy, with parabolic-linear-parabolic programme
- Simon: need also information about acceptance, alpha, etc. for really designing the momentum programme
- Designing RF programme also requires multiple input parameters
- Some cases can generate e.g. from harmonic the voltage (assuming constant bucket area)
  - Could have more minimalistic RFSystem input (dummy objects)
Alex: comments
- In the proposal of June 2019, the structure proposed was preliminary; changes should be adapted now
- Input parameters: Ring and RF as in tracker (full set of parameters)
  - But for design, one doesn't need so much input -> some minimalistic objects needed in there
  - Use input parameters from the common toolbox for instance
Simon agrees; e.g. designing momentum fits nicely into present design approach

Consensus: have a generic data programme
Construct the RFStation: (1) voltage, harmonic, phase (and frequency) -> (2) single RFSystem -> (3) full RFSystem with vector sum -> (4) RFStation
- For tracking: have shortcuts from voltage to RFStation (if single-value voltage) or single RFSystem to RFStation
- Markus: naming confusing
Consensus: agree on structure to build an RFStation; the naming convention needs to be reviewed
Constructing the RFStation:
- RFStation(Ring, RFSystem1, RFSystem2,...)
- RFStation(Ring, voltage=voltage, harmonic=harmonic,....)
- Helga: do we want to be able to access from RFStation backwards all the subclasses, or do we just want to know the voltages for different harmonics etc?
- Simon: classmethods would be ideal to initialise the object based on different inputs; direct input of single-value voltage into init()
  - Markus: would be confusing for init()
  - Helga: initialize empty RFStation and use (exclusive) classmethods for all different inputs
Constructing the Ring:
- RingSection(momentum, alpha)
- Combine RingSections to Ring
  - Direct input as default? Or same solution as RF?
  - Helga: difference is that empty RFStation has a usecase, but empty Ring does not
  - Markus: Ring has simpler cases
Consensus: build the subclassed structure for Ring and RFStation
- Defaults for now: simple Ring, empty RFStation
- Naming proposals for next week, please!

Bucket object changes
Frequency distribution for the bucket
- Ivan: naming frequency spread (single number) vs distribution

Helga: pull request on SPS OTFB upcoming

What is the trade off between precision and performance when using single vs double numbers?

Single precision: 6-9 significant digits
Double: 15-17 significant digits
For many applications in our code, cannot guarantee a better precision than 7-9 digits anyway
- Physics approximations, compiler used, scipy version used etc.
- Should compare this to the accuracy loss due to single-precision numbers
Two versions of C++ routines
- Can invoke on runtime any of the two; handled by Python
  - Making sure that inputs are correctly passes using as_type()
- Duplicated code, for flexibility
- Could change type in header, but then the compiled version is either single or double
Kick, drift, histogram simple example (EX1)
- Will benchmark more realistic cases, for longer amount of turns later
- 2000 turns in this example
- Accuracy goes up then down, but doesn't seem to have a physical meaning
  - Max. accuracy loss: 1 %, not bad, and almost twice as fast
  - Markus: try with constant momentum, to make sure there are no losses
Promising: could gain runtime for large scans with small accuracy loss
- Could be exposed to users in the future
- If only one version would be available, would have to recompile every time

LHC: 250,000 particles/bunch, PS: 1 mio particles/bunch. 2000 turns of tracking

LHC speed-up ~2-3 over 2-128 bunches
PS speed-up ~2.5-3
Profile and tracker are faster on GPU, but the induced voltage calculation is actually slower
- Looking into why the FFTs are so slow
  - Helga: maybe problem size too small for the GPU?
- All operations on GPU during tracking, without interactions
Initialisation not accounted for in the speed-up
Test to be repeated on a reliable machine (this test was done on a PC)
- Breakdown of runtimes for different functions to be done

Next meeting: next Thu pm

There are minutes attached to this event. Show them.