General
Add docs and developer info to new website
BLonD-common
Helga: Abstract toy model
- Keep data type common for Ring and RF
- Common Ring, inheriting RingTracking, RingDesigning
- RFSystems in RFStations?
Alex: Codimd for Ring object
- same data_type object for Ring and RF
- synchronous data type via key-word argument? => kwargs PREFERRED (consensus)
- conversion functions automatic if input data is tagged
- if not tagged, can call conversion by hand
- Simon/Heiko: can input a single number or a numpy array for simple cases; no need to define an object => SIMPLE CASES SHOULD BE INTUITIVE FOR USERS (consensus)
- YAML input? Helga: might be too ambiguous
- Heiko: input data_program(data, time=time) and tag it when inputting to Ring
- Simon: don’t want to discard the numpy array direct input option -> TO BE DISCUSSED NEXT TIME
- KEEP OPTION C of codimd (consensus)
- Markus: use a single input type for clarity
Kostis: Synchrotron Radiation Implementation
- Unittests have 1 % difference between C++/Python implementations
- Statistically the same, but different random number sequences
- Seed option now available in both
- MPI issue with multi-bunch distribution
- Problem with profile.reduce() before beam.split()
- Now beam object knows whether in reduced mode or not => no flag needed
- - Improved MPI testing
- Skip MPI tests if MPI not installed
- validate_mpi.py comparing MPI and regular BLonD outputs
- time limit -> some examples (integration tests, not considered in coverage) are skipped, check with Helga
Panagiotis: GPU implementation
- moving data between CPU/GPU being investigated
- FFT, tracking etc. all done on GPU
- single transfer at the beginning/end of simulation -> should be investigated first (no interaction with tracking block)
- keep ratio of macroparticles/slices constant for scaling
- complex simulations being assembled
- beam object functions implemented in GPU
Next meeting exceptionally on Thursday
There are minutes attached to this event.
Show them.