Apm app #328
Draft
Apm app #328
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
… probe app, we have edited these here, despite there is currently an active NIAC-feature branch fairmat-2024-apm that is in the process of negotiation with NIAC. To move forward we still work with the old fairmat branch, knowing that the example will need refactoring and reprocessing ones NXapm has been accepted as an official appdef in NeXus by the NIAC, likely end of Q1 2025
…nyaml addressing proper handling of copyright dates as discussed in e.g. nexusformat#1303 on the niac side
… be used only in atom probe and thus may not warrant to become proposed towards NIAC
… likely be used only in atom probe and thus may not warrant to become proposed towards NIAC
…ed strong enough and thus may not warrant to become proposed towards NIAC
…strong enough but used in the end only by NXapm thus we thought it is better to move it into the appdef directly, also because NXapm can cover now use cases of measurements and is envisioned to cover also simulations of APT and FIM so no more need to warrant another appdef that would then use NXapm_hit_finding, cameca could inherit from NXapm as base class inheritance has already been accepted by the NIAC as a result of the Autumn NIAC 2024 hackathon
…nly a container to store instances of NXevent_data_em, reorganized via defining these concepts directly in NXapm_msr
…definition below instrument that was required with the previous design. The key idea always was to have one group where static props of the instrument are stored and another group (event_data) where dynamic values are stored, so far the implementation for this recreated all concepts of the instrument on the one hand in NXapm_msr and on the other hand in NXevent_data_apm. However, now with base class inheritance supported and accepted by the NIAC, it would be much better to refactor NXapm_msr towards a base class called NXinstrument_apm that offers a dictionary for the concepts for static and typically quantities with more dynamic i.e. frequently changing values. Thereby measurement and NXevent_data_apm can just inherit NXinstrument_apm and thus the description of the NXevent_data_apm base class becomes much slimmer, less prone to making manual errors like copy-paste, the appdef will then just constrain for which concepts inherited from either NXinstrument_apm will be required, then possibly one may even remove NXevent_data_apm altogether via eventID(NXobject) with a child NXinstrument_apm
…msr refactored into NXinstrument_apm, next and last step, check that relevant groups of NXinstrument_apm are defined and constrained properly in the NXapm appdef to complete the BREAKING REFACTORING
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.