Architecture #12
Replies: 8 comments 55 replies
-
|
Then we also showed the suggestion we have from HZB. This is based on the architecture developed for our twin presented at IPAC25 so that's why it doesn't include all parts we want in pyAML (like e.g. yaml) but we think the overall concept can also be applicable for pyAML and would simplify the implementation. This is the high-level view of the different parts and how they connect together:
More details can be read in the IPAC paper but @Sulimankhail also has a peer-reviewed paper presented at a conference some weeks ago which has more details. It hasn't been published yet but it has been accepted with minor revisions so he can share the draft on request if you email him. That paper also includes an evaluation of the pros/cons of using these patterns. There is also a more detailed explanation of the liaison manager and the translation service which helped me a lot to understand it. The example is currently in the |
Beta Was this translation helpful? Give feedback.
-
|
I have some comments for @JeanLucPons proposal.
|
Beta Was this translation helpful? Give feedback.
-
|
I look at your branch and I still don't understand how you want to dynamically load external modules ? I recall that at the end we should be able to write something close to this: # Here, arrays of quadrupoles used for tune are in the config file.
# If a tunemat file is already present in data_folder, update_optics() invert it to get tunecorrectionmat
# if both tunemat and tunecorrectionmat are already there, update_optics() do nothing concerning the tune
import pyaml
sr = pyaml('sr.yaml')
sr.live.tune.get()
[76.1585, 27.3401]
# request tune variation
sr.update_optics(model) # Computes tune response from the model and saves files tunemat and tunecorrectionmat in data_folder if needed
sr.live.tune.set([76.25, 27.44]) # Add tunecorrectionmat*dq to quads
sr.live.tune.get()
[76.2505, 27.4398]Notes:
|
Beta Was this translation helpful? Give feedback.
-
|
It is not clear to me how the two proposals are related to each other. What are the advantages of one proposal over another? From what I see, the HZB version is a completely different way of doing things. I don't even see where the elements are in an HZB proposal. For example, where would a betatron tune monitor be in this scheme? You send a command to make a tune measurement / read a tune value from a device / calculate a tune from the lattice? And do a whole measurement execution engine to read a value from the control system? |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
Thanks Vadim. 👍 |
Beta Was this translation helpful? Give feedback.
-
|
Dear all, it is very good you are having this discussion and I can see that it goes in the right direction, however, if I may I would like to suggest to keep discussion on project organization outside of github and use this repository only for the technical aspects of the projects. |
Beta Was this translation helpful? Give feedback.
-
|
We close this discussion because now there are two separate discussion for the architecture proposals. |
Beta Was this translation helpful? Give feedback.




Uh oh!
There was an error while loading. Please reload this page.
-
After talking to @JeanLucPons I have started this discussion about the architecture so everyone who wasn't on the last maintainers meeting also can see the slides.
These are the slides Jean-Luc showed for the current architecture:
Beta Was this translation helpful? Give feedback.
All reactions