Speed up asymmetry calculation

[raquelalvarezbanos]

This issue was originally TRAC 11319

This ticket is blocked by :

• TRAC9215

PlotAsymmetryByLogValue loads a set of muon runs and computes the asymmetry as a function of some log value. Currently, the data loading and the asymmetry calculation are performed within the same loop. These tasks should be carried out separately so that users can play with asymmetry parameters (for instance integration limits) without having to load all the datasets every time.

[raquelalvarezbanos]

@raquelalvarezbanos (2015-03-17T12:59:59):
The main loop currently reads:

  for (size_t i = is; i <= ie; i++) {

    // Load run, apply dead time corrections and detector grouping
    Workspace_sptr loadedWs = doLoad(i);

    // Analyse loadedWs
    doAnalysis (loadedWs, i-is);

    progress.report();
  }

We could add an if statment to check whether the loadedWs were already loaded or not. It seems that the best option is to add the temporary workspaces to the ADS, and end up with something like this:

  for (size_t i = is; i <= ie; i++) {

    if ( loadedWs is not in ADS ) {

      Workspace_sptr loadedWs = doLoad(i);
      Add_loadedWs_to_ADS;

    } else {

      loadedWs = ADS.retrieve( loadedWs_name );
    }

    // Analyse loadedWs
    doAnalysis (loadedWs, i-is);

    progress.report();
  }

Two boolean flags should be added to:

• Hide/show the temporary workspaces
• Keep/remove loaded workspaces

  ---

@raquelalvarezbanos (2015-04-23T15:03:15):
(In http://trac.mantidproject.org/mantid/ticket/6931) I have attached a script I have been using to test the changes, which the tester may find useful. It includes descriptions (comments) of what I would expect in each successive execution of the algorithm.

[raquelalvarezbanos]

Not sure if this is still an issue. PABLV used to be too slow because every time it was run it would load and analyze the whole set of runs. But this problem was partially solved in #13157. Since that fix, when all the input properties stay the same between consecutive executions, only new runs are loaded and analyzed. The only potential issue remaining is that the algorithm will need to load & analyze everything when one of the inputs changes. In this case it would be useful to perform the analysis in parallel (this is what this issue is about). However, no one has complained about performance since #13157, so I'm marking this as Low Priority.