Python Accelerator Middle Layer
Question for magnet in series and familly used for tune #10
Replies: 5 comments 48 replies
-
|
Dear @JeanLucPons, almost. |
Beta Was this translation helpful? Give feedback.
-
|
OK, so i should expect identical value for qf1/c29-e qf1/c30-a and this variation could be handled by applying strength proportionally to design strength ? |
Beta Was this translation helpful? Give feedback.
-
|
Or may be it is preferable to correct the tune correction matrix according to design strength ? If the FamName is not enough to handle this first use case, we have to restart a weekly specification meeting ! |
Beta Was this translation helpful? Give feedback.
-
|
In any case a set of quad in serie which is not in serie is not handled. >>> ring[3]
Quadrupole('QF1J', 0.403, 1.0905857563414754, Device='srmag/m-qf1/c04-a', FringeQuadEntrance=1, FringeQuadExit=1, NumIntSteps=20) |
Beta Was this translation helpful? Give feedback.
-
|
Dear Jean-Luc, for ESRF the family concept is not really used. In our tune example we will use all needed magnets independently, as we do today. I would not use FamName as refernce to determine if magnets are connected on a string and thus a family or not. EBS is an example of how this does not apply. It is also not how AT works (MADX instead has this constraint, the name, defines a family). The hardware name or the pyaml user defined arrays (new name for families) would be better. Taking your example, for EBS I would write: listing 62 magnets to create my tune correction array. A facility where all QD and QF are in series would simply write: As the elements srmag/m/qd2 determine a family. Also something like this should be possible Would this be possible in your opinion? |
Beta Was this translation helpful? Give feedback.
-
|
I don't think it is a good idea to try to have a 124x2 matrix to invert. It brings errors. The idea for general case would be rather to have: And then you average for the 2 families to get a 2x2 matrix. |
Beta Was this translation helpful? Give feedback.
-
|
I agree with @JeanLucPons to solve a system with 2 unknowns in theory we need only 2 variables so we should try to reduce the problem to that to make an exact inversion. There are 2 ways too do this: |
Beta Was this translation helpful? Give feedback.
-
|
I think we should perhaps think a bit longer about how to handle magnets in series vs individually powered magnets. At HZB we have individual names of the magnets but that doesn't mean that they are individually powered. pyAML needs to understand that if I make a change to one of the magnets all of them should be changed both in the simulator and in the live machine. This MML currently can't handle since there is no concept of power supplies and mapping for it only exists in the config for LOCO to be able to fit by power supply. MML also has what I think is a pretty ugly way to implement things like power muxer and shunts to be able to change quads individually for BBA when powered in series. Maybe if we in pyAML had a better implementation of power supplies than what MML has it would also solve the problem @JeanLucPons has? I'm also wondering why you want to calculate the tune response matrix in this way. Why don't do it like in MML and just run the measurement of the tune response matrix on the simulator? That seems to me like an easier path to later be able to add abstraction for the simulation engine in the future and we don't need a separate implementation for getting the simulated tune response matrix? |
Beta Was this translation helpful? Give feedback.
-
|
I agree with Teresia. This test case is already telling us a lot. For magnets in series, I think we could consider this solution (just a proposal). An element must corresponds to an hardware name and index in the model, configured somewhere.
For the tune configuration, then the element is already taking care of magnets connected to the same power supply or not and changes accordingly the correct indexes and polynomB/A fields in AT. I also agree about using the pyaml.model.design.quad.strength.set()/get() and pyaml.model.desgin.tune.get() to compute the tune response. It has also the advantage to bring the simulator features into the design of the tune correction test case. |
Beta Was this translation helpful? Give feedback.
-
|
Let me try an example to see if we are agree. type: pyam.magnet.sextupole
name: SFAM_0
unitconv: path/to/sfam_sext.yaml # A simple LinearUnitConv here
type: pyaml.magnet.cfm_magent
mane: SFAM_0
mapping:
- [B0, SFAM_0_H]
- [A0, SFAM_0_V]
unitconv: path/to/sfam_corr.yaml # A cfm unit conv with for instance 3 currents and 2 functions
type: pyaml.magnet.cfm_magent
mane: SFAM_1
mapping:
- [B0, SFAM_1_H]
- [A0, SFAM_1_V]
unitconv: path/to/sfam_corr.yaml # A cfm unit conv with for instance 3 currents and 2 functionsThen to change your sextupole familly you will have set SFAM_0 and the "_" becomes a semantical symbol. |
Beta Was this translation helpful? Give feedback.
-
I currently do something similar with MML together with a pyAT. In MML the mapping is also by index but it is set up when the config loads. So in the config I can use 'QF1*' and then let the code map the correct indices if the lattice file has changed. But that doesn't work well if the lattice is changed dynamically... It feels like it could be possible that someone might want to add markers, kickers etc in their scripts for simulated commissioning purposes. I like @swhite2401 suggestion of incrementing the FamName when loading. In that way it feels like we can generate unique identifiers from a lattice that doesn't have it. But maybe then we need to have some way to distinguish between a separate magnet and a sliced magnet because I think some also have this in their lattices files for handling slices? Another option I guess is that we introduce a standard for a pyAML lattice and we make it independent of simulation code. And then we separate the concern by adding translators for the different simulation backends we want to support where we put all the fixes to these problems? Added benefit I think could be that we for free can get an universal lattice translator which is a separate annoying problem our community has. pyAT already has it a bit now since it's able to load and save to different formats but there are also other projects where this has been explored. @PaulGoslawski had a student that made a translator which I think uses very nice concepts with a json schema for the standard and lark to parse the grammar. |
Beta Was this translation helpful? Give feedback.
-
|
The idea would then be to have something similar to the latticejson which describes the data models required by the pyAML lattice. And then we can translate to and from that format. Very likely we can just copy the data models that pyAT has but extend the identifiers to something better than just the FamNam field. |
Beta Was this translation helpful? Give feedback.
-
|
A new proposal with shunts. type: pyam.magnet.sextupole
name: SFAM
unitconv: path/to/sfam_sext.yaml # A simple LinearUnitConv here
type: pyaml.magnet.cfm_magent
mane: SFAM_0
mapping:
- [B2, SFAM_0_S]
- [B0, SFAM_0_H]
- [A0, SFAM_0_V]
unitconv: path/to/sfam_corrhv_with_shunt.yaml # A cfm unit conv with for instance 3 currents, 1 shunt, and 3 functions
type: pyaml.magnet.cfm_magent
mane: SFAM_1
mapping:
- [B2, SFAM_1_S]
- [A1, SFAM_1_SQ]
unitconv: path/to/sfam_corrsq_with_shunt.yaml # A cfm unit conv with for instance 2 currents, 1 shunt, and 2 functions
|
Beta Was this translation helpful? Give feedback.
-
|
@JeanLucPons Can maybe work. I need to think a bit more about the pros/cons vs the MML way with completely separate devices to give definite feedback. But spontaneously I like that you in this way in the pyAML config can see which magnets that actually have several functionalities. That is lost in MML. In this way I guess it would be possible with the same mapping to first consider the sextupole and corrector independent but later if you discover that they actually aren't you can change the model by just replacing which unit conversion to use? That I think would be really nice. |
Beta Was this translation helpful? Give feedback.
-
|
Hi everyone, I'm reopening this discussion due to a recurring issue we've encountered. To improve this, I propose delegating the linking logic between PyAML elements (referenced by name) and PyAT elements to a set of dedicated modules.
The module to use (including custom implementations defined outside This modular approach would make the mapping mechanism more flexible and better aligned with different use cases and naming conventions. |
Beta Was this translation helpful? Give feedback.
-
|
I'm starting the development by creating overridable modules. One of them will be used by default and will match the existing behavior. We'll develop the required evolutions from there. |
Beta Was this translation helpful? Give feedback.
-
This is why I would like to propose alias as in CATAP. In case of a simple magnet, today you are limited to have a single name which is the one defined in the lattice. |
Beta Was this translation helpful? Give feedback.
-
|
I agree that just using pyAT
I am not sure this is the good way to go. I think we need a unique identifier in pyAML which could be What is the reason for this choice? In your example it looks like it's a combined function magnet which has the same name for the two dipolar correction components. It could also be handled with a single pyAML object (Combined function magnet) with a single name but which has these two components? Like Right now, most of the possibilites listed in the "User Interface Specification" for the For example (from the spec document): |
Beta Was this translation helpful? Give feedback.
-
Yes it is a sextupole with 2 embedded H&V correctors. Edit: In case of non unique name, limitation of typed magnet array is only for configuration. |
Beta Was this translation helpful? Give feedback.
-
|
I created a new discussion to try to find an agreement on the way to identify a PyAML device. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
For the EBS tune we use QF1 and QD2.
sr.model.qtune.strength.set( [8 values] )
QD2A/E and QF1A/E will then be considered as magnet in series.
@simoneliuzzo
Will the above config will work with the code below ?
Beta Was this translation helpful? Give feedback.
All reactions