LoadEventNexus v1¶

See Also¶

LoadISISNexus, LoadEventAndCompress

Child algorithms used¶

Sample logs, such as motor positions or e.g. temperature vs time, are also loaded using LoadNexusLogs.

Monitors are loaded using LoadNexusMonitors.

Instrument geometry

There are a series of approaches for extracting the instrument geometry. These follow the escalation path as follows:

• Tries to load embedded instrument_xml from the NXinstrument if present using LoadIDFFromNexus.
• Else tries to load embedded nexus geometry from the NXinstrument if present
• Else tries to load the instrument using the name extracted from NXinstrument

The latter two possibilities are achieved via LoadInstrument

Optional properties¶

If desired, you can filter out the events at the time of loading, by specifying minimum and maximum time-of-flight values. This can speed up loading and reduce memory requirements if you are only interested in a narrow range of the times-of-flight of your data.

You can specify to load only certain spectra within the file, using the SpectraMax, SpectraMin and SpectraList properties. This will load data only matching those restrictions. At facilities that do not group detectors in hardware such as the SNS, then this will also equate to the detector IDs.

You may also filter out events by providing the start and stop times, in seconds, relative to the first pulse (the start of the run).

If you wish to load only a single bank, you may enter its name and no events from other banks will be loaded.

The Precount option will count the number of events in each pixel before allocating the memory for each event list. Without this option, because of the way vectors grow and are re-allocated, it is possible for up to 2x too much memory to be allocated for a given event list, meaning that your EventWorkspace may occupy nearly twice as much memory as needed. The pre-counting step takes some time but that is normally compensated by the speed-up in avoid re-allocating, so the net result is smaller memory footprint and approximately the same loading time.

Veto Pulses¶

Veto pulses can be filtered out in a separate step using FilterByLogValue v1:

FilterByLogValue(InputWorkspace="ws", OutputWorkspace="ws", LogName="veto_pulse_time", PulseFilter="1")

Data Loaded from Nexus File¶

The nexus file must have /raw_data_1 or /entry as its main group and that group be of type NXentry. It also needs a group of type NXevent_data.

The data is read from each group of type NXevent_data.

If the file has an isis_vms_compat then it is taken to be an ISIS file and the data will be modified according to the information obtained from this group.

Here are some tables that show it in more detail:

Invalid Period Logs Error¶

There is an issue specific to ISIS, particularly on long runs, where noise on data collection instruments can change the period of the data. This can cause the period associated with certain data points to exceed the total number of periods we expect.

LoadEventNeXus compares the total number of periods we expect, which can be found in the periods/number attribute of the run, and the greatest period number found in framelog/period_log/value attribute of the data. If they do not match, an error message is raised which explains this problem, and loading of the data will be unsuccessful.

In this case, the data is fundamentally corrupted, so Mantid does not know how to correct this automatically. If you only expect 1 period, there is a script in the script repository, user/TomTitcombe/correct_period_logs.py, which will change all the periods in framelog/period_log/value to 1.

If you expect more than 1 periods, there is currently no solution script available through Mantid. You should contact the Mantid team to discuss the problem and possible solutions.