Load algorithms should have consistent parameters

[Nick Draper]

Check that load algorithms have consistent parameters as much as possible.

[Nick Draper]

"New" tickets moved at the code freeze of iteration 29

[Nick Draper]

First task is to check out all the load algorithms and created tickets for those that do not conform.

[Nick Draper]

Bulk move of tickets to iteration 31 at the iteration 30 code freeze

[Nick Draper]

Moved to iteration 33 at iteration 32 code freeze

[Karl Palmen]

Many Load algorithms load from one file into one workspace. Most of these load algorithms have the first parameter called "Filename", which refers to the input file and the second parameter called "OutputWorkspace", which refers to the output workspace. The exceptions are as follows:

LoadDSpacemap:
4th parameter - Filename 
6th parameter - OutputWorkspace

LoadDetectorGroupingFile:
LoadMask:
LoadMaskingFile:
3rd parameter - InputFile
2nd parameter - OutputWorkspace

LoadMD:
1st parameter - Filename 
6th parameter - OutputWorkspace

LoadPreNexusMonitors:
1st parameter - RunInfoFileName (not Filename)
2nd parameter - OutputWorkspace

There are other types of load algorithms, which I'll mention later on.

[Karl Palmen]

There are several load algorithms that load data from a file into a workspace that is already existing. Most have the first parameter called "Workspace" which is this already existing workspace and the second parameter "Filename". Exceptions are

LoadDetectorInfo:
1st parameter - Workspace
2nd parameter - DataFilename

LoadIsawDetcal:
LoadIsawUB:
1st parameter - InputWorkspace (should be Input/Output)
2nd parameter - Filename

LoadLOQDistancesFromRaw:
LoadSampleDetailsFromRaw:
1st parameter - InputWorkspace (should be Input/Output)
2nd parameter - Input - The input file

LoadMappingTable:
LoadMuonLog:
parameters in wrong order

LoadNexusLog:
1st paramater 'workspace' is documented as 'Output'. 
If this is correct, the algorithm belongs to 
the previous category and is an exception in it.

[Karl Palmen]

I got the exceptions shown above from the wiki. A brief look at the code suggests that there are in reality fewer exceptions.

[Karl Palmen]

The comments I have made are just early observations.

[Karl Palmen]

I've corrected some Wiki load algorithm pages that do not agree with code.

[Karl Palmen]

Here I list the Load algorithms followed by the type (O/IO/I) of workspace followed by xf for exceptional naming of file parameter, xw exceptional naming of workspace parameter, and xo for exceptional ordering.

Load                      O
LoadAscii                 O
LoadCalFile               I  xf xw xo complicated
LoadCanSAS1D              O
LoadDAE                   O  xf DAE host instead of file
LoadDaveGrp               O
LoadDetectorInfo          IO xf ‘DataFilename’ 
LoadDetectorsGoupingFile  O  xf ‘InputFile’ 
LoadDspacemap             O&I xo Both an input and output workspace are required
LoadEmptyInstrument       O
LoadEventNexus            O
LoadEventPreNexus         O  xf xo multiple input files
LoadGSS                   O
LoadInstrument            IO xf input file can be overridden 
LoadInstrumentFromNexus   IO
LoadInstrumentFromRaw     IO
LoadIsawDetCal            I  two input files second ‘Filename2’
LoadIsawPeaks             O
LoadIsawUB                IO xw ‘InputWorkspace’
LoadLiveData              O  xf xo many parameters instead of file
LoadLog                   IO
LoadLOQDistancesFromRaw   I
LoadMappingTable          IO xo 
LoadMask                  O  xf xo ‘InputFile’ 
LoadMaskingFile           O  xf xo ‘InputFile’
LoadMD                    O  xo
LoadMuonLog               IO xo 
LoadMuonNexus             O
LoadNexusLogs             IO 
LoadNexusMonitors         O
LoadNexusProcessed        O
LoadNXSPE                 O
LoadParameterFile         IO
LoadPreNexusMonitors      O  xf ‘RunInfoFilename’ 
LoadRaw                   O
LoadRKH                   O
LoadSampleDetailsFromRaw  I  
LoadSNSNexus              O
LoadSPE                   O
LoadSpice2D               O
LoadSQW                   O
LoadTOFRawNexus           O

Of these the following could have either the workspace or filename parameter name changed and possibly a parameter order changed

LoadDetectorsGoupingFile  O  xf ‘InputFile’
LoadInstrument            IO xf input file can be overridden
LoadIsawUB                IO xw ‘InputWorkspace’
LoadMask                  O  xf xo ‘InputFile’ 
LoadMaskingFile           O  xf xo ‘InputFile’
LoadPreNexusMonitors      O  xf ‘RunInfoFilename’ 

Of these the following could have a parameter order change.

LoadMappingTable          IO xo 
LoadMuonLog               IO xo 

Also further consistency could be obtained by reducing the number of types O, IO, I and O&I.

[Karl Palmen]

The following implement the API::IDataFileChecker interface, which is required by all Load algorithms used by Load.

LoadAscii                 O
LoadCanSAS1D              O
LoadDaveGrp               O
LoadEventNexus            O
LoadEventPreNexus         O  xf xo multiple input files
LoadGSS                   O
LoadMuonNexus             O
LoadNexusProcessed        O
LoadNXSPE                 O
(LoadRaw )                O  not LoadRaw itself but LoadRawHelper
LoadRKH                   O
( LoadSNSNexus )          O  inherits from LoadTOFRawNexus
LoadSpice2D               O
LoadSQW                   O
LoadTOFRawNexus           O

[Nick Draper]

Moved at end of release 2.1

[Nick Draper]

Moved at the end of release 2.2

[Karl Palmen]

I've found the following additional algorithms that implement API::IDataFileChecker

LoadILL                O not in wiki
LoadISISNexus2         O not in wiki
LoadPreNexus           O xf xo
LoadQKK                O not in wiki
LoadSNSSpec            O
LoadSPE                O

[Karl Palmen]

Perhaps Nick Draper could comment on this.

[Nick Draper]

moved to Release 2.4

[Karl Palmen]

A conversation with Nick Draper has revealed that every algorithm (not just a load algorithm) with one input workspace, should have it named InputWorkspace and with one workspace of type InOut or Output should have it named OutputWorkspace.

[Karl Palmen]

A more precise description of what is required is needed to determine what needs doing for this ticket.

[Karl Palmen]

I'll cease work on this ticket until I get further clarification.

[Karl Palmen]

One way of encouraging a consisent naming is to have some declare property functions that automatically name the property e.g.

declareInOutWorkpaceProperty("The name of the the workspace to load into");
which does
declareProperty(
  new WorkspaceProperty<MatrixWorkspace>("Workspace","Anonymous",Direction::InOut),
  "The name of the workspace to load into" );

Which of such property functions we decide to have, would clarify this ticket, which could then be implemented with or without these property functions.

[Nick Draper]

Moved to r2.6 at the end of r2.5

[Nick Draper]

Moved to backlog at the code freeze for R2.6

[Karl Palmen]

This doesn't seem to be a serious problem. If you think it is, then fail the test and give details of the kind of change you think is necesary.

[Peter Peterson]

Considering the age of the ticket and the lack of work for the last 5 month I agree that we aren't going to fix this. However I would prefer if we did...I just don't have a good suggestion.

[Stuart Campbell]

This ticket has been transferred to github issue ​4033