formalisation of common HEP units

[RalphSteinhagen]

Not urgent nor a bug but some thought related to end-user usage and look-and-feel.

I saw that there are some basic definitions of units that are commonly used in particle physics like electronvolt and gigaelectronvolt. This probably gets many of us excited because this seems to imply that there are other HEP people out there that maybe keen in using this library to get some more unit-/type-safetly into their codebase.

While these are still incomplete and certainly possible to (re-(re-(..)))-define them in the various use codebases (i.e. they are all derived from SI units), I was wondering whether this could be formalised and an official part of the units library?

Most of these units are defined either for brevity because of being compound of (e.g. [eV/c] == [kg m/s]) or because being relatively small compared to other base SI-units (e.g. '1 eV' ~ '1.602e-19 J' -- or even '1 fb' = 1e-43 sqm).

On this line, some thoughts for discussion how this could be possibly improved:

1. shorten electronvolt and 'gigaelectronvolt' to eV and 'GeV` respectively -- rationale: the long-form is very uncommon
2. introduce additional '..., keV, MeV, GeV, TeV, ...' short-hand notations
   -- based on this, is the question on 'aliases' vs. 'references' vs. 'literals' decided? (N.B. I'd be in the aliases/literal camp)
   N.B. energies can be negative -- why are there unsigned long long definitions?
3. introduce the 'eV/c^2' mass and common prefix definitions. Which would be a suitable literal definition:
   • eV_per_c_sq,
   • eV_per_c2, or
   • something even shorter (ideally: eV/c²)?
4. masses in HEP are often given in relation to the electron m_e, proton m_p, or neutron m_n masses
5. introduce the 'eV/c' momentum and common prefix definitions. Which would be a suitable literal definition:
   • eV_per_c,
   • eV_per_c, or
   • something even shorter (ideally: eV/c)?
6. introduce the 'barn' (== 1e-28 sqm) definitions with common SI prefixes ('mb', 'ub', and below are only really useful)
7. introduce the 'inverse (femto) barn' definition: this unit is a bit special because it is an inverse area und commonly only the '(fb)^-1^ and nowadays rarely '(pb)^-1^ prefixes are used
8. open question 🤔 : wouldn't it be useful to centrally define common mathematical operations, e.g.
   • rel. Lorentz- transformation, boost operator, energy-momentum relation, etc. (e.g. this and this)
     IMHO: this is not a massive set that would deserve its own library (as LA does) but would be very helpful to avoid common mistakes and different naming conventions (e.g. possibly with a hep_ prefix).

Hope I am not alone with these questions, thoughts, or particular HEP unit interest. Food for thought ...

Click to expand for code-snippet!

// HEP units
#include <units/isq/si/area.h>
#include <units/isq/si/energy.h>
#include <units/isq/si/length.h>
#include <units/isq/si/mass.h>
#include <units/isq/si/momentum.h>

// energy
namespace units::isq::si {
    struct eV : named_scaled_unit<eV, "eV", prefix, ratio(1'602'176'634, 1'000'000'000, -19), joule> {};
    struct feV : prefixed_unit<feV, femto, eV> {};
    struct peV : prefixed_unit<peV, pico, eV> {};
    struct neV : prefixed_unit<neV, nano, eV> {};
    struct ueV : prefixed_unit<ueV, micro, eV> {};
    struct meV : prefixed_unit<meV, milli, eV> {};
    struct keV : prefixed_unit<keV, kilo, eV> {};
    struct MeV : prefixed_unit<MeV, mega, eV> {};
    struct GeV : prefixed_unit<GeV, giga, eV> {};
    struct TeV : prefixed_unit<TeV, tera, eV> {};
    struct PeV : prefixed_unit<PeV, peta, eV> {};
    struct EeV : prefixed_unit<EeV, exa, eV> {};
    struct YeV : prefixed_unit<YeV, yotta, eV> {};
}  // namespace units::isq::si

// mass
namespace units::isq::si {
    struct eV_per_c_sq : named_scaled_unit<eV_per_c_sq, "eV/c^2", prefix, ratio(1'7826'619'216'279, 1'000'000'000'000, -35), kilogram> {}; // alt: eV_per_c2??
    struct feV_per_c_sq : prefixed_unit<feV_per_c_sq, femto, eV_per_c_sq> {};
    struct peV_per_c_sq : prefixed_unit<peV_per_c_sq, pico, eV_per_c_sq> {};
    struct neV_per_c_sq : prefixed_unit<neV_per_c_sq, nano, eV_per_c_sq> {};
    struct ueV_per_c_sq : prefixed_unit<ueV_per_c_sq, micro, eV_per_c_sq> {};
    struct meV_per_c_sq : prefixed_unit<meV_per_c_sq, milli, eV_per_c_sq> {}; // approximate mass of an electron/positron (0.511 MeV/c2)    
    struct keV_per_c_sq : prefixed_unit<keV_per_c_sq, kilo, eV_per_c_sq> {};
    struct MeV_per_c_sq : prefixed_unit<MeV_per_c_sq, mega, eV_per_c_sq> {};    
    struct GeV_per_c_sq : prefixed_unit<GeV_per_c_sq, giga, eV_per_c_sq> {}; // approximate mass of a proton (0.938 GeV/c2) or neutron
    struct TeV_per_c_sq : prefixed_unit<TeV_per_c_sq, tera, eV_per_c_sq> {};
    struct PeV_per_c_sq : prefixed_unit<PeV_per_c_sq, peta, eV_per_c_sq> {};
    struct EeV_per_c_sq : prefixed_unit<EeV_per_c_sq, exa, eV_per_c_sq> {};
    struct YeV_per_c_sq : prefixed_unit<YeV_per_c_sq, yotta, eV_per_c_sq> {};
    struct electron_mass :  named_scaled_unit<eV_per_c_sq, "m_e", prefix, ratio(9'109'383'701'528, 1'000'000'000'000, -31), kilogram> {};
    struct proton_mass :  named_scaled_unit<eV_per_c_sq, "m_p", prefix, ratio(1'672'621'923'695, 1'000'000'000'000, -27), kilogram> {};
    struct neutron_mass :  named_scaled_unit<eV_per_c_sq, "m_n", prefix, ratio(1'674'927'498'049, 1'000'000'000'000, -27), kilogram> {};
}  // namespace units::isq::si

// momentum
namespace units::isq::si {
    struct eV_per_c : named_scaled_unit<eV_per_c, "eV/c", prefix, ratio(5'344'285'992'678, 1'000'000'000'000, -35), kilogram_metre_per_second> {}; // alt: eV_per_c??
    struct feV_per_c : prefixed_unit<feV_per_c, femto, eV_per_c> {};
    struct peV_per_c : prefixed_unit<peV_per_c, pico, eV_per_c> {};
    struct neV_per_c : prefixed_unit<neV_per_c, nano, eV_per_c> {};
    struct ueV_per_c : prefixed_unit<ueV_per_c, micro, eV_per_c> {};
    struct meV_per_c : prefixed_unit<meV_per_c, milli, eV_per_c> {};
    struct keV_per_c : prefixed_unit<keV_per_c, kilo, eV_per_c> {};
    struct MeV_per_c : prefixed_unit<MeV_per_c, mega, eV_per_c> {};
    struct GeV_per_c : prefixed_unit<GeV_per_c, giga, eV_per_c> {};
    struct TeV_per_c : prefixed_unit<TeV_per_c, tera, eV_per_c> {};
    struct PeV_per_c : prefixed_unit<PeV_per_c, peta, eV_per_c> {};
    struct EeV_per_c : prefixed_unit<EeV_per_c, exa, eV_per_c> {};
    struct YeV_per_c : prefixed_unit<YeV_per_c, yotta, eV_per_c> {};
}  // namespace units::isq::si

// interaction cross section (barn)
namespace units::isq::si {    
    struct barn : named_scaled_unit<barn, "b", prefix, ratio(1, 1, -28), square_metre> {}; // 1 barn = 100 fm^2 = 10^-28 m^2
    struct yocto_barn : prefixed_unit<yocto_barn, yocto, barn> {};
    struct zepto_barn : prefixed_unit<zepto_barn, zepto, barn> {};
    struct atto_barn : prefixed_unit<atto_barn, atto, barn> {};
    struct femto_barn : prefixed_unit<femto_barn, femto, barn> {};
    struct pico_barn : prefixed_unit<pico_barn, pico, barn> {};
    struct nano_barn : prefixed_unit<nano_barn, nano, barn> {};
    struct micro_barn : prefixed_unit<micro_barn, micro, barn> {};
    struct milli_barn : prefixed_unit<milli_barn, milli, barn> {};
}  // namespace units::isq::si

// inverse femto-barn -- used to express integrated luminosity, i.e. 'luminosity' * 'in. luminosity' = 'number of expected events'
namespace units::isq {
    template<typename Child, Unit U, typename...>
    struct dim_inv_area;

    template<typename Child, Unit U, DimensionOfT<dim_length> L>
    struct dim_inv_area<Child, U, L> : derived_dimension<Child, U, exponent<L, -2>> {};
}

namespace units::isq::si {    
    struct inv_square_metre : unit<inv_square_metre> {};
    struct dim_inv_area : units::isq::dim_inv_area<dim_inv_area, inv_square_metre, dim_length> {};

    struct inv_barn : named_scaled_unit<inv_barn, "b^-1", prefix, ratio(1, 1, +28), inv_square_metre> {}; // 1 barn = 100 fm^2 = 10^-28 m^2
    struct inv_pico_barn : prefixed_unit<inv_pico_barn, giga, inv_barn> {};
    struct inv_femto_barn : prefixed_unit<inv_femto_barn, tera, inv_barn> {}; // N.B. most common HEP unit for luminosity
}  // namespace units::isq::si

@mpusz N.B. I haven't made a PR out of this, because I wasn't sure about the focus and direction you want to go with your lib and because there are many style questions involved ...

[mpusz]

shorten electronvolt and 'gigaelectronvolt' to eV and 'GeV` respectively -- rationale: the long-form is very uncommon

Well, we can't provide shorter unit names as an exception for HEP because the next request will be to provide m and km instead of metre and kilometre. At least not in SI namespace. Said that every user is able to provide its own alias for type with a more useful name. For example:

using eV = units::isq::si::electronvolt;

Alternatively, we have UDLs, references, and aliases that provide nice shorthand notations. I recommend using them to save typing.

introduce additional '..., keV, MeV, GeV, TeV, ...' short-hand notations

Sure we can do it but for the long names only. Can you provide a PR?

N.B. energies can be negative -- why are there unsigned long long definitions?

There is no other way to specify an integral UDL. See here: https://en.cppreference.com/w/cpp/language/user_literal#Literal_operators. But a negative number can be easily obtained thanks to a unary op-() operator

introduce the 'eV/c^2' mass and common prefix definitions... and the following points

Sure, why not? The only question is if those should go to the si namespace or maybe a new namespace/system based on SI should be provided? In such a case I would love to put keV, MeV, GeV, TeV, ... there as well, as if I recall correctly SI only allowed gigaelectronvolt as an additional unit.

---

To summarize I would like to encourage you to provide a PR with those changes. I think they should be defined in a new namespace/system/directory (i.e. isq::hep). In such a namespace you can use whatever names you find useful 😉

[RalphSteinhagen]

[..] I would like to encourage you to provide a PR with those changes. [..]

Thanks for being open to this and sure this will be a PR, as mentioned before, but I wanted to check first whether there is a chance of this PR being accepted and regarding the required/targeted style/namespace/files before doing so.

[..] as if I recall correctly SI only allowed gigaelectronvolt as an additional unit.

According to the standard the 'electronvolt' or 'eV' can be combined with any SI prefix. 'gigaelectronvolt' as well as 'GeV' are both "accepted for use with the SI Units" but not explicitly stated in the standard.

[..] as an exception for HEP [..]

You are making a lot of physicists sad who think that HEP is the queen of sciences. 😉

[..] will be to provide m and km instead of metre and kilometre. At least not in SI namespace. [..]

I understand and appreciate the point (i.e. namespace collissions), but there is a difference between 'metre -> m' (5 -> 1 characters) and 'gigaelectronvolt -> GeV' (16 -> 3 characters).
As a proposal, I'd add

• the long versions to the units::isq::si namespace,
• the short-hand notations (ie. 'GeV' etc) into the units::isq::si::hep, and
• the short-hand literals (_q_GeV, ...) also into the units::isq::si::literals or -- if needed -- units::isq::si::literals::hep namespace.
  I propose to skip the long literal definitions since these are not really useful and to my knowledge not used in the community.

With exception w.r.t. luminosity (e.g. barn 'b' and '(fb)^-1') -- which I'd add a new file/definition -- I would add the before mentioned definitions to the existing files in si. OK?

Would that be acceptable?

There is no other way to specify an integral UDL.

Yes, I saw this quickly after I have posted this. Sorry, should have maybe edited this out.

[i-ky]

there is a difference between 'metre -> m' (5 -> 1 characters) and 'gigaelectronvolt -> GeV' (16 -> 3 characters)

There is also a difference in how widely metre and electronvolt are used. You need to multiply savings by a number of uses. I am with @mpusz on this one, using (or #define, if you wish) can cope with the problem of typing long names quite easily.

[RalphSteinhagen]

There is also a difference in how widely metre and electronvolt are used.

@i-ky It's all a matter of perspective: yes, I heard that some use 'metre' instead of the more natural 'hc/eV' or 'h/m_ec' units of length. Please, do not burst my beloved bubble and/or the ubiquitous lock-down got the better of me. 😁

I am fully aware of the issue of collisions in namespaces. At the same time, I'd reckon that there are not that many ambiguities regarding e.g. 'GeV'. In any case, as @mpusz already suggested, a dedicated namespace and definitions in, for example, units::isq::si::hep, would be in order also to simplify/speed up the compile-time parsing scope.

[mpusz]

@RalphSteinhagen, BTW, talking about HEP:

1. Do you find the utilities provided by https://github.com/mpusz/units/tree/master/src/systems/isq-natural useful?
2. Did you see a https://github.com/mpusz/units/blob/master/example/references/total_energy.cpp example?
3. Or maybe natural units should be defined totally standalone from the SI system? I always wanted to add such a system that could even potentially break the ISQ rules but never had time to do so.

[RalphSteinhagen]

1. Do you find the utilities provided by https://github.com/mpusz/units/tree/master/src/systems/isq-natural useful?

I work(ed) with both, natural (i.e. h=c=e₀=1, aka. 'God-given-units') and regular SI units are being used based on the given context:
The natural ones are more common/favoured in theoretical physics because they express the relationships and order-of-magnitudes better as well as are much easier w.r.t. pen-and-paper integral calculations.
The SI units are de-facto mandatory if you want to put any HEP measurement into context or control any real-world quantities (e.g. magnetic fields [T], power converter's current [A], or electro-static wire voltage [V]).

I would reckon that the units library has more applications w.r.t. the second use-case domain but my peers may correct me on this.

Did you see a https://github.com/mpusz/units/blob/master/example/references/total_energy.cpp example

Yes. That's one of the use-cases we are interested in and prompted us to your library. 😃
Natural units are IMHO less common when you are dealing with interfacing with real-world hardware. The reason why I asked for an explicit _q_GeV_per_c2 is that many forget about the 'c' in GeV / pow<2>(c) when defining masses.

That's also the reason why I asked about the acceptable shortest short-hand notation because -- beside the simplest formulas -- these expressions can become very long if you have to express them in terms of gigaelectronvolt_per_speed_of_light_squared and gaelectronvolt_per_speed_of_light. These look nice from a principled standpoint but are IMHO not very practical in everyday applications.

But, please take this with a pinch of salt, since physicists often tend to take shortcuts to get the job done. 😉
This is one of the reasons why we'd like to introduce units as a core component into our library to help get some more type-/unit-safety into our accelerator/HEP world while still keeping the threshold for our peers low -- because if the cost-benefit-ratio isn't good, I will have a hard time encouraging my colleagues to accept this and the risk would be that they continue defining ad-hoc conversion factors ... [spiralling to an unpleasant place]

3. Or maybe natural units should be defined totally standalone from the SI system? [..]

I am not sure since I (personally) do not have a strong use case for such a unit system. One of my peers may comment on this.

[i-ky]

these expressions can become very long if you have to express them in terms of gigaelectronvolt_per_speed_of_light_squared and gigaelectronvolt_per_speed_of_light

I guess you should not use these in expressions. These should be used in (const) variable definitions and then (const) variables should be used in expressions. Otherwise you are effectively putting magic numbers into your expressions, which is not good in any case.