TouschekLifetime: machine vs model

[marlibgin]

This is a general question on how to use touschekLifetime in order to have a good match between machine and model.

I am using touschekLifetime after running momentum_aperture to calculate the lifetime of my machine. The goal is
trying to reproduce a real configuration of our storage ring (Diamond). So far I am off by ~10 hrs which is clearly a huge discrepancy
(LT_machine ~ 14hr / LT_elegant ~ 25hr). In the examples seen in this forum I can say that people just generate a Twiss file, a Mmap file
and put them as input of touschekLifetime with some added input to specify beam/bunch properties (sigma_z, emittance, coupling ... ). I state this because I can't find any effect added to the twiss file, e.g. magnet errors, orbit corrections, coupling corrections etc.

It seems all so simple but I could not get close to the machine lifetime, so I have tried to introduce magnet errors of all sorts, corrected the orbit, used skew quad to force the model have a defined coupling ~0.3%, increase number of turns for mom ap calculation etc. Yet this does not seem to produce a decent result at all.

My questions to the community are:
- How are radiation effects treated and how important are they? In my case SREFFECTS is placed just after the RF cavity, while I see other people
distribute them through elements (Bends, Quads ...)
- how well you manage to reproduce your machine measured lifetime?
- if the match is reasonable which tips you feel to give. Is there any issue that is particularly critical to ensure a good reproduction of your system?

Thanks very much for any feedback
Marco

[michael_borland]

Marco,

I think you should be able to get better agreement than that. We don't have a published comparison, but anecdotally, the agreement is within 10-20%. We also get good agreement going from MOGA to the real machine, in the sense of being able to improve the lifetime significantly.

We start by using LOCO to determine a "calibrated model," which reproduces the measured lattice. The tunes, chromaticities, and emittance ratio should agree between the measurements and simulations. (You might need to fudge the sextupoles a bit to get agreement on chromaticity.) Tracking with CSBEND, KQUAD, and KSEXT elements is required. If you know the multipole errors for your magnets, include those as well. (In our case, we know from experience that they don't actually matter.) Tracking should use the actual rf voltage of course, and you should track for several synchrotron oscillations. Presumably, that automatically ensures that you are tracking for a fair fraction of a damping time (e.g., 10% at least); if not, increase the number of turns.

Using element-by-element synchrotron radiation is best and shouldn't add much to the run time. If you go this route, set SYNCH_RAD=1 and ISR=0 (or ISR=1 and ISR1PART=0) on the CSBEND elements.

I hope this helps.

--Michael

[marlibgin]

Thanks Michael
I agree that the ultimate action should be a LOCO calibrated lattice, but this should just trim the result.
My case is outrageously wrong, so I first need to tackle something more macroscopic I believe.

I have ensured that tune, chro, coupling are in decent agreement with reality.
magnet multipole errors are inserted too, but as you say they should be negligible. RF is at the right voltage.
One interesting point you mention is related to the CSBEND, KQUAD, KSEXT elements.
These are in the initial lattice model, however, in order to tune the coupling I have introduced
96 skew QUADs (not KQUADs). Could this be a problem?

Thanks Marco

[michael_borland]

Macro,

Those QUAD elements *could* be a problem, since by default they'll be modeled with a second-order matrix. As you know, that can introduce all kinds of dubious effects in long term tracking. I'd try replacing those with KQUAD elements.

Also, how well do you know your bunch length and rf voltage?

--Michael

[marlibgin]

Thanks I will replace those QUAD asap,
I recall why I had introduced this. When I introduce errors on magnets (KQUAD) I involve the skew quad as well, but I fail to correct the orbit. I am not sure how to exclude the QSKEWs from the error assignment, I can suggest the following

&error_element
element_type=KQUAD,
name=!QSKEW
item=TILT,
type=gaussian,
amplitude=0.00016021,
cutoff=3,
bind=0,
fractional=0
&end

is the suggestion in red correct for the goal?

bunch length: for the test I am doing we indeed measured the b.l. with our streak camera, I cannot quote an error but I guess it's the best I could do
RF voltage: obtained from the control room data. Again, not sure of the error but I'd like to think we are pretty precise.

[michael_borland]

Marco,

The name=!QSKEW won't work, but you should be able to construct a wildcard string that matches the lattice quads without picking up the QSKEWs.

E.g, in our case I'd use

Code: Select all

name=S*[AB]:Q[1-5]

--Michael

[marlibgin]

Naive question on the use of name patterns with wildcards and my epic fails on the subject.

in momentum_aperture include_name_pattern allow to select a wide set of elements, in my case I want to select all the sextupoles in the machine so
include_name_pattern = TS*,
does the job, all the sextupoles being TS1A, TS1B, TS2A ... etc

in a similar way if I wish to select all the quadrupoles (Q1D,Q2D,Q3D,...) I do:
include_name_pattern = Q[1-3]*

The difficulty is in a combined selection of both the sextupoles AND the quadrupoles, something like
include_name_pattern = Q[1-3]*, TS*,

does not seem to do the job, it selects the quads only with no care for the sextupoles.
Thanks

[michael_borland]

Marco,

Alas, the wildcard feature on momentum_aperture isn't that smart. It only accepts a single sequence. We'll try to upgrade the wildcards in the next release.

You might be able to get what you want with something like

Code: Select all

include_name_pattern = [TQ][123S]*

One can also run elegant twice and then combine the output files

Code: Select all

sddscombine momAp1.sdds momAp2.sdds -merge -pipe=out | sddssort -pipe=in -column=s momAp.sdds 

--Michael

[marlibgin]

Nice, thanks very much I will try it asap

Another thing, related to the implementation of the LOCO calibrated model. I need to change something like 248 quadrupoles, what's the most effficient way to do it? I am trying renaming the single quads in the .lte file and then using a -macro inline input but I wonder if there is something smarter than that ...

[michael_borland]

Marco,

The best approach for importing strength settings is the &load_parameters command. The manual describes the format. You can also make one with the &run_setup parameters=<filename> &end field, then copy the pattern.

--Michael