Should Markers be in the lattice file?

[felix-andreas]

No description provided.

[TMsangohan]

Hi Felix,

Would it be much work to implement markers, I need them quite urgently to convert my latest version of BII lattice to the json format.

Thanks
Tom

[TMsangohan]

@andreasfelix

Created a branch add-markers-tom
where I added markers. I also updated the tests a bit such that in test_convert testcases are compared with expected output.

Tom

[felix-andreas]

@PaulGoslawski do you have an opinion on this?

Still not sure if Markers should be part of the lattice file. Because they are just an auxiliary tool and there is no physical equivalent, it feels not right implement them as separate Element. I understand that it is convenient, because there is a Marker element in MADX and elegant, but is this reason enough to include them in LatticeJSON?

Also depending on the task, everybody will set their markers at different positions and this could be quite annoying when exchanging lattice files.

Would there be a problem to define thm as array (position in meters) under the "tool" attribute?

{
  "version": "2.0",
  "title": "FODO Lattice",
  "info": "This is the simplest possible strong focusing lattice.",
  "root": "RING",
  "elements": {
    "D1": ["Drift", {"length": 0.55}],
    "Q1": ["Quadrupole", {"length": 0.2, "k1": 1.2}],
    "Q2": ["Quadrupole", {"length": 0.4, "k1": -1.2}],
    "B1": ["Dipole", {"length": 1.5, "angle": 0.392701, "e1": 0.1963505, "e2": 0.1963505}]
  },
  "lattices": {
    "CELL": ["Q1", "D1", "B1", "D1", "Q2", "D1", "B1", "D1", "Q1"],
    "RING": ["CELL", "CELL", "CELL", "CELL", "CELL", "CELL", "CELL", "CELL"]
  },
  "tool": {
    "markers": [0, 10, 20]
  }
}

[PaulGoslawski]

Ok, so what is the reason for markers - for what do we need markers? Why they are needed in MADx and elegant?
--> To save tracking data in a 'special' position. OK? Only tracking data?
In principle they are not part of the lattice such as BPMs for example... but elegant defines markers as zero lenght dirft space

I like Felix proposal, but it will make the realisation of this markers more difficult or not?
And how to translate json markers into madx or elegant and vice versa?

Please not comment only by 'thumb up' ....

[TMsangohan]

@PaulGoslawski
I disagree to markers not being part of the lattice.

Beamports, FOMs, insertion devices, ... are real physical devices placed in the ring, and are referenced by markers in most cases. I need mostly lattices with markers as most lattice questions directed at me are users asking for optical functions at these places and how they would change when some specific magnet current is changed. And as you can have several versions of lattices I do not really see the problem of having them in the lattices, you just have different versions.

On a related topic, I need a straightforward and easy way to access power supplies as I often also get the question how strengths of magnets in physics units change when the current is changed of specific power supplies (currently I use a database that holds the conversion factors, magnet name and power supply name, and I provide a simple function that calculates conversions in both directions).

Both remarks above are routine questions and should not cost me any effort if you want me to use latticejson as a standard storage for lattices, otherwise it is just another way of storing some lattices but not all the ones I need producing more overhead.

I hope I do not sound harsh but as long as I have no bpms, cavities, kickers and markers I can not use this for my daily work and I need to make progress fast. My old approach of mongodb is far from perfect but allows me to quickly do the above things.

@andreasfelix
Do not take this as negative comments, I support your latticejson project fully but I am also aware of and myself confronted with the limitations that prohibit me from using it as a standard tool. So, see it as a push to develop it further ;).

[tomerten]

Implemented an working for my lattices. (add-markers-tom)