Alex Reichmann's comment 2023/06/09: This could be a misleading naming convention because is it the NOMAD OASIS user or is it the creator of the specimen or is it the technician or is some other person(s)

Currently only the filename, paraprobe-toolbox==0.4 assumes that config for tool run is in the working directory

this is a bug, should be named cumulated and there should be another field cumulated_normalized(NX_FLOAT) for the normalized values of the cumulated(NX_FLOAT) field

same story for the rdf group

Currently only the filename, paraprobe-toolbox==0.4 assumes that config for tool run is in the working directory

this is a bug, paraprobe-toolbox will write volume_volume_spatial_correlationID

this is a bug in this appdef, paraprobe-toolbox==0.4 writes out start_time and end_time like for all other NXapm_paraprobe_results_* appdefs these timestamps are again ISO8601 compliant timestamps

appdef needs to be changed here, paraprobe-toolbox==0.4 currently reports ROI without a clear group (which should be changed in the paraprobe-nanochem source code) but also the fields signed_distance and isotope are not scalars but arrays of the same length [k] although that length may different for each instance of a ROI

It would be possible to add a default plot for every single ROI in this way the classical proxigram could be displayed directly using H5Web, the key overhead which comes with this is the need for very many small data entries which likely blow up the HDF5 file unnecessarily, for this reason currently such default plot is not exported

there is a bug in this appdef in that the shape of these arrays must not be denoted with i because they are not necessarily the same as ofr the center and orientation arrays. Instead, these arrays have as many values (all the arrays) as are needed to visualize the ROIs using XDMF. Specifically these arrays are the geometric primitive property array whereby e.g. Paraview identifies how to color each primitive, paraprobe-toolbox==0.4 reports this situation correctly but the appdef does not reflect it yet

should be changed to plural "volumetric_features"

postponed because will in the future use the NXms_feature_set instances

fix the application definition that these are rendered out correctly, in paraprobe-toolbox==0.4 these have been deactivated and will be fixed with the next bug fix release to show directly in H5Web

make this all into one match filter based on isotope_vectors as these can represent elements/atoms and specific combinations of ions (molecular ions)

Currently only the filename, paraprobe-toolbox==0.4 assumes that config for tool run is in the working directory

this has to be 4 because paraprobe-toolbox==v0.4 reports a four-column array where indeed the first three columns are the mentioned angles but the last column is the sum of the interior angles

here is a bug in the appdef initial_interface(NXprocess) and point_normal_form is a field of this group, paraprobe-toolbox==0.4 does it correctly this way

fitted initially

correct formatting

would need a clearer explanation

with which the ion

with which the ion

this is a bug, it has to be charge_state because charge should have a unit

this is a bug, it has to be charge_state because charge should have a unit

fix mathematical notation

this is a bug because feature_type_dict is optional so one cannot in all cases "need to register" them, has functionally though no effect on computed results for paraprobe-toolbox==0.4

this is a bug and has to be removed paraprobe-toolbox==0.4 understands objects as features which need to be watertight!

fix mathematical notation

make consistent with NXapm_paraprobe_config_nanochem and name phi with the next release

fix the application definition that these are rendered out correctly, in paraprobe-toolbox==0.4 these have been deactivated and will be fixed with the next bug fix release to show directly in H5Web

add a hint that this is also for the visualization with paraview

add a note what happens in case the coordinate system is not added, for paraprobe-toolbox==0.4 the default coordinate system takes precedence

this is a known bug in paraprobe-toolbox==0.4 which does not affect the functionality though, bool isosurfaceHdl::write_vxlizer_task_info_h5( vector<p3dinfo> const & iinfo ) does not report which isotope_whitelist was used, instead inspect the config file

needs to be DELOCALIZATION

Currently only the filename, paraprobe-toolbox==0.4 assumes that config for tool run is in the working directory

is number_of_ions instead of number_of_points, values are correctly reported, this is a bug of this appdef (for all wall_contact_* groups)

conditional required not implemented for NeXus

Currently only the filename, paraprobe-toolbox==0.4 assumes that config for tool run is in the working directory

Sentence has to be changed to reflect that if window_triangles is not provided it means that all triangles were taken

optional constraints not implemented yet

Currently only the filename, paraprobe-toolbox==0.4 assumes that config for tool run is in the working directory

must not be required, paraprobe-toolbox==0.4 does not report this by default

this should not always be repeated but instead inferred from the parent group?

check formatting of the NXDL to RST conversion

Currently only the filename, paraprobe-toolbox==0.4 assumes that config for tool run is in the working directory

Currently only the filename, paraprobe-toolbox==0.4 assumes that config for tool run is in the working directory

deprecated this field is no longer required because ions have now by default a charge state if that was recoverable via the combinatorial analyses performed by ifes_apt_tc_data_modeling package otherwise the charge_state is set to 0

Currently only the filename

ifes_apt_tc_data_modeling==0.0.6 returns this as Da while it should be atomic mass unit per Coulomb (u/C)

this can be considered a bug in both the appdef and the implementation of paraprobe-parmsetup-nanochem: paraprobe-toolbox=v0.4 expects here a field named isotope_whitelist(NX_INT) of length (n_filter, 32) the docstring/meaning of decorating_iontypes_filter group is correct and how v0.4 interprets the isotope_whitelist e.g. setting a isotope_whitelist of 5, 0 ... (with 32-1 zeros following) instructs the code to take all molecular ions with boron and assume that these ions decorate the defect, a subset of the point cloud including these ions is computed and the interface model fitted

what happens if these are defined in a different coordinate system? currently, it is the users responsibility to define them in the paraprobe coordinate system, Alexander Reichmann: Does your tool flip the reconstruction to accommodate for the fact that different versions of IVAS may use different local coordinate systems?

pierces or is laying

what happens if this occurs? currently the code detects this and stops in a controlled manner so that the user can repeat the analyses with a smaller value

conditional required currently not support by NeXus, if normalization is total paraprobe-toolbox==0.4 currently creates an empty but existent field named isotope_whitelist, this field should be removed in future version

as in atom probe tomography ...

also a note of caution should be given that the results from fairing operations should also be compared to object populations where all objects at the edge of the dataset have been removed

use Latex notation

use Latex notation

an optimization of this algorithm using a two-step procedure (explicit narrow kernel first followed by a fast fourier transform adding in quadrature) is possible but has not been implemented.

when the delocalization was computed the first place

not needed any longer paraprobe-toolbox==0.4 detects number of groups automatically

should be tessellation and would be good to have e.g. NXcg_tiling base class

neither available nor used in paraprobe-toolbox==0.4

objective_lens_mode illumination_mode probe_mode image_mode field_mode spot_size or NXbeam geometry probe_size

how they are defined should refer to an NXtransformations object which itself then refers to an instance in NXcoordinate_system_em in this way the values of tilt and position can always be interpreted and/or transformed into other representations

add description for NXcoordinate_system as details

eventually should be replaced like all other fields name value as set_point_value to communicate clearer the intention and meaning of the field

add an field called data_source(NX_CHAR): an array of strings specifying which sources were parsed to fill an instance of NXem, maybe but this also in the top-level entry section next to program and program/version

example of a field for which one could also argue it would be useful if its type would be allowed to come from two sets, i.e. a link/reference or a string.

should be understood as a reference to a source of pieces of information in some system (file, research data management system) which specifies further details of what happened

affiliation is nothing but an organization unit, maybe have it a base class like NXlocation which can then have address, name, identifier etc...

unless the data in these fields follow own documented schema this is not matching FAIR so consider to remove these entries

experiment_identifier_type https://raw.githubusercontent.com/kit-data-manager/Metadata-Schemas-for-Materials-Science/main/TEM_schema.json Better however would be to have a base class NXidentifier which then has value and type and then experiment_identifier(NXidentifier)

Data schemes are a graph: It is noteworthy to ....

is a graph .... NeXus specifically offers not only terms and an associated structuring of these (taxonomy) but also relations between items. This makes NeXus base classes and application definitions an ontology. Ontology and instance of ontology with real data i.e. knowledge graph are two different things. Namely the application definition specifies if a field is required or optional and thus sets constraints on their existence. Exactly these constaints though are not necessarily relevant or specific enough for specific applications.

paraprobe_toolbox==0.4 does not export this NX_class group attribute

these are not used, paraprobe-toolbox==v0.4 assumes there is only a single process in this NXprocess group

should be "mobility_weight"

add: is_boundary(NX_UINT) "Halo region" [1, n_front]

"domain" boundaries of the "simulation box"

paraprobe-toolbox==0.4 expects the file referred to here located in the current working directory

conditionally different types of units not supported yet in NeXus, paraprobe-toolbox==0.4 currently reports alpha values with unit nm^2 (square of the radius of the carving spoon) and nm if it is the alpha for the first parameter of sets of alpha wrappings

conditional requirements not yet supported

one bug in this version of the NXapm_paraprobe_config application definitions specifically the spatial_filter primitive sets is that they state that fields like vertices are scalars while in paraprobe-toolbox==0.4 these are arrays, this bug has no consequences though for the functioning of the v0.4 tools

analysis_identifier should be made required for all NXapm_paraprobe_config/results_*

this is a bug, has to be ROI_SELECTION for future versions of paraprobe-toolbox, currently this group is named "process1" with which functionality-wise there is no problem for paraprobe-toolbox==0.4

name has to be changed to volume_volume_spatial_correlationID to reflect that this field can have more than one group

same bug as with current_set/FEATURE/feature_identifier, has to be an array of (j,)

this must not be a scalar but an array of length (i,)

should be featureID (here discussion with members from FAIRmat Area B needed)

link to the publication, also for the same field under next_set

should be a set of (microstructural) features

conditional required not supported and not required for specific values of ion_query_type_source because e.g. for resolve_all it is clear that each ion will be accounted for so no need for further specifications

also add how many times and ion is accounted for for resolve_all, _unknown, etc.

remove "of" for grammar and readability also in other places in these docstrings

this field name is wrong paraprobe-toolbox==0.4 expects randomize_ion_types

here the application definition is incorrect, this spatial_statistics should be nested into another NXprocess group, implementation in paraprobe-toolbox==0.4 is correct but appdef does not reflect this, content inside spatial stats okay though

has to be changed to "Name" because, currently can be prefixed with a path

this can be a relative or absolute path

paraprobe returns also "volume(NX_FLOAT)" as field unit nm^3 which is the used reconstructed volume per ion (average) from the ranging definitions file if available

currently ifes_apt_tc_data_modeling==0.0.6 and the paraprobe-toolbox yield here no unit or eV but it should be NX_UNITLESS as it is a multiplier which specifies the charge of the ion in multiples of the elementary charge instead a new field "charge(NX_FLOAT)" should be added whose unit is C

needs to have a unit!

not yet documented here is the sub_group charge_model which comes from the combinatorial analysis that is performed for each range to try to identify which charge state does this ion have

terms charge and charge_state should be distinguished charge_state is the multiplier how many times an ion observable in atom probe is positively charged i.e. multiples of an electrons charge but as charge unit is Coulomb one can also argue that mass_to_charge diagram has atomic mass unit / Coulomb as its unit, however the number is the same is one talks about mass_to_charge_state_ratio where the unit then would be atomic mass unit / 1 i.e. atomic mass unit

all NX_BOOLEANs currently stored as uint8

is currently optional

currently a field under the snapshot than an own group

grain_ensemble

recrystallization

should be intended and stored in "grid"

or alternatively an InChi identifier

Add a comment that this design is too much focused on conventions useful for the research field of atom probe tomography. We appreciate there are more general descriptions like InChi which include details about the structure of the molecular ion, H-H+ is a good example https://webbook.nist.gov/cgi/inchi?ID=C12184906&Mask=1000

is on to be labelled with ion_identifier. The field is primarily of interest to document the result of indexing a ToF/mass spectrum.

drop _state it is really a charge

mass number

matrix which decodes the isotope_vector

rank = 2 [1, 1], [2, n_ivecmax])

status how the experiment ended (fracture, stopped, etc.)

evaporation control

use ion_sequence_id instead of evaporation_id if the evaporation_id_included probes a continuous section then this field also defines implicitly the Vstart and Vend but maybe it is better to give an own field for each

add: atomic volume, detection efficiency, electric field (assumptions), final specimen state, pre, post image analysis,

a reference to three images taken as recommended by cameca, before or after, radius evolution model, field factor, image compression

default statistics would be good to report as output e.g.

total ions (single, multiple, partial) reconstructed ions (ranged, unranged) voltage and bowl calibration (peak) mass_calibration as an own field

several programs and libraries are usually coupled together for LEAP instruments, if it is possible to have a different root version with a different ivas/apsuite version that having a single program and version field is not enough but multiple are required

e.g.: LAS root version camecaroot version analysis software

mass_calibration for stretching the raw time of flight to mass-to-charge data should be added with positions of peaks used for calibrating what exactly

do not use evaporation_identifier but ion_sequence_number

vendor_result_file(NX_CHAR): doc: | The name of an immutable file which contains the measured data in their most unprocessed form. The necessity for having such a field is that most measurements in atom probe are performed with commercial instruments for which results such as the raw time of flight and detector event data are stored in a proprietary representation (e.g. file). Examples are RHIT and HITS files whose content is not accessible with software other of the instrument manufacturer (AMETEK/Cameca). Therefore, we cannot safely assume that all relevant content from the measurement can be transcoded into a more accessible and documented digital form other than via processing the vendor_result_file with the commercial software (e.g. IVAS/APSuite) and doing so with a specific version (referred to under program/@version). Although many results from the measurement can be transcoded into more accessible formats like APT as well as ePOS or POS, this transcoding happens via the same proprietary software which may use or not numerical algorithms which are not fully documented but process the data. In effect, all relevant scientific results are affected including key results like calibrated time of flight, and thus mass-to-charge-state ratio values, and thus reconstructed ion positions and ranging definitions derived from the mass-to-charge-state ratio histogram. We are aware that not every such processing substantially modifies the data so that this would lead to substantial different numerical results. However, that is an assumption which in order to be proven demands that it is always possible to recompute the vendor_result_file using the specific version of the program in such a way that the same i.e. deterministic binary results are achieved. We have to assure that such dataset in a research data management system which rely on such proprietary procedures, irrespective how how sophisticated they are or not must keep a documentation of the provenance. Otherwise the data are not even reproducible and thus not meeting the R of the FAIR principles. Therefore, the fields program, program/@version, and vendor_result_file and /@version are required.

For users of the NXapm application definition for which all relevant quantities can be stored using the data structures in the NXapm schema, there is factually no need for specifying a vendor_result_file. The key point is that vendor_result_file should give a statement of what is the immutable data representation of the experiment. If this is already realized via using NXapm throughout and thus there is no need for a vendor_result_file, in this case the users should store the value EXPERIMENT_NXAPM_INSTEAD_OF_PROPRIETARY under vendor_result_file and 0 for its version SHA256 checksum. The only other special case and value for vendor_result_file is that of a computer simulation of a virtual specimen with tools like TAPSim and those of the GPM and Oxford groups. In this case no measurement is performed and thus SIMULATION_NXAPM_INSTEAD_OF_PROPRIETARY should be used. \@version(NX_CHAR): doc: SHA256 checksum of that file.

for the invizo 6000 instrument it makes sense to add at least groups for the two additional lenses whereby the field of view is brought from 50-60 to at most 100 the key invention

add: decelerating_electrode(NXlens_em) accelerating_mesh maybe needs an own base class

I suggest that this section should be reworked with the local_electrode being required and all other components and opposite counter_electrodes being optional WO2016171675A1 details the key specifications of the components and the setup

call this energy_compensation(NXreflectron) can be a Poschenrieder lens US patent 3863068 or a reflectron US patent 6740872 the curved reflectron us patent 8134119

other sources of pulsers are possible: see in WO2016171675A1 invizo 6000 patent from ametek

also termed counter_electrode or extraction_electrode

this is the relevant patent for the invizo 6000 WO2016171675A1

so far the application definition does not really cover fim as there is no place to store values for a gas injection system and a (partial) pressure sensor for the imaging gas it should be clarified in the docstring of the pressure field if this measured either a chamber total of a species partial pressure

add NXapm_energy_analyzer, a voltage grid like done in Rouen/GPM

https://www.youtube.com/watch?v=99hNEkqdj78t=1876s

Eventually also add a section instrument_calibration(NXcollection) where the gridded-counter-electrode shadow image polyline fits are exported as NXcg_spline_set see also https://www.youtube.com/watch?v=99hNEkqdj78t=2348s

eventually one may wish to store values from an NXmonitoring tracking the DLD signal amplitude (mV) = f(t)

add section for propagation_delay(NXprocess) ?

move raw_tof and calibrated_tof under tof_calibration coming before the voltage and bowl correction add a sequence_id for each process to add which step comes first in the pipeline

this should be an NXprocess m/n = 2ealpha(Vdc+beta*Vpulse)((t-t0)/L)^2 maybe a mistake in the equation?, Slide7 from the conference incorrect?

add: start_voltage(NX_FLOAT) and end_voltage(NX_FLOAT), eventually also monitor Kp values from pulser etc

check also here the PYCCAPT pipeline from P. Felfer's group

addition of a NXfurnace in which one can define the atmosphere and partial pressures of the agents in that atmosphere with which the sample was annealed at which temperature see the work happening at PNNL

add an estimated_field(NXcollection) field_at_the_apex(NX_FLOAT) shape(n_ions, 1)

maybe make this an (NXmonitor) and then also the voltage curve or all often discussed quantities can be an NXmonitor voltage_curve(NXmonitor): voltage = f(evaporation_id)

also a monitor for Saxey plot i.e. mass correlation plots for on the same hit coming signals

add xdmf_topology(NX_UINT) array to visualize the specimen

add: a field for chamber geometry via NXcsg, also for the other chambers, add fitted field https://researchdata.edu.au/spatial-reconstruction-parameters-common-minerals/1792332

add: NXcsg to describe the specimen geometry

add a default plot V = f(time/evaporation_id), essentially for each quantity

add a base class for spatial statistics / correlation statistics SRO equations, kNN, RDF, n-point statistics

image compression factor(NX_FLOAT), dimensionless, ICF kf field factor NX_FLOAT, dimensionless ?

NXapm_detector_stack as a base class which has then - NXdata for the stack - possibility for instances of NXcg_circle_set to mark positions of specific peaks - add NXcg_circle_set for each circle would be nice to have a place where one can store LaTeX-formatted UTF-8 text - conceptualize also a default plot for overlaying a stereographic or equidistant projection

detection_rate but is this not the target_detection_rate ?

move to laser_gun

is this the pulse_rate?

it would be good to have an application definition NXicp for chemical composition

electric_field_estimation(NXprocess) or something like this to describe the details of the Kingham curve analyses differently charged ion ratio = f(evaporation_id)

see https://en.wikipedia.org/wiki/Einzel_lens for details double einzel lens in the invizo 6000 according to A. Breen (UNSW)

this has to be improved, interview atom probers on how they add the charge state or know the charge state

add target_detection_rate(NX_FLOAT)

rename to LASER_SOURCE because the Invizo 6000 has a dual laser or should the dual laser be considered as one component

NXdecelerating_mesh and check counter-electrode again

Milling and lift-out https://patents.google.com/patent/US8789826?oq=%22atom+probe+tomography%22

Add a specific cryo_transfer(NXchamber)

A key question raise by the https://raw.githubusercontent.com/kit-data-manager/Metadata-Schemas-for-Materials-Science/main/SEM_schema.json schema proposal is how to handle correlative results. My personal opinion is that this is should be thought and stored in such a way that data are automatically correlateable. Take an example. A frequent situation in SEM is the beam scans a ROI while n detectors take different signal. In this case usually the control software/tools of the individual detectors either assures that the collection of the signals is already synced or it has to be synced later. Syncing later can essentially happen if one e.g. collects data at such a high frame rate that only an additional hardware tool can manage the stream of incoming data and these come with an own time code. And thats the point if the signals individually have a time-code they should be stored such that we can get an answer for, when was the beam illuminating what and what during that point/interval was happening with each detector. Maybe a 1d, 2d, signal was captured. In this way we leave it open from a data modeling point of view to say that the results form a collection of signals which can be used for correlative analyses. Instead we have a description which a machine can understand by arranging the signal streams on the time axis and if we then ask, are there pieces of information / signals within time [t, t + deltat] what is available? With this we discuss the important case of correlation analysis not just from the perspective of what the research intended but we give already all these pieces of information which somebody else would need if one were to repurpose the data for a different study. In this case either we get an answer if we have detector readings for [t, delta +t ] if yes, we can use these data, if not there is likely no algorithm that can recover these data as they simply havent measured

if then a certain parser already aggegates the time stamped data and syncs them so that the scientists gets an easier representation for the study for which the measurement was originally performed this is an additional advantage but storing only this already "synced" data makes the representation unnecessarily limited wrt to possible repurposability of the data. https://www.cambridge.org/core/journals/microscopy-and-microanalysis/article/5dstem-live-processing-and-display-at-15000-diffraction-patterns-per-second/ACE6E17B131FC599D731310BFDB2D227

angle to the electron beam gun pressure, gas injection system (maybe a base class) deposition_current, deposition_size, deposition_time

electron beam deceleration is currently not handled, landing_energy, stage_bias, e.g. also grid in front of SE detectors

instances of NXimage_set should have a field for the tilt_correction in the case of se detectors

additional descriptions can be added such as the shape and form of the sample as additional named field but it would be better to use instances of e.g. NXcg_ base classes as these have many of the shape and geometrical descriptors already included but can, if people want be optionally made immediately as specific as that the exact shape and geometry of the sample and all possible ROIs on the sample are well described in a consistent and documented coordinate system

It would be better to disentangle the spectrometer from the instrument as yes it is a detector but usually is an own complicated piece of equipment with many details lenses and parts. It does certainly not harm to group this "set" of components under detector as one could then add (in addition to the already existent fields in NXdetector add also again an entire construction plan of the spectrometer if needed however from the perspective of an application definition most of these cannot be made required because if then one user has also a spectrometer but again one field is different it would need another application definition this makes clear that constraints on the nodes in the hierarchy of NeXus have to be disentangled from the definitions

in https://raw.githubusercontent.com/kit-data-manager/Metadata-Schemas-for-Materials-Science/main/TEM_schema.json a number of eels details are specified which can all be stored in an instance of NXimage_set_em_eels

spectrometer details though should be placed under detector as the spectrometer is nothing but an own detector + maybe additional pieces of information

add NXscanbox_em as this could then hold all relevant settings when the image was taken i.e. scan details

add an NXdeflector_em which can be passed as an additional component of the gun, https://www.jeol.com/words/emterms/20160713.103817.php currently the idea behind NXscanbox_em is rather https://www.globalsino.com/EM/page4225.html the electron deflection/scanning coil (the one with the brownish arrow on the figure)

precession is a particular operation mode of the NXscanbox_em for which one should place the angle, frequency and details in the NXscanbox_em

for Astar is this a particular hardware component talking to the scanbox ? in this case astar parameters should be added as fields of an instance of a base class https://nanomegas.com/precession-electron-diffractionand-applications/#

an NXgrating device would also be good to have https://raw.githubusercontent.com/kit-data-manager/Metadata-Schemas-for-Materials-Science/main/TEM_schema.json

value is often a set value in the control software whereby one can pick a specifically shaped so-and-so large aperture there are two approaches to this: either one stores the set_point_value like possible right now (which has value for somebody going back to the microscope but which is problematic because values are not comparable directly) maybe better store diameter or radius or some geometric measure of the aperture (problem here is that also this is not comparable for most people but thanks to having a fabrication one could store the aperture identifier and with this know exactly what one talks about,

Users should also note that each base class can also use an attached NXtransformations which would allow to locate the aperture as a technical component in the microscope and with this use an application definition to describe also an entire construction plan of the microscope

lifetime of the source in Ah

rename to electron_source and ion_gun rename to ion_source

then details about the source in a particular place should better be stored under electron_source (NXbeam) and at this position one has measured a current, a current density a beam energy etc

add an instance of NXmonochromator all properties under monochromator details could then be placed under (NXmonochromator)

https://raw.githubusercontent.com/kit-data-manager/Metadata-Schemas-for-Materials-Science/main/TEM_schema.json

Would profit from chamber state values like pressure coming from an NXsensor or plain field

e.g. omega_filter(NXmonochromator)

it might be intersting to store if the sample is conductive, magnetic, or beam sensitive the problem with these statements is they are all qualitative, how would one filter for this i.e. show me all those measurements with so and so beam sensitive material, when do I switch the boolean on or off, if this can be quantified like conductivity, coercivity, ... etc that might be better but we know that for practical EM operations oftentimes qualitative statements are sufficient

https://raw.githubusercontent.com/kit-data-manager/Metadata-Schemas-for-Materials-Science/main/TEM_schema.json what is final specimen? for plasma cleaning one should have an own appdef what to fill in storage conditions? ion sensitivity well like electron sensivity I see value of having such fields the probelm I have with this (all here my personal opinion) is that how do you know that sth is sensitive, common knowledge, results from other analyses? fact is assuming a sample to be sensititive is a model according to previously gained knowledge, if one would probe for this knowledge during the experiment one could have a measurement where these evidences are collected and then the statement about sensitivity inferred later

Plasma cleaning, this is clearly a processing step:

(NXplasma_cleaning): gas_composition(NX_NUMBER)(1): gas_species(NXion)(2): power(NX_NUMBER)(3): percent_power(NX_NUMBER)(4): duration(NX_TIME)(5):

constraints: shape(i) == (n,) forall i in [1, 2]

currently has no fields but should get some when there is a specific example

All NXspectrum_set_em will get a field intention(NX_CHAR) with values to pick form an enumeration of controlled intention e.g. xreay, eels, auger, cathodolum

but then there is the possibility to add method-post-processing specific base classes of what will be essentially NXprocesses to describe and document how the data were post-processed

All NXimage_set_em will get a field method(NX_CHAR) with values to pick form an enumeration of controlled intention e.g. se, bse, bf, df, adf, kikuchi, ecci, sad, nbed, ronchigram, chamber,

but then there is the possibility to add method-post-processing specific base classes of what will be essentially NXprocesses to describe and document how the data were post-processed

Will be moved to the individual NXimage_set_em and NXspectrum_set_em base classes

hint on iso with local time zone and again stating that for all settings they are assumed constant in between [start_time, end_time]

and RDMS

technology partners

an open

technology partners

remove

format metadata like

its processing, and the microscope session in general.

,

or research data management system (RDMS) introduce abbrev earlier.

details like

NX and NX

, users

documented covering enough.

given the advice to keep the original files. Make that sentence in bold. The more a schema like NXem establishes the more likely it could be that technology partners will be motivated to offer parsers that export to this format and in this case eventually it may no longer be needed to store the original files.

specific files

frequent case

common

the

of an

during the event

also an NXapm_pl would be possible, as soon as NXluminescence by Carola Emminger and Florian Dobner is ready whereby then there would be two subentries one for an NXapm and one for NXphotoluminesence to capture the photonic atom probe of Rouen/GPM

and finally if there were an NXafm for atomic force microscopy the IMEC AFM/APT experiments could be stored with an NXapm_afm application definition with NXapm and NXafm being respective subentries of the appdef but as NXapm_afm is a step-by-step approach one would have to release the constraint that only a single measurement can be performed.

NXasat should be a fuse of NXapm and NXem within an NXentry with NXsubentry, in this way we can combine the strength of both application definitions to describe also the upcoming technique of "atomic scale analytical tomography" https://doi.org/10.1017/9781316677292

TKD should be reflected also with an NXimage_set_em_tkd within NXem