Some confusing issues with insert_elements

[GPenn]

Hi,

I use insert_elements to add TSCATTER elements for calculating losses due to Touschek scattering.
Most of the time it works fine, but I am also using load_parameters as my way of reading in magnet errors.
When both are used in one set of calculations *and* add_at_start=1, that very first insertion seems to be assigned
properties coming from what was originally the first element, even if those properties do not belong.
It takes calls to both load_parameters and insert_elements, and using add_at_start=1 to experience the problem.

There is a separate issue with the relatively new feature allowing insert_before=1. If the selected
places for insertion are close together, then fewer new elements are added compared to using
insert_before=0. The demonstration files for this problem do not use either load_parameters or add_at_start=1,
to try keeping things simple.

I am attaching some files based on the spear lattice and output coming from Mac binaries for version 34.4.1.
I do see the same thing for later versions. In these examples, load_parameters is not actually doing anything
useful, but it does trigger the bug. I played a little with changing the order of the command namelists, but I could
not avoid getting an error.

I was wondering if there is a better way to save and load in lattices with given errors, other than using
parameters in run_setup followed by load_parameters. Also, it would be very convenient if I could use
a list of element types in insert_elements instead of trying to cobble something together with wildcards.
That method seems to work with exclude_type_pattern inside load_parameters, it would be great to be able to do
the same thing for insert_elements. Or is there already a way to do that and I just don't know the proper format?

Thank you,
Gregg

[michael_borland]

Gregg,

Thanks for uploading a file with detailed examples of the problems. I'll have a look and get back to you.

As for the best way to save a lattice with errors, using parameter files is it. Since the lattice is often defined with repeated occurrences of the same element name (e.g., we define a sector, then multiply by N), it is not possible to provide a general capability in the lattice file alone.

I'll look into improving insert_elements with more flexible specification of the insertion point.

--MIchael

[michael_borland]

Gregg,

I confirmed the bug in load_parameters when insert_elements is used. The fix was simple (recreating a hash table when the beamline is regenerated) and will appear in the next release.

Meanwhile, you should be able to work around the problem by changing your load_parameters command to something like

Code: Select all

&load_parameters
   filename = spear0.param,
   change_defined_values = 1
   force_occurence_data = 1
&end

This will force the loading of parameters to occur immediately, rather than waiting until after the &track command is issued. This will be completely equivalent to what you wanted to do so long as spear0.param only has a single page of errors. If you need multiple pages of errors (different seeds), just split the file using sddssplit and run each separately (you can use the macro substitution feature on the elegant commandline to help with this).

I'm still looking at the insert_before issue.

--Michael

[GPenn]

Hi Michael,

Thanks, that did the trick. My workaround was to do a separate elegant run just to read in the nominal lattice, insert the elements, and save a revised lattice file using output_seq=1. With the new lattice I can still load in the same parameters file without a problem. I like your way since it is less of a kludge.

Cheers,
Gregg

[michael_borland]

Gregg,

I also confirmed the bug with insert_elements when insert_before=1 and the selected elements are closely-spaced (consecutive elements are the problem). This will be fixed in the next release. For now, I suggest one of two workarounds: (1) Use a preceding insert_elements command to put MARK elements in after all the selected elements. This will ensure that the elements you are inserting before are not consecutive. (I didn't try this, but it "should work.") (2) Use three separate insert_elements commands, one for each type of element. You'll need to give different names for the TSCATTER elements, but that shouldn't hurt anything.

--Michael