LoadEventNexus only loads a 1:1 spectra map

[Martyn Gigg]

ISIS event files still have hardware grouping so that the spectra are not a 1:1 map of the detectors. The spectra as usual start from 1 and the only place the mapping is defined is in the legacy 'isis_vms_compat' block.

For now read this block to set up the correct spectra->detector mapping.

[Martyn Gigg]

(In [12114]) Update to LoadEventNexus and LoadNexusMonitors to read in the spectra table from the NeXus file if it exists. It is only defined for the isis_vms_compat block at the moment. Refs #3106 #3099

[Martyn Gigg]

(In [12165]) Fix LoadEventNexus for ISIS event files to remove the monitor spectra from the main detector block. Also added a method to return simply the number of monitors on an instrument rather than always dragging the vector of IDs across. Refs #3106.

[Janik Zikovsky]

(In [12177]) Refs #3116, Refs #3106: Reverted change to LoadEventNexus that breaks loading TOPAZ event nexus files.

[Janik Zikovsky]

(In [12178]) Refs #3116, #3106: Actual fix to LoadEventNexus this time.

[Martyn Gigg]

(In [12210]) Refs #3106. Created a new algorithm that replaces LoadLogsFromSNSNexus and can be used for any of the NXlog and IXseblock entries in a NeXus file. LoadEventNexus and LoadISISNexus2 now use these also.

[Martyn Gigg]

(In [12212]) Missed the proton charge NeXus files that don't define the field explicity. Re #3106

[Martyn Gigg]

(In [12217]) Swap to indexing the events by spectra for those files that have loaded a spectra mapping as well, currently just the ISIS ones. Those that use the default mapping remain unchanged until I can figure out all the consequences for changing everyone to index events by spectra. It basically requires the spectra number to match the event ID and not just start from zero. Refs #3106

[Janik Zikovsky]

Hi Martyn,

LoadRunLogs does not seem to load some of the log entries that LoadLogsFromSNSNexus; in particular, the phi, chi, omega logs of a TOPAZ event nexus are not loaded whereas they were previously.

[Martyn Gigg]

(In [12247]) Add a test to check the number of log entries. Re #3106

[Martyn Gigg]

(In [12249]) My poor naming skills have let me down again. Rename LoadRunLogs to LoadNexusLogs as it doesn't touch any other type of log. Re #3106

[Martyn Gigg]

(In [12250]) Fix a problem with loading NXpositioner logs and update the test to actually check for the number of loaded logs. Refs #3106

[Martyn Gigg]

(In [12253]) Fix for non 1:1 mappings from LoadEventNexus. It turns out NSP1 doesn't match SPEC.size. Re #3106

[Martyn Gigg]

(In [12256]) Correct a typo that leads to the spectramap equality operator always returning true. Re #3106

[Martyn Gigg]

(In [12264]) Fix a bug in NeXus log loading when an selog entry from a multi-period dataset doesn't have a time field but has a dimension > 1. Refs #3106

[Martyn Gigg]

(In [12293]) Fix an issue that causes a crash on Windows when loading trying to load a bad log from a NeXus file. This should fix the system test crash. Re #3106

[Martyn Gigg]

(In [12382]) LoadInstrument now has a new property called RewriteSpectraMap. If it is true (the default) then a new spectra map and axis are created on the input workspace and a 1:1 mapping of spectra->detector ID is set up. This should cure the issue that users of Python algorithms and CreateWorkspace don't get anything that is that useful. LoadEventNexus has also been updated to handle spectra rather than single pixel IDs for all files rather than just ISIS ones. A little tidy up is still required but the functionality is complete. Re #3106

[Martyn Gigg]

(In [12428]) A more robust spectra detector map iterator, i.e. actually works in Debug on Windows. There was a subtle heap corruption bug that only the Windows debug checked iterators picked up. Re #3106

[Martyn Gigg]

(In [12432]) Fix for one implementation broke the other one. This will do better. Re #3106

[Martyn Gigg]

(In [12433]) More subtleties that the windows compiler in debug is picking up. Hoping this is the source of the Mac test problem. Re #3106

[Janik Zikovsky]

Performance test for loading SNAP instrument

[Janik Zikovsky]

Hi Martyn,

According to performance tests, Rev [12382] introduced a slow-down in instrument loading (from 3.6 seconds to 5.4 seconds for SNAP, in this example). You can see it in the attached graph (the full report is hosted at ORNL so I don't think you can get to it?). Other instruments have slowed as well...

The performance test does not send out emails saying "so-and-so has slowed" because it occasionally is way slower due to multiple jobs running on the same machine (as you can see from the spikes in the graph). It is probably not such a big deal but I thought you should be aware of this.

Cheers,

Janik

[Steve Williams]

Checked some log and spectra map information from the LET1511, SANS2D5512 and CNCS7860 nexus files. The files loaded and the workspace data I checked matched and the HDF files. Each spectrum in the CNCS file was linked to a detector with the same number.

[Stuart Campbell]

This ticket has been transferred to github issue ​3953