Move the Muon workflow out of the MuonAnalysis interface code

[Arturs Bekasovs]

Muon Interface has quite a long sequence of things it does to the loaded workspace before it actually gets plotted on the screen. Currently, all these steps are buried in the depths of the interface code. This is bad.

Firstly, because it makes them difficult to test. Currently, only the individual algorithms are tested, but not how they are working together.

Secondly, this makes it impossible to use the workflow outside the interface, which is currently required for #6473.

To solve similar kinds of problems, a notion of Workflow algorithm was introduced. Those are not doing much work themselves, but are instead setting parameters for child algorithms. This seems like a right thing to use inside Muon Analysis.

So, the initial plan is:

1. Find out how many and what kind of algorithms are needed.
2. Write rigorous tests for them.
3. Implement algorithms so that tests are passing.
4. Refactor MuonAnalysis interface code to use these algorithms instead.

[Arturs Bekasovs]

(In #6473) I am unable to load workspace for fitting properly before the workflow of the MuonAnalysis is moved outside the interface.

[Arturs Bekasovs]

Deleted

[Arturs Bekasovs]

I will use a following approach to testing - it will be assumed, that the current results produced by MuonAnalysis interface are correct and I will test against them. This will make sure I've not broken anything that works already.

[Arturs Bekasovs]

It was decided to implement these algorithms in separate tickets. I will add them as blockers of this one as I will go along and create them. When all of them are done, tester of this ticket should just verify that the overall job was done.

[Arturs Bekasovs]

The workflow was re-thought a bit. Now it utilizes more already-available algorithms. New list of things to implement:

1. Update LoadMuonNexus - it should return DeadTimes as a TableWorkspace, so we can directly use it for ApplyDeadTimeCorr.
2. Replace ApplyGroupingFromMuonNexus with MuonLoadGrouping and MuonGroupDetectors.
3. Update Rebin algorithm to include new option "FullBinsOnly".
4. Create workflow algorithm MuonCreateWorkspace.
5. Create top-level workflow algorithm MuonLoad.

While doing all that, again, appropriate part of the MuonAnalysis should be refactored to move out the calculations.

[Arturs Bekasovs]

(In #6473) This was mostly done. Option for Rebin is a tiny little thing which stops me from closing that ticket, so I've implemented it in both places and will re-factor that during maintenance.

[Arturs Bekasovs]

Done to an extent which allowed to complete sequential fitting. Closing and checking properly can be left for maintenance.

[Arturs Bekasovs]

Workflow of MuonAnalysis and MuonLoad

[Arturs Bekasovs]

Tester:

I wasn't able to move out too much, because the interface uses a lot of intermediate values to allow quick experimenting with loaded data. That's why I couldn't use e.g. MuonLoad to do everything for me and need to replicate the workflow in the interface.

Though one of the biggest aims was achieved - the workflow was analysed, formalised using the diagram attached and expressed as the new MuonLoad algorithm.

So the testing here comes to fetching the latest master and reading through the MuonAnalysis.cpp. Verify that there are no calculations done in the interface code and all it does is passing appropriate workspaces and parameters to algorithms, according to the attached diagram. Try to find places which could potentially be re-factored out.

[Gesner Passos]

There are no calculations done directly through MuonAnalysis.cpp. It seems that some lines of code could be potentially saved not only in yours but generally if createChildAlgorithm or something likely could be made static.

The real problem is the:

That's why I couldn't use e.g. MuonLoad to do everything for me and need to replicate the workflow in the interface.

New requests or maintenance will require checking both places always. In some places, people defined a HelperClass that was uses to share between both classes, hence, allowing the replication. I'm not quite sure how we could apply here, but I think it is worth discussing with Martyn to see if he could suggest a nice approach.

[Stuart Campbell]

This ticket has been transferred to github issue ​9338