Cannot load ISAWPeaks text file

[Owen Arnold]

Saving ISaw Peaks is taking 300 seconds for a 375 peak workspace!

When the ISaw peak file does finally save, loading it results in multiple log entries of the form

Error reading peak SEQN -1: Empty peak line encountered

Progress stalls at 100%.

As the IsawPeak workspaces are the only way we have of persisting peak workspaces at the moment. This is a very serious issue.

[Anders Markvardsen]

Used to able to load e.g. mantid\Test\AutoTestData\TOPAZ_1204.peaks using the LoadIsawPeaks algorithm.

However, something has caused this to no longer work.

Add a unit test class for LoadIsawPeaks, for now just containing one test which loads an isaw peak file without crashing.

[Karl Palmen]

This does not happen with the TOPAZ_1204.peaks, but does happen to a peaks file generated from a NEXUS file that Owen supplied me after following the instructions in the accompanying python file. The NEXUS file was almost one Gigabyte in size.

The Error reading peak SQN -1: Empty peak line encountered occurred on loading the peaks file created. The file looked OK when read with Notepad.

[Karl Palmen]

A more careful look at the peak file that does not load done in comparison with the Topaz file does suggest there is something wrong with the file. Each line except the first line begins with a one digit number apparently corrosponding to the line type.

Some lines in the file that won't load instead begin with a large number and seem to be missing a linetype number, which I think ought to be a 1. Also there are no lines beginning with a 5 after the line beginning with a 4 suggesting missing data.

[Karl Palmen]

I put the missing 1s back into the file, one then got errors of the form:

Error reading peak SEQNn: Bank named bankd not found!

and bank d refers to a row of the missing data (columns both have header DETNUM in both tables).

[Karl Palmen]

A look at the code for saving the peaks shows that the missing 1 occurs because there is no space printed between it and a 5-digit run number. Also the debugger shows that the missing data has arisen from a failure to find the instrument for the row of data.

[Karl Palmen]

I've been able to reproduce the problem by cropping the workspace supplied by Owen to 100 histograms from 30,001 histograms.

[Karl Palmen]

I've found that if I load the workspace look at the instrument, select the instrument tree tab, I find what SaveIsawPeaks searches through to get its detector module info (for line type 5). It expects to find dectector modules such as Bank143. But intead I see examples such as tube143, which is a group of pixels.

[Karl Palmen]

I've found that the code for SaveIsawPeaks finds tube143 and assumes it is called bank143 etc. .

[Karl Palmen]

I made a simple fix to enable SaveIsawPeak to recognise a detector module of type tubeN as well as bankN. This did not work and using the debugger, I found it did find the tube143 detector module and returned its information, but this was rejected by a boost::dynamic_pointer_cast<const RectangularDetector> which cast it as null pointer.

The instrument producing this problem is a WISH instrument. Perhaps, more work needs to be done by someone knowledgeable in WISH to support WISH in IsawPeaks.

[Owen Arnold]

WISH does not have rectangular detectors. This is another example we have in Mantid of instrument/facility specific code. Can we do something else if this dynamic cast fails?

[Karl Palmen]

I've already put in code that issues a warning message: "Information about detector MODULE " << bankName << " not found and recognised\n";

Also I've found out the WISH tubeN uses a different formatting convention to TOPAZ bankN, which would result in tube001 to tube099 failing even if the dynamic cast were successful.

[Karl Palmen]

Dealing with SaveIsawPeaks for WISH instrument re #4104

Made SaveIsawPeaks quit with an error if a detector module (other than "None") is found that is not of form bankN. In the case of WISH, the detector modules are of form tubeNNN and are not rectangular detectors.

The issue of saving peaks unsuitable for IsawPeaks will be dealt with in another ticket (also critical).

Signed-off-by: Karl Palmen <karl.palmen@…>

Changeset: b5be73293369bfd7bc513168168afc40ffbc679c

[Karl Palmen]

A suggested test is to follow the steps decribed in ticket #4105 verifying that SaveIsawPeaks fails quicky with an error message concerning a detector module.

[Karl Palmen]

Allow for an unlabeled detector module as in unit test for re #4104

Signed-off-by: Karl Palmen <karl.palmen@…>

Changeset: 992d3a8681e49ca688ccf91a33bded8b28311f87

[Karl Palmen]

The ISAW files will only work with instruments with rectangular detectors. For other instruments such as WISH, the peaks can be saved into a NexXus file (see ticket #4137).

[Michael Reuter]

I understand the issue and it's good to know non-rectangular detectors have a file format.

[Stuart Campbell]

This ticket has been transferred to github issue ​4951