Elegant users forum

Mike,

I have a question regarding the load_parameters. I have lattice file and a parameters file that I generated with elegant. The lattice file is a bare lattice and the parameters file contains errors that I included into the lattice. I want to use these files in another script. I use Load_Parameters to load the .param file in and output the Twiss functions and the parameters again. The Twiss functions come out as the bare lattice, while the params file come out as if my original params file was loaded in correctly. I would have expected the Twiss file to reflect the errors in the lattice. Needless to say I am a little confused by this behavior.

I have attached an example for you.

Ray

Ray,

This is one of the more frequent points of confusion. The twiss_output and load_parameters commands are a dual-mode commands. That means they can both take an action immediately or set up elegant to take actions later. In the case of twiss_output, the default is to compute the twiss parameters right away. In the case of load_parameters, the default is to load the parameters later, as part of the main loop.

So there are two solutions:
* Change twiss_output to setup mode. You can do this by setting output_at_each_step=1
* Change load_parameters to action mode. You can do this by setting change_defined_values=1. This is probably not what you want if you are simulating errors. The manual has more details about the meaning of this parameter.

--Michael

Mike,

I tried this and it worked. Thanks for the clarification.

Ray

Mike,

I had a further question on this point. When one has a lattice with errors in it and then computes the twiss functions setting output_at_each_step=1, how exactly does elegant compute the twiss functions? Does it calculate the closed orbit and then integrate along it or does it do something else?

Ray

Ray,

It depends on what you've requested. If you request orbit computations (either with &closed_orbit or &correct), then those are performed first. Also, if you request tune or chromaticity correction, those are done first. If you don't request any of these things, elegant just computes the twiss parameters on whatever trajectory it gets by proceeding along the beamline.

--Michael

Mike,

Sounds good. I assume that the calculation includes all of the errors as well.

Ray

Ray,

Yes, that's a correct assumption.

--Michael

Michael,

Sounds good.

Ray.

This seems like an old post but I am having a similar issue, what I am trying to do is the following, the problem is split into two blocks:

block A)
track a case with quad errors and save as a test_a.new lattice + test_a.param file and output test_a.twi.
This should also create a .new lattice which is in fact a copy of the original "run0.new" lattice. It also saves the parameters
describing the errors of the system, in this case FSE errors on QUADs.

block B)
upload test_a.new lattice + test_a.param from previous run (block A) and verify tune & chromaticity and recalculate the .twi output.
ideally when the two blocks are run in sequence, one should end up with equal tune and chromaticity at the "exit" of block B.

But this is not the case, maybe my assumption is too naive. I reckon this is a very simple example, but I would really like to understand what I am doing wrong before introducing other errors and orbit corrections, which is indeed the final goal of the exercise

I attach the test file, which can be run as
elegant test_a.ele
elegant test_b.ele
or just via ./runAll
(./cleanUpAll removes the unwanted stuff)

Ray,

This is an admittedly confusing issue.

The problem is that you have many elements with the same name. In the run test_a, these are all given different FSE errors, since you have bind=0 on the &error_element command. Further, those individual errors are saved in the parameter file, with the ElementOccurence value telling elegant which error goes with which occurrence of the identically-named element. However, when &load_parameters has change_defined_values=1, elegant is being instructed to change the definition of each quad, rather than the instances (occurrences) that are duplicates of the definition. That means all the quads with the same name end up with the same parameters.

To get the desired result, you can set change_defined_values = 0, or you can set force_occurence_data = 1 in your &load_parameters command. The former will result in delaying the parameter loading until the steps loop, but that shouldn't be a problem. The latter tells elegant to change the copied definitions of the quads individually, rather than the root definition.

You may wonder when you should use change_defined_values=1 vs change_defined_values=0. Generally, the former is used to tell elegant to load parameters immediately for use as the basis for all subsequent changes. If that's what you need, then just be sure to use force_occurence_data = 1 when you are loading errors and force_occurence_data=0 for loading common changes across many like-named elements.

--Michael