diff --git a/applications/NXarpes.nxdl.xml b/applications/NXarpes.nxdl.xml
index 8d17472ad3..e506cd3d29 100644
--- a/applications/NXarpes.nxdl.xml
+++ b/applications/NXarpes.nxdl.xml
@@ -3,7 +3,7 @@
@@ -114,7 +135,7 @@ cannot be made required as for simulations you do not have a run number!
should be stored as individual :ref:`NXentry` instances in one NeXus file.
-
+
Either an identifier or an alias that is human-friendly so that scientists find that experiment again.
For experiments usually this is the run_number but for simulation typically no run_numbers are issued.
@@ -167,6 +188,11 @@ the appdef definition here is nothing else then the documentation of this for a
when the atom probe session ended.
+
+
+ How long did the measurement take e.g. use CRunHeader.CAnalysis.fElapsedTime
+
+
@@ -454,7 +480,7 @@ schema for heat treatment
-
+
Set to hold different coordinate systems conventions.
Inspect the description of the :ref:`NXcoordinate_system_set`
@@ -512,162 +538,250 @@ schema for heat treatment
-
-
-
-
+
+
+ Base class for collecting a session with a real atom probe or field-ion microscope.
+
+ Workflows used during experiments or simulations of atom probe and related field-evaporation
+ research should be documented in more detail and be better contextualized not only because of
+ ongoing developments and the tighter becoming connection between atom probe and other
+ methods for material characterization foremost electron microscopy see e.g.:
+
+ * `T. Kelly et al. <https://doi.org/10.1017/S1431927620022205>`_
+ * `C. Fleischmann et al. <https://doi.org/10.1016/j.ultramic.2018.08.010>`_
+ * `W. Windl et al. <https://doi.org/10.1093/micmic/ozad067.294>`_
+ * `C. Freysoldt et al. <https://doi.org/10.1103/PhysRevLett.124.176801>`_
+ * `G. da Costa et al. <https://doi.org/10.1038/s41467-024-54169-2>`_
+
+ to mention but a few.
+
+ To arrive at a design of base classes and an application definition that can be used
+ for both real and simulated atom probe experiments it is worthwhile to recall concepts that are
+ related to events and (molecular) ions:
+
+ * Pulsing events which are used to trigger ion extraction events.
+ * Physical events and corresponding signal triggered by an ion hitting the detector.
+ Some of these events are not necessarily caused by or directly correlated with an identifiable pulsing event.
+ * Processed ion hits which are the result of an algorithm that took the physical and pulsing events as input
+ and qualified some of these events as to be of sufficiently high quality to call them (molecular) ions that are
+ wortwhile to be considered further and eventually included in the reconstructed volume.
+ * Calibration and signal filtering steps applied to these processed ion hits as input which results in actually
+ selected (molecular) ions based on which an instance of a reconstruction is created.
+ * Correlation of these ions with a statistics and theoretical model of mass-to-charge-state ratio values
+ and charge states of the (molecular) ions to substantiate that some of these ions can be considered
+ as rangable ions and hence an iontype can be assigned to these via running peak finding algorithms
+ and subsequent peak labeling. In the field of atom probe this these peak identification methods
+ are known as ranging definitions.
+
+ Not only in AMETEK/Cameca's IVAS/APSuite software, which the majority of atom probers use, these concepts
+ are well distinguished. However, the algorithms used to transform correlations between pulses and physical events
+ into actual events (detector hits) ions is a proprietary one - the so-called hit finding algorithm.
+
+ Due to this practical inaccessibility of details, virtually all atom probe studies currently use a reporting scheme
+ where the course of the specimen evaporation is documented such that quantities are a function of evaporation identifier
+ i.e. actual event/ion, i.e. after having the hit finding algorithm and correlations applied.
+ That is evaporation_identifier values take the role of an implicit time and course of the experiment given that
+ ion extraction physically is a sequential process.
+
+ There is a number of research groups who build own instruments and share different aspects of their technical
+ specifications and approaches how they apply data processing e.g.:
+
+ * `M. Monajem et al. <https://doi.org/10.1017/S1431927622003397>`_
+ * `P. Stender et al. <https://doi.org/10.1017/S1431927621013982>`_
+ * `I. Dimkou et al. <https://doi.org/10.1093/micmic/ozac051>`_
+
+ to name but a few.
+
+ Despite some of these activities embrace practices of open-source development, they use essentially the same
+ workflow that has been proposed by AMETEK/Cameca and its forerunner company Imago: A graphical user interface
+ software is used to explore and thus analyze reconstructed atom probe datasets.
+
+ Specifically, software is used to correlate and interpret pulsing and physical events into processed ion hits.
+ Some of these ion hits are reported as (molecular) ions with ranged iontypes to yield a dataset based on which
+ scientific conclusions about the characterized material volume are made. Also here a reconstruction is
+ point cloud that serves as the proxy for the characterized material volume, i.e. the reconstruction is a model.
+
+ By contrast, simulations of field-evaporation have the luxury to document the flight path and allow a following of all
+ the whereabouts of each ion evaporated if this is desired. This level of detail is currently not characterizable in experiment.
+ Thus, there is a divide between schemas describing simulations of atom probe vs measurements of atom probe.
+ We argue that this divide can be bridged with realizing the above-mentioned context and the realization that
+ similar concepts are used in both research realms with many concepts not only being similar but being exactly the same.
+
+ A further argument to support this view is that computer simulations of atom probe usually are compared to reconstructed
+ datasets, either to the input configuration that served as the virtual specimen or to a real world atom probe experiment
+ and reconstructions computed from these. In both cases, the recorded simulated physical events of simulated ions hitting
+ a simulated detector is not the end of the research workflow but typically the input to apply additional algorithms such as
+ (spatial) filtering and reconstruction algorithms.
+
+ Only the practical need for making ranging definitions is (at least as of now) not as much needed in field-evaporation
+ simulations than it is in real world measurements because each ion has a prescribed iontype in the simulation.
+ Be it a specifically charged nuclid or a molecular ion whose flight path the simulation resolves.
+ Although, in principle simpler though, we have to consider that this is caused by many assumptions made in the simulations.
+ Indeed, the multi-scale (time and space) aspects of the challenge that is the simulating of field-evaporation often require
+ simplifications because of otherwise too high becoming computing resource demands and existent knowledge gaps
+ in how to deal with all quantum physics complexities. Molecular ion dissociation upon flight is one such complexity.
+ Also the complexity of simulation setups is typically defined simpler in simulation (e.g. straight flight path assumption)
+ than in a measurement with a real instrument. In addition, simulation often also ignore objects and fields in the flight path
+ such as local electrodes or physical obstacles and electric fields (controlled or stray fields).
+
+
+
+
-
+
-
+
-
-
-
-
-
-
-
+
-
+
-
+
-
-
+
+
-
-
-
- The wavelength of the radiation emitted by the source.
-
-
-
-
-
-
- The space inside the atom probe along which ions pass nominally
- when they leave the specimen and travel to the detector.
-
-
-
-
-
+
+
+
+ Free text field for additional comments.
+
+
-
-
-
+
+
+ A statement whether the measurement was successful or failed prematurely.
+
+
+
+
+ CAnalysis.CResults.fQuality
+
+
+
+
+
+ Group to hold instances of :ref:`NXevent_data_apm`.
+
+ Which temporal granularity is adequate depends on the situation and research
+ question. Using a model which enables a collection of events offers the most
+ flexible way to cater for both atom probe experiments or simulation.
+
+ To monitor the course of an ion extraction experiment (or simulation)
+ it makes sense to track time explicitly via time stamps or implicitly
+ via e.g. a clock inside the instrument, such as the clock of the pulser
+ and respective pulsing event identifier.
+
+ As set and measured quantities typically change over time and we do not
+ yet know during the measurement which of the events have associated
+ (molecular) ions that will end up in the reconstructed volume, we must not
+ document quantities as a function of the evaporated_identifier but as a
+ function of the (pulsing) event_identifier.
+
+
+
+
+
-
-
-
-
+
+
+
-
-
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
-
-
-
+
+
+
+
+
-
-
-
-
+
+
+
+
+
-
+
+
-
-
+
+
+
-
-
-
-
+
+
+
-
+
+
+
+
+
-
-
+
+
+ Simulation of ion extraction from matter via laser and/or voltage pulsing.
+
+
+
A region-of-interest analyzed either during or after the session for which
specific processed data of the measured or simulated data are available.
-
-
+
- SEM or TEM image of the initial specimen i.e.
- ideally taken prior to the data acquisition.
+ SEM or TEM image of the initial specimen (ideally taken prior data acquisition).
@@ -688,9 +802,17 @@ NEW ISSUE: make this rather an own subentry NXapm_ranging-->
-
+
+
+ For almost atom probe instruments (meta)data about raw data follow proprietary semantics.
+ Therefore, this group can currently be used only to point to these digital artifacts
+ in an effort to document all step of an analysis workflow.
+
+ The physical quantities measured in an atom probe experiment are time-of-flight and
+ tuples of arrival_time_pairs as a function of the event chain on the pulser.
+ From these tuples hits are computed in a process called hit_finding.
+
@@ -701,11 +823,46 @@ a time series of the specimen shape evolution-->
-
-
+
+
+
+
+
+ The number of wires in the detector.
+
+
+