Comments (13)
Hi @swhite2401,
As I mentioned earlier we are working on this point for our implementation at ALBA. We are basically adapting @mashl version which for him is working. As I said before, my understanding is that the current GWigSymplecticRadPass is not accompanied with the corresponding additional files and modifications in the ohmienvelop.m function. I guess @ahmad should update his pull requests but he seems quite busy and actually I'm not sure his is reading this (despite my efforts).
In summary, in case it helps we will let you know if it finally also works for us.
Best,
Zeus
from at.
Thanks @ZeusMarti it is in fact excellent news that you are tackling this issue. The question is now whether we should disable this feature until a working solution is found or at least issue a clear warning message to prevent any confusion on the users side.
from at.
Hi @swhite2401,
As I mentioned earlier we are working on this point for our implementation at ALBA. We are basically adapting @mashl version which for him is working. As I said before, My understanding is that the current
from at.
I believe a warning should suffice, just in case my opinion counts.
from at.
Hello @swhite2401 and @ZeusMarti,
There are 2 problems with GWigSymplecticRadPass
:
- For tracking, the present implementation is wrong: it's missing the change in momentum. As it is, there is no momentum change due to radiation, which is obviously wrong. This is easy to correct, since
GWigSymplecticRadPass
is based on a drift-kick sequence in cartesian geometry, the same as what is used ifStrMPoleSymplectic4RadPass
. So all ingredients are available, - For equilibrium emittance, the problem is more general: unlike tracking, which is modular, the computation of the diffusion matrix is monolithic, done in
findmpoleraddiffmatrix.c
. This function is just an extension ofBndMPoleSymplectic4RadPass
, adding the propagation and increment of the diffusion matrix. A general solution consists in making this modular, and to avoid building a new family of specific functions, a proposed solution is to integrate the processing of diffusion matrices as an option in the existing pass methods. After the discussion in #715, a prototype of this big change is already available in the #742 pull request. It's fully functional, but such a big modification of the structure of AT deserves some discussion, so I don't expect the branch to be merged in a near future. As the branch is now,findmpoleraddiffmatrix.c
is replaced by something similar toat.c
, which distributes the task depending on the element passmethod. I encourage you to have a look at this branch.
For the demonstration, up to now only BndMPoleSymplectic4RadPass
, StrMPoleSymplectic4RadPass
and ExactMultipoleRadPass
have been adapted to propagate diffusion matrices (which is already better than the present computation). As I said above, GWigSymplecticRadPass
is based on existing integration steps, so it should be easy to adapt it. I'll be leaving soon up to the end of April, but I think I could have an upgraded version of GWigSymplecticRadPass
during May, if you are interested. But still a prototype for evaluation, while important design decisions will still have to be made.
After working a bit on this branch, I intend to post in a few days a summary of the remaining difficulties (mainly the "exact" passmethods), and of some choices to be made.
In the mean time, I can remove GWigSymplecticRadPass
and remove wigglers from the default elements switched on in "enable_6d". Or make the simple correction for momentum loss in the present version, forgetting the diffusion, but I'm not so motivated to work on something which should be replaced soon. Let me know…
from at.
Hello @lfarv, I agree that there is no need to put to much effort on something that will be replaced. For me adding a warning message is fine as well.
Just for my understanding, from previous discussion I thought that this element was also modifying dispersion which in principle is not supposed to happen in a wiggler, could you confirm this?
from at.
Just for my understanding, from previous discussion I thought that this element was also modifying dispersion which in principle is not supposed to happen in a wiggler, could you confirm this?
Sorry, but I can't remember that… Does this mean that GWigSymplectPass
(no Rad) would also be wrong? I was thinking of adapting it for radiation and diffusion, but I did not think of reviewing its basis…
For me adding a warning message is fine as well.
to @oscarxblanco and @swhite2401 : ok, but when should this message appear ? In Lattice.enable_6d
? And if so, should we keep wigglers in the set of elements turned on by default ?
from at.
I was thinking more in the C when the element is loaded in atpass but this is not necessarily the best option
from at.
Hello @swhite2401 and @lfarv,
I am Joan Arenillas and I am currently working with @ZeusMarti and @mashl on the implementation of wiggler diffusion matrices in ohmienvelope
. We are also implementing momentum change due to radiation in GWigSymplecticRadPass
, and are planning on presenting the new codes soon.
As @swhite2401 said in the first comment in this issue, there is a bug with atx
when using a lattice with a wiggler. In particular, the function atdisable_6d
removes the Energy attribute to every element in the lattice (we have tested this with the lattice of ALBA).
Could you please advise on how to tackle this issue?
Thanks!
from at.
Hello @joanarenillas and welcome!
I think there are several ways to go around this:
- You may get the ring energy accessible in the C through the param struct in the input arguments of the trackFunction. For information, the parameters available in this structure are in atintegrators/attypes.h
- In case you really want the energy to be a users input, i.e. an attribute of the element, it is a bit more complex. The wiggler element inherits from the _Radiative class (in elements.py). You can see there that set_long_motion will delete the Energy attribute when disabling the 6D motion. You may override this function in the Wiggler class with the proper behavior to keep the attribute Energy even with 6D disabled
Not sure if that makes sense... please let me know if you need more details or help. I can also look at your branch an comment directly in the code if this makes it simpler for you.
There might be other option I did not think of, @lfarv any ideas?
from at.
from at.
Dear @swhite2401 and @lfarv,
Thank you for your insights. The trackFunction in GWigSymplecticPass
and GWigSymplecticRadPass
were wrongly defining the energy from "ElemData", instead of taking it from "param struct" as you suggested. I will modify this in my branch.
I have noticed that all pass methods with radiation set the energy from the "param struct" in their Track Function (Matlab and Python) but instead take the energy from "ElemData" in their Matlab Mex Function. Is this difference some compiler requirement or should we maybe change this so both the Track and Mex Functions take the energy from the "param struct"?
Regards
from at.
Dear @joanarenillas , this is a good point. I think there is a historical reason to this: pass methods were implemented before the param struct was introduced.
You are right we may consider to clean this up. @lfarv , any objection? I think this is a good proposal.
from at.
Related Issues (20)
- pyAT Distinguish between a sector bending magnet and a rectangular bending magnet HOT 2
- Reduce behaves differently in Matlab and python
- B0 added twice in exactkickrad HOT 2
- python: ringparam not well identified by lattice_load HOT 6
- bug is saving lattice HOT 4
- problem with display of correctly initialised VariableMultipole element HOT 1
- Change Legend Labels for plot_trajectory() function HOT 12
- fast_ring when having harmonic cavities in the lattice HOT 4
- AT_2_Elegant uses deprecated N_KICKS
- Factor 4 missing in Touschek scattering B2 expression HOT 5
- pyAT Error when calculating damping ring HOT 3
- Rotation of dipoles HOT 18
- matlab atlinopt4 check on 6d is disabled
- Severe bug introduced by #766 HOT 2
- Bug in Lattice.avlinopt HOT 7
- ring.get_lifetime fails if list of reference indexes has only one valid element HOT 1
- Compilation error when building from repository HOT 27
- VariableMultipole Usage HOT 7
- Inherited fields don't exist unless first explictly set HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from at.