Choose timezone
Your profile timezone:
BLonD code development meeting
→
Europe/Zurich
CERN
CERN
Video conferencing only
News
None
BLonD-common datatypes
Feedback (all) on datatypes usage
- Alex: datatypes is a good idea; several sections and several RFs to be seen
- Heiko: strings to qualify types not very clever/elegant; try to keep functions as generic as possible; important to have the structure for defining RF systems and momentum. OO is the way to go (except for simple things).
- Helga: user perspective - have either just generic or ALL data types specific; developer perspective: very simple parent classes, complex child classes with additional parameters; for tracking, should not need to define mass, charge etc. before defining Ring. Will need docs to understand code; rather confusing for now.
- Luis: can see the advantage of data types, but it's still confusing on how to use Ring object (kwargs). Simon: where and how to make the identification -- still sticking out.
- Markus: 110 m ring Kara modelling in 2 sections. No docs now, so getting the information on how to do the basic input is rather messy; tutorials for simple setups would be useful in the future. Liked that the total energy was passed and momentum compaction as a single number; code extended it automatically to multiple sections. RF: still figuring out how to input harmonics, voltages, phi etc. for multiple sections. Alex: should we have one programme per section or one implementation that handles it all? Helga/Simon: default should restrict the time base for different sections to be the same, as an expert option it could allow different time bases. Alex: BLonD design: as many RFStations as sections; with SR could define a section that has no RF kick -> Helga: empty RFStation is possible
- Ivan: (data, time) can only interpolate without knowing what is the data type; to convert, need extra information, already needed for the Ring -> conversion internally treated. For tracking, would use e.g. momentum programme
- Mihaly: makes sense the way it's implemented, old was too; read the EOM, and it was both intuitive, no strong opinion. Likes numpy arrays and duck-typing.
- Theo: feeling as a user: like to have generic functions defining before defining the Ring object
Helga: after listening to everyone, the code seems to be compatible with the wishes. In the use case of tracking, preference is to use generic input and specify other parameters at Ring definitions. For designing, want to have more specific functions. Good compromise to both.
Simon: could create a generic blond_function() that is then converted in the Ring object. Alex: why not use the parent _function()? Heiko: type printout gives momentum object even for what he thought was a generic object; a bit confusing
- BLonD_common: could take only synchronous_data keyword
- BLonD tracking could take momentum, energy, etc. as keywords
Simon: codimd example
- Possibility of having one constant and one time-varying voltage, for instance
- Using object rather than a function has some benefits
- Limited number of input types to be defined for Ring and RF (~10)
- Helga: RF frequency and phase slippage w.r.t. revolution frequency being reviewed now for OTFB/PL interaction; let's come back to definitions later on
- Open question: how to label and convert; many options for now, we should limit some options
- Split into: (0) generic type (i) momentum-type data, (ii) momentum compaction, (iii) voltage-type, (iv) phase and freq offset
- Alex: data type should handle input formats, Ring should align different objects
- Helga: consensus for now: (1) want to be able to mix constant with time-varying input, (2) for tracking, want to be able to have generic functions and define Ring with these
Heiko: pseudo-code
- Generic types, kwargs define the exact type
- Can interpolate, ask values at different times (or turns; turns requiring additional input)
- Allow the user to have different time inputs
- Conversion functions can be fully external and labelling could be done at this level
- Simon: advantage of having internal conversion is multiple sections; Heiko: this type of complexity should be covered by Ring
- Helga and Markus agree
- RF functions in terms of harmonic, voltage and phase, allowing time moments to be different for different harmonics -> singleRFSystem -> RFStation
- Alex: can combine two programmes without passing through singleRFSystem
- Helga: open questions: (1) shall we keep conversions inside data types? (2) multi-RF systems: to be split by singleRFSystem? (3) should the Ring be broken down to RingSection?
For next time:
- For tracking, have generic data types implemented and a tutorial
- First implementation of single RFSystem and RingSection
- Ivan: requirements/wish list for tracking and designing and try to find the common subset
- Everyone: please upload your code snipplets to indico
GPU implementation
Panagiotis
- GPU/CPU difference debugging -- problem in drift function using different solvers on GPU and CPU
- LHC input file running on GPU completely
There are minutes attached to this event.
Show them.