[Bug]: No materials card instantiated despite atom_types present for several techniques in oasis-b

[mkuehbach]

Contact Details

@mkuehbach

What happened?

Tested 2025-11-25 on oasis-b with the XPS and the APM examples, which both have an NXsample instance with a concept atom_types instantiated:

• No materials cards generated in both cases
• atom_types ends up correctly in NeXus file and in NOMAD Metainfo in both cases
• Is the case handled that an entry has multiple NXentry groups with individually different atom_types?
• Is the previous observation related to an observation Anton Gladyshev made in the Koch group OASIS?
• For NXapm two semantic types of NXsample are distinguished "sample" and "specimen". Incorrectly, nomad parser interprets the existence of both such that it instantiates a composite system base section. This is just wrong, accepted atom probe terminology is that the "sample" is the larger chunk of material from which the "specimen" gets prepared; the "sample" itself is never measured with atom probe, see the resulting composite system

- In the process of bughunting, also NXchemical_composition instances from which composition could be instantiated but are currently not evaluated to populate atom_types and thus a material card.

We should possibly split these issues apart.

[lukaspie]

Tested 2025-11-25 on oasis-b with the XPS and the APM examples, which both have an NXsample instance with a concept atom_types instantiated:
No materials cards generated in both cases
atom_types ends up correctly in NeXus file and in NOMAD Metainfo in both cases

As discussed, oasis-b currently uses pynxtools==0.12.0, so the atom_types bug is expected and be solved by #723. Works locally with nomad@develop and pynxtools@master. Here's the material card for the APM example on localhost:

Is the case handled that an entry has multiple NXentry groups with individually different atom_types?
Is the previous observation related to an observation Anton Gladyshev made in the Koch group OASIS?

This normalizer runs on NXentry instances individually, so no, we don't have any rule for atom_types within multiple NXentry. I think we should not touch this for now, simply for the reason that we anyway plan to refactor such that one NXentry <-> one NOMAD entry, so then this isn't an issue anymore.

For NXapm two semantic types of NXsample are distinguished "sample" and "specimen". Incorrectly, nomad parser interprets the existence of both such that it instantiates a composite system base section. This is just wrong, accepted atom probe terminology is that the "sample" is the larger chunk of material from which the "specimen" gets prepared; the "sample" itself is never measured with atom probe, see the resulting composite system

We would need to hardcode this behavior into the normalizer. If I understand correctly, you wouldn't expect the materials card to be filled from "sample", correct?