nobeam/lattice-summaries-lattices-legacy

https://lattice-summaries.netlify.app

lattice-summaries-lattices-legacy's Issues

Clean shared lattices

In my opinion shared lattices should not contain any markers or other optional elements.

They should be as clean as possible, so that they are useful for everyone.

Uniform naming scheme

New Proposal

Naming Scheme

Information like the energy, periodicity, number of bends per cell and other details (e.g. longitudinal gradients bend) which characterize a lattice will be included in the info.toml file, so it is not necessary that they are present in the filename. As we want to distribute the lattices over the web we have restrict us to the unreserved URL characters A-Za-z0-9.~-_.

Schema

The schema of a lattice name is given by:

<machine>_<namespace>_<familiy>_v_<version>

A name is built up out of different <identifiers> which are separated by a _. Allowed characters within an <identifier> are therefore A-Za-z0-9.~-.

⚠️ Notice that _ is not allowed!

Explanation of different <identifiers>

• <machine> Name of the machine (e.g. b2,b3, mls, mls2)
• <namespace> This is necessary to make sure different people don't come up with the same name. All contributors of lattice-summaries repo will have their own namespace and have to make sure that all <family> names are unique within their namespace. Notice that the <namespace> must not correspond to the author(s) of a lattice. The actual authors of a lattice are listed in info.toml file and also as comment at the top of automatically generated lattice files. I decided it this way, because we may want to include lattices from other facilities. If Paul would upload the SLS2 lattice, the name would be something like sls2_goslawski_design_v_std-user even though Paul is not the author of the SLS2 lattice. The same would be true for a LOCO-measured BESSY II lattice file. In case a lattice <family> is maintained by multiple people an acronym like gaa for Goslawski, Abo-Bakr and Andreas would also be fine.
• <familiy> The goal of a <family> identifier is to make different versions of a lattice easier to compare on the lattice-summaries website. The name of the lattice family must be unique within YOUR <namespace>. Lattices within a family should belong logically together. For example Paul created several MLS2 lattices based on a scaled down version of BESSY II. In this case the family name should be something like scaled-bessy2. As during the B3 development presumably many lattices will be called 5ba-20p, you could also choose a more memorable name like jupiter, bravo or falcon, which will make it easy to refer to a specific lattice during discussions.
• <version> The version name uniquely identifies a lattice within a <family>. It can be a simple number like 1 or a more descriptive name like std-user, low-alpha or reference. To please Paul it is also possible to use something like 1200mev-8p-2ba-new-wp-x909125-y909125.

Recommendations

Even there are no technical limitation, I would recommend to stick with lowercase characters and avoid using the ~ and . characters. This will make it easier on the command line and also provides some consistency. So I would only use the a-z0-9-.

Examples

• b3_kuske_5ba-20p_v_reference
• b3_kuske_5ba-20p_v_long-bend-tgrb
• b3_abo-bakr_jupiter_v_2
• mls3_goslawski_scaled-bessy2_v_100m-1200mev-8p-2ba-new-wp-x909125-y909125
• b2_mertens_loco_v_std-user-2020-08-10
• b2_andreas_q5t2-off_v_4

Agree on lattice structure

@MichaelMAB2020 @PaulGoslawski @HZBries
I think it would be reasonable to agree on a shared lattice structure. This would make it easier to compare different lattice parameter such like "free straight length" as suggested in Markus's last email.

We should agree on:

• name of the main straight
• name of the unit cell
• should the lattice files contain the definition of the whole ring or just of the unit cell?

Naming Convention for Lattice Files

For a lattice design project, i.e., covering the evolution from a:

design concept -> CDR -> PDR -> etc.

given the multitude of lattice files that will be generated during this activity – and exchanged between individuals & groups, i.e., the End Users – a well thought out naming convention at the outset, is as important as e.g. ditto for the parameters for a control system for such a system:

<system> -> <sub-system> -> <sub-sub-system> -> etc.

Hence, for a Straw Man proposal for Functional Specs – i.e., What vs. How/Design Specs – I suggest:

<accelerator> <engineering footprint/structure> <linear optics> <nonlinear dynamics> <version>

.

Wrong Elegant Twiss Plot

The Twiss parameter plot for kuske / bessy3_5ba-20p_v_reference from Elegant is wrong? I run the file and get the same results as mad and apace ...

how to name reversed elements/sequences

@MichaelMAB2020 @PaulGoslawski

At the moment i append "_reversed" if an element or sequence gets reversed. this raises the problem that names overlap in the twissplot.

Possible solutions:
just append

• "_rev"
• "_r"
• "__r"
• "r"

but this would make name conflicts more likely.

Lattice Labels

Related to #3 (comment)

We should introduce a list of labels, which can be added to the lattice metadata. These labels would be displayed on the lattice summaries and could also be used to filter for specific lattices:

Proposal

• antibends
• combined function bends
• longitudinal gradient bends
• super bends
• loco

@MichaelMAB2020 please add other labels if you have ideas

Lattice file format

@PaulGoslawski @MichaelMAB2020 @tomerten

Problem:

To leverage multiple simulation tools we have to generate lattice files in different formats.

Solution 1: Maintain different formats by hand

This can become very tedious, especially if we have tens or hundreds of different lattice files. This could also be error-prone. I think the only advantage is, that we don't have to write any custom software.

Solution 2: Generate different lattice files automatically

Decide on one main lattice file format. This file format will be the ground of truth format. This requires the files to be clean (no markers, simulation-tool specific attributes/variables), because otherwise it is very difficult to convert to other formats.

To make lattice-development more convenient, we could than provide some template files, where markers or other utility elements are automatically injected.

I would propose to go with the LatticeJSON format, because it will be the easiest way to generate other lattice files. It is much harder to parse stuff than generating stuff! If you don't I think it is a good idea to use a custom file format, my second-favorite approach would be to agree on a restricted subset of the MADX format (no variables, only basic elements)