Muon interface dies when 'old' emu data

[Anders Markvardsen]

Load attached emu data into muon interface and mantidplot dies. Note this appear to be muon interface specific since the data load OK using Load button on Mantidplot.

Steve writes:

I’m trying to load a datafile where the source was an old muon MCS binary files with the NeXus version being generated by CONVERT_NEXUS. Unfortunately it fails. I’m hoping you can give me an idea why this is failing and the easiest way we can fix this,

[Nick Draper]

Bulk move of tickets out of triage (new) to assigned at the introduction of the triage state

[Arturs Bekasovs]

It is not dying for me. Should probably try it out on Windows.

But there definitely are problems:

1. FirstGoodData read by LoadMuonNexus is enormously big. This is because in the data provided, the resolution is stored as NX_FLOAT32, but in newer files - as NX_INT32. And we are always reading it as an int.
2. LoadMuonLog fails for the file, so we haven't got any of the time series logs in the loaded workspace.

[Arturs Bekasovs]

Refs #8863. Add support for resolution stored as float.

Changeset: 338d68224753341a798da6d7eccf1e4658c622ef

[Arturs Bekasovs]

Refs #8863. Better error reporting.

Changeset: a23178cf23bb221177c34d47d91a4dc0936c33b6

[Arturs Bekasovs]

Refs #8863. Output warning if values/times not found.

The log is the just skipped instead of LoadMuonLog failing. It means that if the files contains a few malformed logs, we can still load the other ones.

Changeset: 7255cc3cb75df99093c93ddf6249af4fc16fa6ec

[Arturs Bekasovs]

Refs #8863. New system test for the file.

Changeset: ​b20e1f625aafb366732c32a70fdd863f7fc5d70f

[Arturs Bekasovs]

Tester:

First of all, verify that the system test for the file was added (see comment:6) and is passing all the develop test builds ​here.

Then merge/build the test and launch MantidPlot -> MuonAnalysis interface. Load the attached file. Warnings should be printed about NXlog entries not having values/times set. You can examine the structure of the file and verify that it is indeed the case. Check that the FirstGoodData value loaded from the file looks OK (isn't insanely big as it was before).

Now go thought basic analysis steps and make sure everything works OK: adjust settings, adjust grouping, plot different groups/pairs, fit and create the results table.

Load a different (newer) Muon file, e.g. MUSR00015189 from AutoTestData. No warnings should be reported and FirstGoodData loaded from it should be the same as it was before the changes.

Additionally, using LoadMuonNexus, load MUSR00015189 and examine the log values. They should be loaded correctly (compare it to the ones if loaded before the changes).

When passed, please merge the systemtests branch as well.

[Anders Markvardsen]

Merge remote-tracking branch 'origin/bugfix/8863_old_emu_wrong_first_good_data'

Full changeset: ​053d182ad88a7062186f47897dd596dcd8fa17b3

[Anders Markvardsen]

Merge remote-tracking branch 'origin/bugfix/8863_old_emu_wrong_first_good_data'

Full changeset: ​3dbee4bb9d549ae04e08767cc0fb6b84e57c5732

[Stuart Campbell]

This ticket has been transferred to github issue ​9707