-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New Lattice properties: energy, harmonic number and particle #329
Conversation
@lfarv, since we are talking about non-relativistic particles etc... do you think it would be worthwhile introducing a beam object that would handle and carry the particles, each particle could then have its own properties such as mass, charge, coordinates, etc... |
@swhite2401: this looks much more ambitious than what is proposed here ! Why not, but I don't think it interferes with this PR: most of it deals with handling of harmonic number and code cleaning of the Lattice object. The introduction of the Particle object is straightforward, and the only missing part to handle non-relativistic particles is a modification of RFCavityPass, which is a minor point (though I have trouble with it at the moment). Such a beam object would come on top of that, with several options for tracking: either track separately the different ion species, or heavily modify the tracking engine to add mass and charge as additional coordinates, or as additional variables… This needs to be carefully imagined, including the use case: AT is restricted in magnets to small angles and deviations, it's not meant to design spectrometers… |
Absolutely, it was just a suggestion! this PR is perfectly fine for me. |
@lfarv , I started using this branch for some other development and realized I went through this one a bit too fast: |
Also I think |
I am working on an improved |
I agree that the frequency is a cavity property, however for modifying the frequency on all cavities in one shot, I do not see any other possibility than applying it to the ring ! Now for the naming, I just follow the common practice of having getter and setter methods prefixed with 'get_' and 'set_' and the corresponding property without any prefix.
Same answer as above: to be consistent, same convention (except there is no setter function). And yes, they should give the same result, unless I left a bug… In all cases, it's true that the property does not bring any new functionality compared to the methods, it's just more convenient is most cases (when using the default arguments). And you are free to ignore them if you prefer the methods. |
Again for multiple RF systems the logic is broken as there is no single frequency and this is misleading for standard user that did look at the source, I would keep only the getter and setter which are unambiguous. As for |
In principle, that's true. But setting the frequency needs to know the revolution frequency. And I could not keep the revolution frequency in the Ok for improvements, but keep the interface clean: having both |
Ok then I propose we merge this one as is, because it is fine for the moment, then we can continue the discussion when I have something to propose. |
Do you really think that a statement like: For multiple RF systems, the
No, you don't miss anything: the property corresponds to the default arguments of the method, as usual. In both cases, the meaning of the property is so obvious that I do not see how it could be interpreted other than what it says. |
@swhite2401: do you think it's worth moving the |
Definitions are clear, I think what confused me is that the property is defined in one place and the getter somewhere else, I'll think about it...as I said lets merge this one as is. More to come on RF tuning... |
Good idea, I just looked at it. The problem is that the |
Ah too bad...so in this case do we really need the harmonic number to be defined at initialization of the Lattice object? We may as well define getter and setter in |
@lfarv can you merge this one? Anything blocking it? I would need it for other devs... |
@swhite2401 :I'm planning to implement the move of |
Following discussions in #319, it appeared that the harmonic number of a ring should be better defined as a Lattice property rather than a RFCavity property. More generally, this PR will add these 3 items to the Lattice properties:
The
harmonic_number
is used to set the RF frequency.At the moment, no modification is made on the way the Element properties are handled: the
HarmNumber
field of cavities is ignored, but theEnergy
field is still necessary and used by the tracking in cavities and radiating elements. The new lattice properties are ready and should be used instead in the future, but this will require modifications of tracking.A
Particle
is defined by a name, a rest energy in eV and a charge in elementary charge unit. At the moment, only the 'relativistic' particle is allowed: it has a charge -1 and a rest energy of zero, so its relativistic beta is always 1 which is at the moment the only allowed value for tracking. So any attempt to select another particle raises an error. Tracking of non-relativistic particles is foreseen in the future.All this required simultaneous modification in many modules, for both python and Matlab. In particular, loading, saving and importing lattices had to be upgraded so that compatibility with existing files is ensured, while newly created files will contain the new information.
So here are the main changes:
python
The standard Lattice properties are now:
name
,energy
,periodicity
,harmonic_number
,particle
.When building a lattice, the search for these properties is done in the following way, by decreasing priority order:
energy: input keyword argument, then
Energy
field of the "main" cavity (see below), thenEnergy
field of any other element. If energies of different elements are inconsistent, a warning is emitted. If no energy definition exists, an error is raised.The "main" cavity is the cavity (or cavities) with the lowest frequency.
Harmonic number: input keyword argument, then
HarmNumber
field of the "main" cavity, then frequency of the "main" cavity divided by the revolution frequency. If no definition is found (no cavity in the lattice for instance),harmonic_number
is undefined.Particle: input keyword argument, and then defaults to 'relativistic'.
When loading a file, the missing data (in an old file) will be deduced by applying the same search rules.
The 5 properties may be freely modified on an existing lattice.
To be consistent, the harmonic number access is removed from the
set_cavity
method.Matlab
The modifications are more important since there is no Lattice class in Matlab. As previously, the lattice properties are stored in a
RingParam
element, and are handled by the upgradedatGetRingProperties
andatSetRingProperties
functions. The standard list of properties is now:FamName
,Energy
,Periodicity
,HarmNumber
,Particle
.atGetRingProperties
handles properly missing or incompleteRingParam
elements by applying the search rules described above for python. It is now much more efficient by storing the location of theRingParam
element for faster access. If there is noRingParam
element, a warning tells that the function is much slower because it needs to scan the whole lattice.atSetRingProperties
creates theRingParam
element if it is missing, or upgrades it if necessary, for instance after reading an old file. It also provides an easy way to create or upgrade an incompleteRingParam
element with the simple commandring=atSetRingProperties(ring)