Load seperate period good frame values from the Beamlog logs

[Nick Draper]

There is more detailed beamlog information in the nexus files that stores the beamlog data for good frames by period so we can split them out by the period they were recorded in. Otherwise at present the goodfrm log is wron as is it a single value which is the sm of all of the periods.

Look into how common this log structure is? Common across muon insts? or all ISIS insts.

Good file as an example:
isis\inst$\NDXHIFI\Instrument\data\cycle_12_5\HIFI00050132.nxs

Then we need to consider how to make use of this.

From James Lord:

With ISIS Muon data (and probably neutrons), in the Nexus file header each Period has its own number of Good Frames collected during a run. When a multi-period run is loaded into Mantid it appears as a Workspace Group, in which each Workspace has "goodfrm" set to the total good frames in the whole run. It would be better to put that individual period's good frames instead, so that dead time and other corrections automatically work as they do for non-period data.

For much of our data we have 2 periods with equal numbers of frames each so "goodfrm" is wrong by a factor 2, but we can't rely on a fixed factor as it is easy enough (and often scientifically useful) to set up different numbers of frames per period, and perhaps more than 2 periods. With externally controlled period switching it may not be possible to predict the ratio in advance.

[Nick Draper]

More from James

Now I look through older data, perhaps run 23391 (for example) may be better. This is real muon data from an RF experiment.
That's at \\isis\inst$\NDXHIFI\Instrument\data\cycle_11_2\HIFI00023391.nxs and has 17321 frames in each of 2 periods. Unfortunately the good frames are equal (as intended) so maybe not too good for thorough testing?

Or do you have any muon period data files already in the example data collection used for the Mantid automated tests?

We do have some nxs_v2 files but not for 50132, and that for 23391 fails to load in Mantid. Another example with real data might be 47745, from cycle 12_5, that run's .nxs_v2 also fails to load in Mantid while the plain .nxs is OK.

[Anders Markvardsen]

Procedure to fix

1. read in number of good frames for each period and store in individual matrix workspaces

In addition in bottom of the Home tab in the Information part write text like:

Data collected at 'n' periods and the number of good frames for each period

[Nick Draper]

Talk to Owen about this he may have some code you can use, he had to do something very similar for the neutron nexus files recently.

[Nick Draper]

Moved to the Backlog after R2.6

[Arturs Bekasovs]

Difficult to read like that.

[Arturs Bekasovs]

Difficult to read like that.

[Arturs Bekasovs]

First of all, need to investigate why Muon Nexus v2 files fail to load in Mantid for those runs outlined by James Lord:

HIFI00023391.nxs_v2, HIFI00047745.nxs_v2

Ticket for that: #8335

[Arturs Bekasovs]

Wouldn't want to start before structure of the Muon Nexus file is sorted out.

[Nick Draper]

Bulk move to assigned at the introduction of the triage step

[Stuart Campbell]

This ticket has been transferred to github issue ​7820