Avoid having many singletons for SANS reduction

[Gesner Passos]

I really do not like the fact that we have 'many' singletons for performing the sans reduction. For example, to reduce both banks it will do the following:

• Reduce rear sample,
• create a new singleton
• reducer rear can,
• finalize reduction rear
• create new singleton
• reduce front sample
• create new singleton
• reduce front can
• finalize reduction front.

I suggest removing this thing, to have a single singleton for the whole life of the SANS reduction.

[Gesner Passos]

re #8443: SANS reduce CAN does not create new singleton

Changeset: 52975a3c701d64c5be88802a206f7df9e313cabb

[Gesner Passos]

re #8443: Correct dealing with transmission names

Changeset: 4c93a275685e90d3bbf6fb10bf86bf1ad7aa79c2

[Gesner Passos]

re #8443, re #8461: Update SystemTests for the fix of search centre

Changeset: 48356ca3deafb3d3a599f4425d5c6c7f52bf2a10

real link: ​https://github.com/mantidproject/systemtests/commit/48356ca3deafb3d3a599f4425d5c6c7f52bf2a10

[Gesner Passos]

As a side effect of removing the creation of singletons we found a bug inside the search centre procedure #8461. For this reason the system test was forced to be updated ( comment:12 ).

[Gesner Passos]

What is proposed here avoid the creation of the new singleton internally when reducing the can data. So, internally, the isis_reducer does not 'recreate' itself. But, others (ISISCommandInterface and centre_finder) still uses the creation of new singletons to process their functions.

For time constrains, it will not be dealt with here. It will be let to another ticket #8470. So, I can focus on #8444 earlier.

[Gesner Passos]

Tester:

• Code review: If you are able to spot anything that could be dangerous, in avoiding the creation of the singleton, please present it to me.
• Systemtests must be in sane condition.
• Follow the steps provided ​here to perform a normal reduction and check that everything is going ok using the GUI interface.
• Move to the Geometry Tab and run the search centre.
• Check the history of Up. Make sure that the problem reported in #8461 is sorted, i.e., you must find the following history:

  RebinToWorkspace(WorkspaceToRebin='22041_trans_can_1.5_12.5',WorkspaceToMatch='centre',OutputWorkspace='CalculateNorm_loaded_temp') 
  
  Multiply(LHSWorkspace='CalculateNorm_loaded_temp',RHSWorkspace='Q_WAVE_conversion_temp',OutputWorkspace='Q_WAVE_conversion_temp') 
  
  Q1D(DetBankWorkspace='Up_can',OutputWorkspace='Up_can',OutputBinning='0.001,0.001,0.0126,-0.08,0.2',WavelengthAdj='Q_WAVE_conversion_temp',AccountForGravity='1')
  

[Peter Parker]

Merge remote-tracking branch 'origin/feature/8443_many_singletons'

Full changeset: ​a8ad0a4560af4cbf3315cb90fda31849475b713b

[Peter Parker]

Merge remote-tracking branch 'origin/bugfix/8443_many_singletons'

Full changeset: ​4fa79cc43e0bafc23d35bc0975fc9473aa41659c

[Gesner Passos]

Merge branch 'feature/8443_many_singletons' into feature/8455_correct_sample_geom_cor

Full changeset: ​d6e9fa02184bc547c79d320e5108488da601bc31

[Stuart Campbell]

This ticket has been transferred to github issue ​9287