Update the list of emission lines

[mretegan]

Includes all emission lines listed in xraylib (see https://github.com/tschoonj/xraylib/blob/master/src/xrayvars.c)

[mretegan]

Extended the list to include the Siegbahn notation and added the mapping with IUPAC.

[mretegan]

Extended the Siegbahn-IUPAC correspondence following Table 2 from https://analyticalsciencejournals.onlinelibrary.wiley.com/doi/abs/10.1002/xrs.1300200308.

I have some doubts regarding the labeling of some L-lines. Are those Latin letters?

      <item value="Ll"></item>
      <item value="Ls"></item>
      <item value="Lt"></item>
      <item value="Lu"></item>
      <item value="Lv"></item>

[newville]

@mretegan Thanks for those changes!

[mretegan]

Extended the Siegbahn-IUPAC correspondence following Table 2 from https://analyticalsciencejournals.onlinelibrary.wiley.com/doi/abs/10.1002/xrs.1300200308.

I have some doubts regarding the labeling of some L-lines. Are those Latin letters?

      <item value="Ll"></item>
      <item value="Ls"></item>
      <item value="Lt"></item>
      <item value="Lu"></item>
      <item value="Lv"></item>

It appears that the names are indeed the ones above: https://physics.nist.gov/PhysRefData/XrayTrans/Html/search.html

[mretegan]

Do you think having the possibility to specify lines using Siegbahn notation will be used, or is it enough to just have the mapping with IUPAC names?

[mretegan]

@maurov @woutdenolf This is ready for review when you have time.

1. Siegbahn notation is not included in the list of available lines, but there is a table showing the correspondence between the two. The IUPAC notation is also used in xraylib and xraydb.
2. I added an energy field.
3. Because of 2, I renamed emission_lines to emission_line, which means that if we want to allow for multiple emission lines in another class, we will need to use NXcollection:

  <group name="emission_lines" type="NXcollection" optional="true">
    <doc>
      Collection of emission lines detected or used in this measurement.
    </doc>
    <group type="NXemission_line" minOccurs="1" maxOccurs="unbounded"/>
  </group>

In an HDF5, this will look like:

emission_lines/         (NXcollection)
  K-L2/                 (NXemission_line)
  K-L3/                 (NXemission_line)

[maurov]

@mretegan

Thanks for the nice work! It looks nice to me. I have only one remark: would it make sens to accept also a simpler Siegbahn notation as Xraydb is doing?

https://xraypy.github.io/XrayDB/overview.html#xraydb-lines-table

This said, I do not have a strong opinion on it and I think this can be merged as it is.

[mretegan]

@maurov I added the Latinized names.

I would like to merge this commit, but I need one of the reviewers to accept it 😄.

[maurov]

Fine for me

[woutdenolf]

One comment (something I learned recently): NXcollection is to be used by people who created HDF5 files and want to make any validator ignore the HDF5 group.

[woutdenolf]

@lukaspie @mkuehbach IIRC you guys encountered places where you needed an NX_class to group/enlist things. What NX_class did you use for that?

[lukaspie]

This is a topic that we also had: how to group a bunch of related concepts without needing to create base classes each time. Indeed, we went back and forth with NIAC on this.

Initially, we used NXobject as a 'bucket' to group other base classes, without needing to define a new base class for the bucket. There was also some discussion to create a new base class (e.g. NXbag) for the sole purpose of collecting related objects together.

Finally, we went with the more 'traditional' route: creating new base classes for these groupings (see also the longer-existing precedent of NXdetector_group). Here, we also made use of base class inheritance. IMO, this is still the best option if you want to be semantically correct (because you can define specific groupings for a particular purpose). The only concern voiced by NIAC was that there would be many more base classes. This is why we prefixed the domain-specific classes by the technqiue (NXem_*, NXspm_*, etc.). From the data modeling point of view, more classes is of course not problematic, but I think there was some software that had dropdowns to select classes, which would of course be harder the more classes you have.

All that being said, I don't think there was any great opposition to having NXbag (or even to using NXobject groups with nameType=partial), so if that is helpful for you, this discussion could possibly be reopened.

See discussion in nexusformat#1423 (comment). Hope this helps.

[mretegan]

@lukaspie Thank you for the feedback. It helps a lot!

While this is part of the things we need for the NXxas definition, I can make a separate pull request upstream to open the discussion in the next telco.

[woutdenolf]

We are using one HDF5 group for each line because of NeXus limitations right? nexusformat#1379

[mretegan]

We are using one HDF5 group for each line because of NeXus limitations right? nexusformat#1379

After adding the energy field, I thought it made sense to have NXemission_line as a single HDF5 group.

Now we need a way to specify multiple emission lines, and I thought that NXcollection would be okay, but if it is not validated, then it might be a problem.

[mretegan]

It would be nice to have in NeXus a way to group a bunch of similar things, even though such a deeply nested structure is generally discouraged.

I could easily create an NXemission_lines class to have strict validation. The HDF5 would look something like this:

/
├── entry:NXentry
│   └── emission_lines:NXemission_lines
│       ├── line_1:NXemission_line
│       │   ├── name = "K-L3"
│       │   └── energy = 5414.72   (units="eV")
│       ├── line_2:NXemission_line
│       │   ├── name = "K-L2"
│       │   └── energy = 5405.5    (units="eV")
│       └── line_3:NXemission_line
│           ├── name = "K-M3"
│           └── energy = 5946.7    (units="eV")