em proposal

[sanbrock]

No description provided.

[sanbrock]

https://fairmat-experimental.github.io/nexus-fairmat-proposal/d122a69ce0c953805e60a662e9580ee2c4a6fae7/index.html

[mkoennecke]

I do not understand the difference between NXlens and NXlens_em. NXlens seems to contain all the fields of NXlens_em too.

Is the scan box necessary? Is this not adequately described by NeXus scan conventions?

Should NXstage not be merged with NXsample?

[woutdenolf]

Tests are failing

======================================================================
ERROR: test__3__contributed_definitions__NXem_nion (test_nxdl.Individual_NXDL_Tests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/denolf/dev/nexus/definitions/utils/test_nxdl.py", line 56, in validate_xml
    result = NXDL_SCHEMA.assertValid(xml_tree)
  File "src/lxml/etree.pyx", line 3638, in lxml.etree._Validator.assertValid
lxml.etree.DocumentInvalid: Element '{http://definition.nexusformat.org/nxdl/3.1}symbols': This element is not expected. Expected is one of ( {http://definition.nexusformat.org/nxdl/3.1}doc, {http://definition.nexusformat.org/nxdl/3.1}attribute, {http://definition.nexusformat.org/nxdl/3.1}choice, {http://definition.nexusformat.org/nxdl/3.1}group, {http://definition.nexusformat.org/nxdl/3.1}field, {http://definition.nexusformat.org/nxdl/3.1}link )., line 271

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/denolf/dev/nexus/definitions/utils/test_nxdl.py", line 90, in test_wrap
    validate_xml(nxdl_file_name)
  File "/home/denolf/dev/nexus/definitions/utils/test_nxdl.py", line 61, in validate_xml
    raise NXDL_Invalid(msg)
test_nxdl.NXDL_Invalid: contributed_definitions/NXem_nion.nxdl.xml : Element '{http://definition.nexusformat.org/nxdl/3.1}symbols': This element is not expected. Expected is one of ( {http://definition.nexusformat.org/nxdl/3.1}doc, {http://definition.nexusformat.org/nxdl/3.1}attribute, {http://definition.nexusformat.org/nxdl/3.1}choice, {http://definition.nexusformat.org/nxdl/3.1}group, {http://definition.nexusformat.org/nxdl/3.1}field, {http://definition.nexusformat.org/nxdl/3.1}link )., line 271

======================================================================
ERROR: test__3__contributed_definitions__NXscanbox_em (test_nxdl.Individual_NXDL_Tests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/denolf/dev/nexus/definitions/utils/test_nxdl.py", line 56, in validate_xml
    result = NXDL_SCHEMA.assertValid(xml_tree)
  File "src/lxml/etree.pyx", line 3638, in lxml.etree._Validator.assertValid
lxml.etree.DocumentInvalid: Element '{http://definition.nexusformat.org/nxdl/3.1}symbols': This element is not expected. Expected is one of ( {http://definition.nexusformat.org/nxdl/3.1}doc, {http://definition.nexusformat.org/nxdl/3.1}attribute, {http://definition.nexusformat.org/nxdl/3.1}choice, {http://definition.nexusformat.org/nxdl/3.1}group, {http://definition.nexusformat.org/nxdl/3.1}field, {http://definition.nexusformat.org/nxdl/3.1}link )., line 5

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/denolf/dev/nexus/definitions/utils/test_nxdl.py", line 90, in test_wrap
    validate_xml(nxdl_file_name)
  File "/home/denolf/dev/nexus/definitions/utils/test_nxdl.py", line 61, in validate_xml
    raise NXDL_Invalid(msg)
test_nxdl.NXDL_Invalid: contributed_definitions/NXscanbox_em.nxdl.xml : Element '{http://definition.nexusformat.org/nxdl/3.1}symbols': This element is not expected. Expected is one of ( {http://definition.nexusformat.org/nxdl/3.1}doc, {http://definition.nexusformat.org/nxdl/3.1}attribute, {http://definition.nexusformat.org/nxdl/3.1}choice, {http://definition.nexusformat.org/nxdl/3.1}group, {http://definition.nexusformat.org/nxdl/3.1}field, {http://definition.nexusformat.org/nxdl/3.1}link )., line 5

[prjemian]

The <symbols /> block must appear before the <doc /> block.

[mkuehbach]

Wrt to mkoennecke comments from March 4th:
I do not understand the difference between NXlens and NXlens_em. NXlens seems to contain all the fields of NXlens_em too.

Indeed this was confusing if not incorrect. So I decided to drop NXlens_em from the proposal and propose NXlens.
There is currently only an NXxraylens but for electron microscopes using this is confusing not only because the lens designs and possible fields to store with electro-magnetic lenses, the physical characteristics are different, maybe it is possible to have at some point only one NXlens that could cater for different types of radiation. Then however the need for NXxraylens becomes questionable...

Is the scan box necessary? Is this not adequately described by NeXus scan conventions?

At the point when I proposed this I was not aware of NXscan. Now I inspected NXscan.
NXscan defines a generic scan-type instrument which takes a sample, scans and measures something, and the next user comes.
Indeed NXscan would apply for some modes how electron microscopes in some routine applications and
imaging modes are used. So yes one could design the application definition for say an secondary electron image
taking electron microscope just based on NXscan and some customization but this does not cover the general
more flexible usage of electro microscopes (EM) where the EM is like an electron beam line.
Multiple detectors are used, correlatively, eventually some scan measurements on the same specimen are taken
while the user is at the instrument. So to reflect this I would had anyway to substantially reformulate the docstrings
in NXscan. I decided instead for generalizing NXem_nion into an NXem that can take account of these flexible
correlative data acquisition techniques.

Should NXstage not be merged with NXsample?

No I don't want this, but yes, conceptually in principle. It is a matter of debate. My aims are clear. It turned out that the discussion what exactly is the stage returned not a clear picture across electron microscopists. Usually stages nowadays are rather hierarchical arrangements of specimen fixtures. Virtually in all cases these fixture arrays are physically connected with the instrument. In that sense the stage is an entire lab of individual hierarchical components some of which user of an electron beamline find and need to have precise control over, some components the user customize, as they might bring their own fixtures which are then just mounted onto the stage.

In NeXus it seems the NXsample is the physical piece of material (the sample/specimen) + its environment, okay and this "and the environment" brings the question where do we draw the thermodynamic/conceptual boundary between where does this environment physically and conceptually end. An specimen in an EM during operation has a number of relevant environments to distinguish (near surface interaction with the chamber atmosphere, especially in environmental SEM, charging, build up of contamination) etc.
The environment in which a sample is and the stimuli which the sample is exposed, yes they could be described
as a part of the environment but isnt then the microscope then the environment, what about electron magnetic fields.
All of these stimuli anyway need to be measured and where should these sensor readings and associated data be stored then.

Thank you very much for your suggestions.

[mkuehbach]

wrt to the comments of prjemian and woutdenolf:
Which tool have you used for this verification, then I can run our NXDL also through it before we upload it, thanks for point me to this both of you and the suggestions

[woutdenolf]

@mkuehbach I always do make local (result will be in the ./build directory). This runs both the tests and HTML building.

[prjemian]

LGTM as contributed