search

blond-org / blond_common

Collection of common functions and interfaces
GNU General Public License v3.0
3 stars 5 forks source link

storing predicted/desired emittance value and beam parameters #33

Open scpalbright opened 4 years ago

scpalbright commented 4 years ago

In the context of BLonD_Design I need to have a sensible place to store the predicted emittance of bunches along with various other parameters like bunch length and position in the ring. In LoCa I've been doing this in an object similar to the RFSection object, but with a lot more and different functionality. However, I don't think adding it to the RFStation is a good solution, as it could add a lot of overhead that's not needed in some places.

What I propose is a new object for storing and calculating beam parameters as part of the interfaces.beam package. This would take Ring and RFStation as inputs and calculate parameters at specified turns/times.

In the context of BLonD_Design I'd define the required longitudinal emittance along the ramp, I could see it being useful in the context of BLonD_Data to compare measurements with analytical predictions. I could imagine it being useful in the context of tracking as well, depending on the functionality included.

For now I propose starting a interfaces.beam.beam_parameters module. If there's no objection to the concept I'll start on this tomorrow and then we can discuss what should/shouldn't be included in the future.

scpalbright commented 4 years ago

After yesterday's meeting, I'm wondering if the beam_dynamics package (where I've put the bucket object) could also contain the beam_parameters object. And maybe beam_dynamics can be a subset of interfaces, as the input_parameters and impedance are now.

htimko commented 4 years ago

I propose we review the overall BLonD-common structure and its the naming conventions in detail in next week's meeting. Personally, I find the naming "beam_dynamics" not very intuitive; in the wider sense, all we do is beam dynamics. What type of classes precisely do you plan to add in this package in the future? Could we find a more speaking name?

Looking at the content as is right now, having "bucket" inside the rf_functions appears more logical (at least to me).