Load algorithm throws exception when doing operations and different kind of files are present.

[Alex Buts]

this is extraction out of ticket #5205

When user is trying to sum number of files using Load algorithm interface if both raw and nxspe files are present, nxspe files are higher in a search path and last time you were loading raw files, an unknown exception is thrown

This problem occurs often but not always. The point indicating that exception would be thrown, is the load interface for the type of files different from the type of files you trying to sum. Sometimes even this works fine but mainly not.

Ann Terry (Sans2D) have risen the same issue when working with Load algorithm. They are typing file names in Load algorithm field and have 2 types of input files (raw and nxs). Claim was that nxs do not work from load but does work from loadNXS. I am almost sure, they hit the issue, revealed by this ticket.

[Peter Parker]

Refs #5441 - *Added* multi file functionality to Load dialog.

Now allowing devs to ask that MWRunFiles deals with file finding via a specified algorithm property instead of the default method of passing the user's inputs straight to FileFinder, which is ill-equipped to deal with complex multi file loading / addition, etc.

LoadDialog now uses MWRunFiles in this way, via the "Filename" property of Load.

This indirectly solves most (all?) of the recent problems surrounding the Load dialog, which are a result of my lack of understanding in how it could be affected by adding the multi file functionality. I had certainly not intended for LoadDialog to be even used for multi-file loading at this stage, and so had simply not catered for it or spotted the problems caused. Mea culpa.

There are still some outstanding issues:

1) Currently, the suggested ws name given to Load by the dialog is just the "base" of the first filename, i.e. loading IRS21000+21009.raw produces a ws with the name "IRS21000". This name is neither helpful or accurate.

2) After loading multiple files and then reopening the dialog, the MWRunFiles widget contains the full file name of the first file ONLY. This issue is compounded by the fact that specifying addition / ranges of files during multi file loading is supported via the syntax

[full_path][inst][run]+[run][.ext]

BUT NOT

[full_path][inst][run]+[full_path][inst][run][.ext].

As far as I can tell it is only going to be possible to either:

a) display the full file path of the files that have been found but not specify which files were added to which; OR

b) accurately display which files are being added to which, but not display their full files path.

If b) is to be implemented I can not comment on how big a loss (if at all) not seeing full file paths would be. a) Does not seem to be a reasonable option.

Changeset: 8a0496585be1c2407e4aa8b9196bb3919fac6760

[Michael Reuter]

Refs #5441. Using correct object for calls.

Changeset: faafb1f8e206f845db65f4fe6ec885ac1830655f

[Peter Parker]

Refs #5441 - *Added* multi file functionality to Load dialog.

Now allowing devs to ask that MWRunFiles deals with file finding via a specified algorithm property instead of the default method of passing the user's inputs straight to FileFinder, which is ill-equipped to deal with complex multi file loading / addition, etc.

LoadDialog now uses MWRunFiles in this way, via the "Filename" property of Load.

This indirectly solves most (all?) of the recent problems surrounding the Load dialog, which are a result of my lack of understanding in how it could be affected by adding the multi file functionality. I had certainly not intended for LoadDialog to be even used for multi-file loading at this stage, and so had simply not catered for it or spotted the problems caused. Mea culpa.

There are still some outstanding issues:

1) Currently, the suggested ws name given to Load by the dialog is just the "base" of the first filename, i.e. loading IRS21000+21009.raw produces a ws with the name "IRS21000". This name is neither helpful or accurate.

2) After loading multiple files and then reopening the dialog, the MWRunFiles widget contains the full file name of the first file ONLY. This issue is compounded by the fact that specifying addition / ranges of files during multi file loading is supported via the syntax

[full_path][inst][run]+[run][.ext]

BUT NOT

[full_path][inst][run]+[full_path][inst][run][.ext].

As far as I can tell it is only going to be possible to either:

a) display the full file path of the files that have been found but not specify which files were added to which; OR

b) accurately display which files are being added to which, but not display their full files path.

If b) is to be implemented I can not comment on how big a loss (if at all) not seeing full file paths would be. a) Does not seem to be a reasonable option.

Changeset: 8a0496585be1c2407e4aa8b9196bb3919fac6760

[Michael Reuter]

Refs #5441. Using correct object for calls.

Changeset: faafb1f8e206f845db65f4fe6ec885ac1830655f

[Peter Parker]

Refs #5441 - *Added* multi file functionality to Load dialog.

Now allowing devs to ask that MWRunFiles deals with file finding via a specified algorithm property instead of the default method of passing the user's inputs straight to FileFinder, which is ill-equipped to deal with complex multi file loading / addition, etc.

LoadDialog now uses MWRunFiles in this way, via the "Filename" property of Load.

This indirectly solves most (all?) of the recent problems surrounding the Load dialog, which are a result of my lack of understanding in how it could be affected by adding the multi file functionality. I had certainly not intended for LoadDialog to be even used for multi-file loading at this stage, and so had simply not catered for it or spotted the problems caused. Mea culpa.

There are still some outstanding issues:

1) Currently, the suggested ws name given to Load by the dialog is just the "base" of the first filename, i.e. loading IRS21000+21009.raw produces a ws with the name "IRS21000". This name is neither helpful or accurate.

2) After loading multiple files and then reopening the dialog, the MWRunFiles widget contains the full file name of the first file ONLY. This issue is compounded by the fact that specifying addition / ranges of files during multi file loading is supported via the syntax

[full_path][inst][run]+[run][.ext]

BUT NOT

[full_path][inst][run]+[full_path][inst][run][.ext].

As far as I can tell it is only going to be possible to either:

a) display the full file path of the files that have been found but not specify which files were added to which; OR

b) accurately display which files are being added to which, but not display their full files path.

If b) is to be implemented I can not comment on how big a loss (if at all) not seeing full file paths would be. a) Does not seem to be a reasonable option.

Changeset: 8a0496585be1c2407e4aa8b9196bb3919fac6760

[Michael Reuter]

Refs #5441. Using correct object for calls.

Changeset: faafb1f8e206f845db65f4fe6ec885ac1830655f

[Peter Parker]

Refs #5441 - Fix bug where we were erroneously removing whitespace.

Changeset: 12dd145aab2d27e4f9940574eeec0f05e91e7545

[Peter Parker]

Refs #5441 - Fix builds.

Move folder creation / destruction to inside test case.

Changeset: 7e8ec1acc74cfe1b250d09123a7062bb7e069169

[Peter Parker]

Refs #5212, #5441 - Better parsing when multifile loading. Hist Fixed.

Allow filenames specified with the format <<short><operator>>...<short> where:

<short> = <dir><inst><underscore><runs><ext> <operator> = "+" or "," <runs> = lists and/or ranges of (possibly added) runs e.g. "12,13+14,15:20".

See header file of MultipleFileProperty for more info on syntax.

This enables workspaces loaded through the algorithm to have a history that can be used to reproduce the workspace properly.

MWRunFiles widget of LoadDialog now remembers the exact text a user typed - in this way any user who types "INST0-50", clicks "Run" and reopens the dialog is not met by a huge string containing a list of all 51 fully resolved files, but rather their original input.

Changed the vector<vector<string>> templated versions of the toString and toValue functions to accept customised delimiters. This enables us to add an option for the user to turn off multifile parsing if they are crazy enough to want to load files with a plus or a comma in their path.

Changed the inner workings of Load for multi files. No longer calling sub algorithms with setChild or alwaysStoreInADS. All workspaces are essentially created outside the ADS and managed by the algorithm, right up until the OutputWorkspaces are set.

Tests added where appropriate, but the majority of parsing cases are already covered by MultiFileNameParser.

Changeset: 5b78e0e5d0e8d64f7d93b668d676148a029d66e5

[Peter Parker]

Refs #5441 - Fix bug where we were erroneously removing whitespace.

Changeset: 12dd145aab2d27e4f9940574eeec0f05e91e7545

[Peter Parker]

Refs #5441 - Fix builds.

Move folder creation / destruction to inside test case.

Changeset: 7e8ec1acc74cfe1b250d09123a7062bb7e069169

[Peter Parker]

Refs #5212, #5441 - Better parsing when multifile loading. Hist Fixed.

Allow filenames specified with the format <<short><operator>>...<short> where:

<short> = <dir><inst><underscore><runs><ext> <operator> = "+" or "," <runs> = lists and/or ranges of (possibly added) runs e.g. "12,13+14,15:20".

See header file of MultipleFileProperty for more info on syntax.

This enables workspaces loaded through the algorithm to have a history that can be used to reproduce the workspace properly.

MWRunFiles widget of LoadDialog now remembers the exact text a user typed - in this way any user who types "INST0-50", clicks "Run" and reopens the dialog is not met by a huge string containing a list of all 51 fully resolved files, but rather their original input.

Changed the vector<vector<string>> templated versions of the toString and toValue functions to accept customised delimiters. This enables us to add an option for the user to turn off multifile parsing if they are crazy enough to want to load files with a plus or a comma in their path.

Changed the inner workings of Load for multi files. No longer calling sub algorithms with setChild or alwaysStoreInADS. All workspaces are essentially created outside the ADS and managed by the algorithm, right up until the OutputWorkspaces are set.

Tests added where appropriate, but the majority of parsing cases are already covered by MultiFileNameParser.

Changeset: 5b78e0e5d0e8d64f7d93b668d676148a029d66e5

[Peter Parker]

Closing. This turned into a bit of long and rambling ticket, so here's a summary:

• The problems related to this ticket were a result of the MultiFileParsing functionality being implemented for Load but not being implemented for the Load Dialog. This has now been rectified.

• The string a user enters into the Filename field of Load Dialog is now remembered exactly as the user typed it, instead of the fully resolved filename used previously. This is beneficial to users loading large ranges of files at once via "INST1-20" or similar, who do not wish to see a huge string of 20 fully resolved file names when they reopen the dialog.

• "Outstanding Issue 1)" from ​comment 3 is still unresolved. Leaving this for now, but suggestions for a sensible convention are welcome.

The original problem as described in the ticket description should no longer occur as a result of these changes.

[Anders Markvardsen]

Tested this by first load LOQ72224.raw and subsequently LOQ72224.nxs and no exception was thrown

[Stuart Campbell]

This ticket has been transferred to github issue ​6287