Discussion about the lattice standard started in PR #11

[egstern]

1. The Lattice Standard is an abstract description of a lattice for the simulated transport of charged particles.

2. A Lattice is an ordered list of regions in space distinguished by the presense of (possibly time-varying) specially described electromagnetic fields,
   materials, apertures and other possible engineered structures. For simplicity, we will denote these regions as lattice_elements although a region
   Member
   @DavidSagan DavidSagan 3 days ago
   Instead of "For simplicity, we will denote these regions as lattice_elements " better I think is "These regions will be called lattice elements

Member
Author
@egstern egstern 3 days ago
Sounds good to me.

@rdemaria rdemaria 2 days ago •
Point 2 and 4 seem too specific to me in this context, as they imply a specific choice of the relation between lattice, elements and positioning. I would state for instance that “the standard will define what is a lattice and how it can be described in terms of primitive components".

For instance, you can call a "lattice element" a coordinate transformation, observation point, a matrix element that are not regions of space, but which you could order. Conversely, you may call elements, specifications of certain aspects of a region of space (fields, aperture, etc,), without an explicit positioning and the lattice an unordered collection of the positioning of existing elements relative to a reference coordinate system.

---

materials, apertures and other possible engineered structures. For simplicity, we will denote these regions as lattice_elements although a region
may be distinguished by the absence of material (drift space.)

1. A lattice will have the notion of a reference_trajectory which is the defined path of the particle which the lattice is intended to transport.
   Member
   @DavidSagan DavidSagan 3 days ago •
   This is a bit confusing. Especially since the particles may never follow the reference trajectory (EG: in a wiggler the reference trajectory is straight but the actual particle path is oscillatory). I think better is:

A lattice will have the notion of a reference trajectory, also called the zero orbit, about which the curvilinear coordinate system of the lattice is defined. This curvilinear coordinate system, called machine coordinates in the standard, establishes a coordinate system which may be used to describe particle trajectories and lattice element alignment.

Member
Author
@egstern egstern 3 days ago
Yes, I was unsure of how to deal with things like undulators and even what MAD calls RBENDS. We definitely need some language that can deal with it but it wasn't obvious to me without maybe a figure what your terminology refers to and how you would use it to place elements at positions.

Member
@DavidSagan DavidSagan 3 days ago
Yes I plan on submitting a PR that will go into this in detail.

---

propagated reference particle. The definition and use of coordinates transverse to the direction of motion is not in this document and will be
the subject of the definition of the standard.
Member
@DavidSagan DavidSagan 3 days ago •
Some parts of this document should be incorporated in the standard itself. I'm imagining a preamble section in the standard which talks about what the standard is and what it is not.

---

1. The Lattice Standard defines a language and a document composed of words and symbols made of UTF-8 characters that is human readable.

2. The language defined by the Lattice Standard should conform to a formal grammar in the the common meaning in computer science and be unambiguously parsable by machines.
   Member
   @DavidSagan DavidSagan 3 days ago
   My idea is that the Standard defines a schema which can be realized in languages like YAML, JSON, etc. So the grammar is defined by the language. What should be avoided is a custom language like MAD.

Member
Author
@egstern egstern 3 days ago
Isn't a schema a kind of grammar as well? I'm not familiar with the details of what makes something a schema and whether it is too constraining. I would like to see some examples of how that would work.

Member
@DavidSagan DavidSagan 3 days ago
Agreed. I believe things will become much clearer when we start fleshing out the Standard.

---

1. It would be nice for the Lattice Standard language to have the ability to define subsections of a machine (arcs) which substitutable arguments that can be duplicated and placed within a larger structure.

2. It would be nice for the Lattice Standard language to allow mechanisms to manipulate and transform defined arcs.
   Member
   @DavidSagan DavidSagan 3 days ago
   This gets into a discussion of portability versus usability. Portability is maximized by minimizing manipulations that are needed to instantiate a lattice within a program. I think we can eventually include such manipulations but I would propose we initially aim for portability.

---

What the Lattice Standard is not

1. The Lattice Standard does not say anything about its implementation in any computer language.
   Member
   @DavidSagan DavidSagan 3 days ago
   Yes the Standard itself will be language agnostic. To make the Standard useful, we will need to create translating software that will be housed in the repo (or repos) with the Standard.

---

1. The Lattice Standard does not say anything about its implementation in any computer language.

2. The Lattice Standard does not say anything about the algorithms or physics that goes into the implmentation of particle transport simulations.
   Member
   @DavidSagan DavidSagan 3 days ago
   Yes this is an important point. The Standard will need to rigorously define everything. For example, what is the field associated with a multipole.

---

1. The Lattice Standard does not say anything about the algorithms or physics that goes into the implmentation of particle transport simulations.

2. Any particular lattice element may include in its description hints about the way in which it is intended to be implemented. The standard does not require their usage in any code in any particular way.
   Member
   @DavidSagan DavidSagan 3 days ago
   I'm confused by what is intended here.

Member
Author
@egstern egstern 3 days ago
Suppose some dipole element has some kind of fringe fields. Fringe fields can be described in many different ways. MAD-X has several parameters that can go into a fringe field calculation; there are other formalisms. Your element may have suggestions on the preferred way but some codes may not be implement them. They are still useful.

---

1. The Lattice Standard organization encourages the development of software in various languages that implement tools
   for parsing Lattice Standard documents and making the information available to particle transport codes. These tools are separate from the Lattice Standard.
   Member
   @DavidSagan DavidSagan 3 days ago
   To make the Standard usable, Readers/Writers should be part of the project. Just as Readers/Writers are part of OpenPMD.

Member
Author
@egstern egstern 3 days ago
OK, but I don't want to specify an interface that a reader/writer has to follow, especially because the natural idiom for doing things can vary by language, not to mention that the representation of all the data objects is going to be different in different languages.

Member
@DavidSagan DavidSagan 3 days ago
Yes. This is not preventing someone from implementing their own. We just don't want people to have to reimplement the wheel so to speak.

---

This document, as Eric says, is a view on how to develop the Standard. As such, as the Standard is developed, I'm sure our conception of what the standard is, and is not, will evolve. So I don't take this as a mandate but rather something to help guide our thoughts. Given this, I'm thinking that it would be more useful to move this to the Conversation area where there can be a conversation that is not limited in time.