Adjust the config file for your own instrument¶
This how-to assumes you already understand what the config file does and how its keys and values are structured — if not, read Learn > Reader architecture first. Here, we go through concrete changes you're likely to want to make, using config_file_witec.json as the starting point.
Provide your own metadata via an ELN file¶
The WITec parser only extracts the spectrum arrays and a handful of scalar fields (axis/intensity units, sample stage position, ...) from the raw .txt export; everything else — instrument, sample, user, experiment description — comes from a separate eln_data.yaml file that you write. Its structure should mirror the NeXus concept paths (lowercased, without the TYPE[...] bracket syntax); see the example ELN file that ships with the repository, or generate a fresh template with
which writes raman.eln_data.yaml in the current directory (see the pynxtools CLI reference for the other options).
Stop writing a field entirely¶
Remove its key from the config file. If the corresponding key is still in your eln_data.yaml, that's fine; it's simply not picked up. If the config file doesn't reference a piece of data at all, it never ends up in the output, no matter what's in the ELN file.
A field is missing from the output and you don't know why¶
Check that the key is still spelled correctly in eln_data.yaml — the reader looks it up by exact path. If the key is missing there entirely, the conversion still succeeds, but you'll see a warning like:
Give a field a fixed, hardcoded value¶
Skip the @eln/@attrs/@data prefix and just write the literal value:
This is useful for values you know are constant across all your measurements (a fixed excitation wavelength, a lab name, ...) so you don't have to repeat them in every eln_data.yaml.
Name a variadic group and declare its NeXus class¶
Some NXraman concepts are variadic: the application definition gives them a base class but no fixed name, so a file can contain any number of instances, each named with the NAME[instance_name] syntax on that segment — NAME is the uppercase base-class placeholder from the NXDL, instance_name is whatever you want to call this particular one. The shipped config files already do this throughout, for example for the laser source:
If your setup has a second laser, add another key with a different instance name, e.g. SOURCE[source_808nmlaser]/type.
This bracket syntax only works for concepts that are actually variadic in the NXDL. Fixed-name concepts — like beam_incident, which NXraman/NXoptical_spectroscopy already names explicitly — take no brackets; write the path with the lowercase name only, the way it already appears throughout the config file (.../beam_incident/wavelength, not .../BEAM[beam_incident]/wavelength). See the pynxtools naming rules for the full logic behind concept names, instance names, and when brackets apply.
Set or override a unit¶
Units are separate keys with the /@units suffix. Either point them at the ELN file, same as the value:
"/ENTRY[entry]/INSTRUMENT[instrument]/beam_incident/wavelength/@units": "@eln:/ENTRY[entry]/instrument/beam_incident/wavelength/@units"
or hardcode them, if the unit never changes for your setup:
Rename the entry¶
By default, entries are named entry (from ENTRY[entry] throughout the config file). To use a different name, e.g. measurement1, replace every occurrence of ENTRY[entry] with ENTRY[measurement1]. If you have many keys, it's easier to structure the config file as nested dictionaries instead of flat paths — see the pynxtools multi-format reader guide for that syntax.
Add a fallback chain for a field that comes from different sources depending on the record¶
Some ROD records have a mineral name, others only a systematic chemical name; some have _cod_original_formula_sum, others only _chemical_formula_structural. Rather than picking one source and losing the other, config_file_rod.json uses a JSON-encoded list of candidates, tried in order until one resolves:
"/ENTRY[entry]/SAMPLE[sample]/name": "['@attrs:_chemical_name_mineral','@attrs:_chemical_name_systematic']"
The same pattern works for @eln/@data sources too. This is the mechanism to reach for whenever "the right field to use" depends on what a specific input file actually contains.
Point a parser at a different config file¶
RodParser and WitecParser each hardcode their own default config file (see Learn > The WITec and ROD parsers). If you're experimenting with a modified config file, pass it explicitly on the command line using the -c flag. It takes precedence over the default: