Skip to content
This repository has been archived by the owner on Jun 7, 2021. It is now read-only.

Uniform naming scheme #3

Closed
felix-andreas opened this issue Dec 3, 2020 · 5 comments
Closed

Uniform naming scheme #3

felix-andreas opened this issue Dec 3, 2020 · 5 comments

Comments

@felix-andreas
Copy link
Member

felix-andreas commented Dec 3, 2020

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
@MichaelMAB2020
Copy link

MichaelMAB2020 commented Dec 4, 2020

naming proposal:

Only use unreserved characterscharacters: A-Za-z0-9_.~-

  • machine: b3 or b2 or mls2 or ...
  • energy / 0.1 GeV (2.5 GeV -> 25) or in MeV
  • periodicity
  • N Bends per cell (MBA)
  • use of Antibends: RB=y or RB=n
  • use of combined function bends: TGMB=y/n (M=Main) and TGRB=y/n
  • use of long. gradient bends: LGMB=y/n ?
  • use of super Bends: SB=y/n ???
  • ...
  • an author given version number (X-Y)

If the naming convention is for b3 lattices only, we should not use fixed parameters (maybe Energy, straight length, ...)

@felix-andreas
Copy link
Member Author

We should only use signs allow in URIs.

@felix-andreas

This comment has been minimized.

@felix-andreas
Copy link
Member Author

felix-andreas commented Dec 5, 2020

@MichaelMAB2020 @PaulGoslawski See my proposal at the top. If you have an improvements don't hesitate to edit the top comment. All comments are version controlled, so you can't delete anything.

Open questions:

  • should we have shared namespaces? For examples a synchrotron-data-booklet namespace where we could collect lattices of other machines? or an hzb namespace as a place for official/final and loco-measured lattices.
  • should <machine> name and <namespace> be switched? this would make it easier to see all lattices within your own namespace...
  • use folders instead of the namespace?

@MichaelMAB2020
Copy link

Open questions:

1. should we have shared namespaces? For examples a `synchrotron-data-booklet` namespace where we could collect lattices of other machines? or an `hzb` namespace as a place for  _official/final_ and loco-measured lattices.

2. should **`<machine>`** name and **`<namespace>`** be switched? this would make it easier to see all lattices within your own namespace...

3. use folders instead of the namespace?
  1. I'd like to have these things in namespaces.

  2. No, keep it as it is - machine is more important than author

  3. What is the difference? If it is not a big difference for the "user" do it to your convinience.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants