First-order corretion of chromaticity and multiple error

[gwei]

Hi, all.

From the manual and example of ELEGANT, I learned how to make correction of linear chromaticity.
And for a collider, usually First-order corretion of chromaticity is needed at IP, like W function in MADX.
The W function: W=SQRT(a^2+b^2),
And b=1/beta * d(beta)/dp ; a= d(alf)/dp - alf * b;
So my first question: Do we have w function in ELEGANT? And how to make correction?

And it seems there only 8th order of multiple error for dipole in ELEGANT.
my 2nd question: Do we have methods to deal with 9th and 10th order of multiple error of dipole?
Because for my lattice, we use a super-conduct dipole with 9th and 10th order of multiple error.
It seems not so large. But I want to make a study if there is a chance.

About the multiple error of quadrupole and sextupole.
I read them from sdds files into a lattice file. When I do many processes, I write a parameters file as shown in orb_corr.ele, like model.param0.
Then my 3rd question: how can I find those multiple error of quadrupole and sextupole in the parameters file? especially random error.
And my 4nd question: does the multiple error of quadrupole and sextupole automatically works without any switch command? like
USE_BN to switch on the function of multiple components of dipole?

With best wishes!
Guohui Wei

[michael_borland]

Guohui,

From the manual and example of ELEGANT, I learned how to make correction of linear chromaticity.
And for a collider, usually First-order corretion of chromaticity is needed at IP, like W function in MADX.
The W function: W=SQRT(a^2+b^2),
And b=1/beta * d(beta)/dp ; a= d(alf)/dp - alf * b;
So my first question: Do we have w function in ELEGANT? And how to make correction?

There's no built-in function for this, but you can compute it yourself from the quantities betax, betay, dbetax/dp, dbetay/dp, dalphax/dp, and dalphay/dp. These values hold at the start/end of the beamline, so the IP needs to be at the start of the beamline.

And it seems there only 8th order of multiple error for dipole in ELEGANT.
my 2nd question: Do we have methods to deal with 9th and 10th order of multiple error of dipole?
Because for my lattice, we use a super-conduct dipole with 9th and 10th order of multiple error.
It seems not so large. But I want to make a study if there is a chance.

I will look into this. As the order goes up, so does the complexity of the expressions and the time required to evaluate them; I want to ensure the code doesn't get too slow.

About the multiple error of quadrupole and sextupole.
I read them from sdds files into a lattice file. When I do many processes, I write a parameters file as shown in orb_corr.ele, like model.param0.
Then my 3rd question: how can I find those multiple error of quadrupole and sextupole in the parameters file? especially random error.

Unfortunately, those errors are not logged. Also, since there is no parameter of the KQUAD or KSEXT element that corresponds to the particular value of a multipole error, you won't find it in the parameters file. I'll think about how to add logging of the errors.

And my 4nd question: does the multiple error of quadrupole and sextupole automatically works without any switch command? like
USE_BN to switch on the function of multiple components of dipole?

The multipole errors for KQUAD and KSEXT are generated whenever the SYSTEMATIC_MULTIPOLES or RANDOM_MULTIPOLES fields are given values. One pitfall: in the multipole input files elegant uses "bn" to mean skew components and "an" for normal, which is the opposite of the normal convention. For this reason, I suggest using "normal" and "skew" as the input file column names. This avoids any confusion.

--Michael

[gwei]

Guohui,

About the multiple error of quadrupole and sextupole.
I read them from sdds files into a lattice file. When I do many processes, I write a parameters file as shown in orb_corr.ele, like model.param0.
Then my 3rd question: how can I find those multiple error of quadrupole and sextupole in the parameters file? especially random error.

Unfortunately, those errors are not logged. Also, since there is no parameter of the KQUAD or KSEXT element that corresponds to the particular value of a multipole error, you won't find it in the parameters file. I'll think about how to add logging of the errors.

And my 4nd question: does the multiple error of quadrupole and sextupole automatically works without any switch command? like
USE_BN to switch on the function of multiple components of dipole?

The multipole errors for KQUAD and KSEXT are generated whenever the SYSTEMATIC_MULTIPOLES or RANDOM_MULTIPOLES fields are given values. One pitfall: in the multipole input files elegant uses "bn" to mean skew components and "an" for normal, which is the opposite of the normal convention. For this reason, I suggest using "normal" and "skew" as the input file column names. This avoids any confusion.

--Michael

Thank you for your kind reply.
And for the RANDOM_MULTIPOLES of KQUAD and KSEXT, if I don't write "random_number_seed = 0," in the &run_setup, the random value will
keep the same when I do another process by &load_parameters and using the same lattice? In the situation of orb_corr.ele I uploaded, Is it right?
Because I need many processes to do orbit correction, twiss matching, and chromaticity correction, I want to keep the random value of KQUAD
and KSEXT always same in those processes.

[michael_borland]

And for the RANDOM_MULTIPOLES of KQUAD and KSEXT, if I don't write "random_number_seed = 0," in the &run_setup, the random value will
keep the same when I do another process by &load_parameters and using the same lattice. In the situation of orb_corr.ele I uploaded, Is it right?
Because I need many processes to do orbit correction, twiss matching, and chromaticity correction, I want to keep the random value of KQUAD
and KSEXT always same in those processes.

Yes, that's right. By default, the "random numbers" are deterministic in that the seed is fixed.

--Michael

[gwei]

And for the RANDOM_MULTIPOLES of KQUAD and KSEXT, if I don't write "random_number_seed = 0," in the &run_setup, the random value will
keep the same when I do another process by &load_parameters and using the same lattice. In the situation of orb_corr.ele I uploaded, Is it right?
Because I need many processes to do orbit correction, twiss matching, and chromaticity correction, I want to keep the random value of KQUAD
and KSEXT always same in those processes.

Yes, that's right. By default, the "random numbers" are deterministic in that the seed is fixed.

--Michael

By default, the "random numbers" is 987654321 in the manual. Then for RANDOM_MULTIPOLES of different KQUAD, different steps, it will change.
And for RANDOM_MULTIPOLES of KSEXT group, random of misalignment species, the "random numbers" will return back to 987654321
at the first random error element for different species. Is it right? I mean the "random numbers" for different error species are independent and
start from 987654321 if default.

[gwei]

Guohui,

From the manual and example of ELEGANT, I learned how to make correction of linear chromaticity.
And for a collider, usually First-order corretion of chromaticity is needed at IP, like W function in MADX.
The W function: W=SQRT(a^2+b^2),
And b=1/beta * d(beta)/dp ; a= d(alf)/dp - alf * b;
So my first question: Do we have w function in ELEGANT? And how to make correction?

There's no built-in function for this, but you can compute it yourself from the quantities betax, betay, dbetax/dp, dbetay/dp, dalphax/dp, and dalphay/dp. These values hold at the start/end of the beamline, so the IP needs to be at the start of the beamline.

--Michael

I find dbetax/dp, dbetay/dp at the end of the beamline in *.twi, but no dalphax/dp, and dalphay/dp.

[michael_borland]

Guohui,

Yes, unfortunately it isn't in the twiss output file for some reason, but you can use it in optimization terms (optimization_term command).

We'll get it in the twiss output file in the next release.

--Michael

[michael_borland]

And for the RANDOM_MULTIPOLES of KQUAD and KSEXT, if I don't write "random_number_seed = 0," in the &run_setup, the random value will
keep the same when I do another process by &load_parameters and using the same lattice. In the situation of orb_corr.ele I uploaded, Is it right?
Because I need many processes to do orbit correction, twiss matching, and chromaticity correction, I want to keep the random value of KQUAD
and KSEXT always same in those processes.

Yes, that's right. By default, the "random numbers" are deterministic in that the seed is fixed.

--Michael

By default, the "random numbers" is 987654321 in the manual. Then for RANDOM_MULTIPOLES of different KQUAD, different steps, it will change.
And for RANDOM_MULTIPOLES of KSEXT group, random of misalignment species, the "random numbers" will return back to 987654321
at the first random error element for different species. Is it right? I mean the "random numbers" for different error species are independent and
start from 987654321 if default.

Sorry, I didn't see this before. There are four random number sequences in elegant: beamline errors (including multipoles), scattering (radiation, IBS, etc), diagnostics and control (bpm noise, feedback), and beam generation. In general, the random numbers are seeded once at the beginning of every run. So each instance of KQUAD or KSEXT will get different values for the random multipole components. The random number sequences are not independent.

One exception is during optimization, where the user can request that the random number seed gets reset before each function evaluation. This is done with the restart_random_numbers control of &optimization_setup.

--Michael

[michael_borland]

In updating the code to supply dalphax/dp and dalphay/dp to the twiss output file, I realized that the value being provided for optimization of dalphax/dp was incorrect (it is actually filled with dbetax/dp). This will be fixed in the next release.

If you build from source, the attached file can be used to provide the fix.

--Michael

[gwei]

In updating the code to supply dalphax/dp and dalphay/dp to the twiss output file, I realized that the value being provided for optimization of dalphax/dp was incorrect (it is actually filled with dbetax/dp). This will be fixed in the next release.

If you build from source, the attached file can be used to provide the fix.

--Michael

Thank you for your kind help.