Skip to content

Mpes readd base classes #53

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
sanbrock merged 9 commits into from
Sep 5, 2023
Merged

Mpes readd base classes #53

Show file tree
Hide file tree
Changes from 4 commits
Commits
Show all changes
9 commits
Select commit Hold shift + click to select a range
0f1ab1f
Readds base classes for mpes (from commit 843283a)
domna Aug 9, 2023
d94a5ce
Readds mpes relevant changes from 4b064d9
domna Aug 15, 2023
99d43d9
Making ci/cd happy again
domna Aug 16, 2023
9db7a87
Revert to older classes
domna Aug 16, 2023
c83104e
Regeneration of the nexus file for fixing the changes coming from old…
RubelMozumder Aug 24, 2023
fa2bbb3
Merge pull request #57 from FAIRmat-NFDI/regen_mpes_readd-base-classes
RubelMozumder Aug 31, 2023
a093625
Revert changes to NXsample
lukaspie Aug 31, 2023
69f59bb
Merge branch 'fairmat' into mpes-readd-base-classes
lukaspie Aug 31, 2023
0308566
Typo fix
lukaspie Aug 31, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
150 changes: 92 additions & 58 deletions base_classes/NXaperture.nxdl.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,14 +1,14 @@
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="nxdlformat.xsl" ?>
<?xml-stylesheet type="text/xsl" href="nxdlformat.xsl"?>
<!--
# NeXus - Neutron and X-ray Common Data Format
#
# Copyright (C) 2008-2022 NeXus International Advisory Committee (NIAC)
# Copyright (C) 2014-2022 NeXus International Advisory Committee (NIAC)
#
# This library is free software; you can redistribute it and/or
# modify it under the terms of the GNU Lesser General Public
# License as published by the Free Software Foundation; either
# version 3 of the License, or (at your option) any later version.
# version 2 of the License, or (at your option) any later version.
Comment thread
lukaspie marked this conversation as resolved.
Outdated
#
# This library is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
Expand All @@ -21,76 +21,110 @@
#
# For further information, see http://www.nexusformat.org
-->
<definition xmlns="http://definition.nexusformat.org/nxdl/3.1" category="base"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://definition.nexusformat.org/nxdl/3.1 ../nxdl.xsd"
name="NXaperture"
type="group" extends="NXobject">

<doc>A beamline aperture. This group is deprecated, use NXslit instead.</doc>
<!-- TODO compare with "screens" in SHADOW -->

<definition xmlns="http://definition.nexusformat.org/nxdl/3.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" category="base" type="group" name="NXaperture" extends="NXobject" xsi:schemaLocation="http://definition.nexusformat.org/nxdl/3.1 ../nxdl.xsd">
<doc>
A beamline aperture. This group is deprecated, use NXslit instead.
</doc>
<!--TODO compare with "screens" in SHADOW-->
<field name="depends_on" type="NX_CHAR">
<doc>
NeXus positions components by applying a set of translations and rotations
to apply to the component starting from 0, 0, 0. The order of these operations
is critical and forms what NeXus calls a dependency chain. The depends_on
field defines the path to the top most operation of the dependency chain or the
string "." if located in the origin. Usually these operations are stored in a
NXtransformations group. But NeXus allows them to be stored anywhere.

The reference point of the aperture is its center in the x and y axis. The reference point on the z axis is the
surface of the aperture pointing towards the source.

In complex (asymmetic) geometries an NXoff_geometry group can be used to provide an unambiguous reference.

.. image:: aperture/aperture.png
:width: 40%
</doc>
<doc>
NeXus positions components by applying a set of translations and rotations
to apply to the component starting from 0, 0, 0. The order of these operations
is critical and forms what NeXus calls a dependency chain. The depends_on
field defines the path to the top most operation of the dependency chain or the
string &quot;.&quot; if located in the origin. Usually these operations are stored in a
NXtransformations group. But NeXus allows them to be stored anywhere.
The reference point of the aperture is its center in the x and y axis. The reference point on the z axis is the
surface of the aperture pointing towards the source.
In complex (asymmetic) geometries an NXoff_geometry group can be used to provide an unambiguous reference.
Comment thread
lukaspie marked this conversation as resolved.
Outdated
.. image:: aperture/aperture.png
:width: 40%
</doc>
</field>
<group type="NXtransformations">
<doc>
This is the group recommended for holding the chain of translation
and rotation operations necessary to position the component within
the instrument. The dependency chain may however traverse similar groups in
other component groups.
</doc>
<doc>
This is the group recommended for holding the chain of translation
and rotation operations necessary to position the component within
the instrument. The dependency chain may however traverse similar groups in
other component groups.
</doc>
</group>
<group type="NXpositioner">
<doc>
Stores the raw positions of aperture motors.
</doc>
</group>
<group type="NXgeometry" deprecated="Use the field `depends_on` and :ref:`NXtransformations` to position the aperture and :ref:`NXoff_geometry` to describe its shape">
<doc>
location and shape of aperture

.. TODO: documentation needs improvement, contributions welcome

* description of terms is poor and leaves much to interpretation
* Describe what is meant by translation _here_ and ...
* Similar throughout base classes
* Some base classes do this much better
* Such as where is the gap written?

location and shape of aperture

.. TODO: documentation needs improvement, contributions welcome

* description of terms is poor and leaves much to interpretation
* Describe what is meant by translation _here_ and ...
* Similar throughout base classes
* Some base classes do this much better
* Such as where is the gap written?
</doc>
</group>
<group name="BLADE_GEOMETRY" type="NXgeometry" deprecated="Use :ref:`NXoff_geometry` instead to describe the shape of the aperture">
<doc>location and shape of each blade</doc>
<doc>
location and shape of each blade
</doc>
</group>
<field name="material"><!-- TODO Uniformity problem, "type" is used elsewhere for same context -->
<doc>Absorbing material of the aperture</doc>
<field name="material">
Comment thread
lukaspie marked this conversation as resolved.
<!--TODO Uniformity problem, "type" is used elsewhere for same context-->
<doc>
Absorbing material of the aperture
</doc>
</field>
<field name="description">
<doc>Description of aperture</doc>
<doc>
Description of aperture
</doc>
</field>
<field name="shape">
<doc>
Shape of the aperture.
</doc>
<enumeration>
<item value="straight slit"/>
<item value="curved slit"/>
<item value="pinhole"/>
<item value="circle"/>
<item value="square"/>
<item value="hexagon"/>
<item value="octagon"/>
<item value="bladed"/>
<item value="open"/>
<item value="grid"/>
</enumeration>
</field>
<group type="NXnote"><doc>describe any additional information in a note*</doc></group>
<field name="size" type="NX_NUMBER" units="NX_LENGTH">
<doc>
The relevant dimension for the aperture, i.e. slit width, pinhole and iris
diameter
</doc>
</field>
<group type="NXnote">
<doc>
describe any additional information in a note*
Comment thread
lukaspie marked this conversation as resolved.
</doc>
</group>
<attribute name="default">
<doc>
.. index:: plotting

Declares which child group contains a path leading
to a :ref:`NXdata` group.

It is recommended (as of NIAC2014) to use this attribute
to help define the path to the default dataset to be plotted.
See https://www.nexusformat.org/2014_How_to_find_default_data.html
for a summary of the discussion.
.. index:: plotting
Declares which child group contains a path leading
to a :ref:`NXdata` group.
It is recommended (as of NIAC2014) to use this attribute
to help define the path to the default dataset to be plotted.
See https://www.nexusformat.org/2014_How_to_find_default_data.html
for a summary of the discussion.
</doc>
</attribute>
</definition>
143 changes: 140 additions & 3 deletions base_classes/NXbeam.nxdl.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -61,11 +61,45 @@
<doc>Distance from sample. Note, it is recommended to use NXtransformations instead.</doc>
</field>
<field name="incident_energy" type="NX_FLOAT" units="NX_ENERGY">
<doc>Energy carried by each particle of the beam on entering the beamline component</doc>
<doc>
Energy carried by each particle of the beam on entering the beamline component.

In the case of a monochromatic beam this is the scalar energy.
Several other use cases are permitted, depending on the
presence of other incident_energy_X fields.

* In the case of a polychromatic beam this is an array of length m of energies, with the relative weights in incident_energy_weights.
* In the case of a monochromatic beam that varies shot-to-shot, this is an array of energies, one for each recorded shot.
Here, incident_energy_weights and incident_energy_spread are not set.
* In the case of a polychromatic beam that varies shot-to-shot,
this is an array of length m with the relative weights in incident_energy_weights as a 2D array.
* In the case of a polychromatic beam that varies shot-to-shot and where the channels also vary,
this is a 2D array of dimensions nP by m (slow to fast) with the relative weights in incident_energy_weights as a 2D array.

Note, variants are a good way to represent several of these use cases in a single dataset,
e.g. if a calibrated, single-value energy value is available along with the original spectrum from which it was calibrated.
</doc>
<dimensions rank="1">
<dim index="1" value="m"/>
</dimensions>
</field>
<field name="incident_energy_spread" type="NX_NUMBER" units="NX_ENERGY">
<doc>
The energy spread FWHM for the corresponding energy(ies) in incident_energy. In the case of shot-to-shot variation in
the energy spread, this is a 2D array of dimension nP by m
(slow to fast) of the spreads of the corresponding
wavelength in incident_wavelength.
</doc>
</field>
<field name="incident_energy_weights" type="NX_NUMBER" units="NX_ENERGY">
<doc>
In the case of a polychromatic beam this is an array of length m of the relative
weights of the corresponding energies in incident_energy. In the case of a
polychromatic beam that varies shot-to-shot, this is a 2D array of dimensions np
by m (slow to fast) of the relative weights of the corresponding energies in
incident_energy.
</doc>
</field>
<field name="final_energy" type="NX_FLOAT" units="NX_ENERGY">
<doc>Energy carried by each particle of the beam on leaving the beamline component</doc>
<dimensions rank="1">
Expand Down Expand Up @@ -174,18 +208,59 @@
</dimensions>
</field>
<field name="incident_polarization" type="NX_NUMBER" units="NX_ANY">
<doc>Polarization vector on entering beamline component</doc>
<doc>
Incident polarization as a Stokes vector
on entering beamline component
</doc>
<dimensions rank="2">
<dim index="1" value="nP"/>
<dim index="2" value="2"/>
</dimensions>
<attribute name="units" type="NX_CHAR">
<doc>
The units for this observable are not included in the NIAC list.
Responsibility on correct formatting and parsing is handed to the user
by using `NX_ANY`. Correct parsing can still be implemented by using
this attribute.

| Fill with:

* The unit unidata symbol if the unit has one (Example: T for the unit of magnetic flux density tesla).
* The unit unidata name if the unit has a name (Example: farad for capacitance).
* A string describing the units according to unidata unit operation notation, if the unit is a complex combination of named units and
does not have a name.

Example: for lightsource brilliance (SI) 1/(s.mm2.mrad2).
Here: SI units are V2/m2.
</doc>
</attribute>
</field>
<field name="final_polarization" type="NX_NUMBER" units="NX_ANY">
<doc>Polarization vector on leaving beamline component</doc>
<doc>
Polarization as Stokes vector on leaving beamline component
</doc>
<dimensions rank="2">
<dim index="1" value="nP"/>
<dim index="2" value="2"/>
</dimensions>
<attribute name="units" type="NX_CHAR">
<doc>
The units for this observable are not included in the NIAC list.
Responsibility on correct formatting and parsing is handed to the user
by using `NX_ANY`. Correct parsing can still be implemented by using
this attribute.

| Fill with:

* The unit unidata symbol if the unit has one (Example: T for the unit of magnetic flux density tesla).
* The unit unidata name if the unit has a name (Example: farad for capacitance).
* A string describing the units according to unidata unit operation notation, if the unit is a complex combination of named units and
does not have a name.

Example: for lightsource brilliance (SI) 1/(s.mm2.mrad2).
Here: SI units are V2/m2.
</doc>
</attribute>
</field>
<field name="incident_polarization_stokes" type="NX_NUMBER" units="NX_ANY">
<doc>
Expand Down Expand Up @@ -245,6 +320,66 @@
<dim index="1" value="nP"/>
</dimensions>
</field>
<field name="pulse_energy" type="NX_FLOAT" units="NX_ENERGY">
<doc>
Energy of a single pulse at the diagnostic point
</doc>
</field>
<field name="average_power" type="NX_FLOAT" units="NX_POWER">
<doc>
Average power at the diagnostic point
Comment thread
mkuehbach marked this conversation as resolved.
Outdated
</doc>
</field>
<field name="fluence" type="NX_FLOAT" units="NX_ANY">
<doc>
Incident fluence at the diagnostic point
</doc>
<attribute name="units" type="NX_CHAR">
<doc>
Here: SI units are 'J/m2', customary 'mJ/cm2'.
</doc>
</attribute>
</field>
<field name="pulse_duration" type="NX_FLOAT" units="NX_TIME">
<doc>
FWHM duration of the pulses at the diagnostic point
</doc>
</field>
<field name="frog_trace" type="NX_FLOAT">
<doc>
FROG trace of the pulse.
</doc>
<dimensions rank="2">
<dim index="1" value="nx"/>
<dim index="2" value="ny"/>
</dimensions>
</field>
<field name="frog_delays" type="NX_FLOAT" units="NX_TIME">
<doc>
Horizontal axis of a FROG trace, i.e. delay.
</doc>
<dimensions rank="1">
<dim index="1" value="nx"/>
</dimensions>
</field>
<field name="frog_frequencies" type="NX_FLOAT" units="NX_FREQUENCY">
<doc>
Vertical axis of a FROG trace, i.e. frequency.
</doc>
<dimensions rank="1">
<dim index="1" value="ny"/>
</dimensions>
</field>
<field name="chirp_type" type="NX_CHAR">
<doc>
The type of chirp implemented
</doc>
</field>
<field name="chirp_GDD" type="NX_FLOAT" units="NX_TIME">
<doc>
Group delay dispersion of the pulse for linear chirp
Comment thread
mkuehbach marked this conversation as resolved.
Outdated
</doc>
</field>
<group type="NXdata">
<doc>
Distribution of beam with respect to relevant variable e.g. wavelength. This is mainly
Expand All @@ -265,6 +400,8 @@
</doc>
</attribute>



<field name="depends_on" minOccurs="0" type="NX_CHAR">
<doc>
The NeXus coordinate system defines the Z axis to be along the nominal beam
Expand Down
Loading