Ticket #8219 (assigned)
Bug in workspace group 'similar names' code if suffixes don't count from _1
| Reported by: | Russell Taylor | Owned by: | Anyone |
|---|---|---|---|
| Priority: | critical | Milestone: | Backlog |
| Component: | Framework | Keywords: | |
| Cc: | saviciat@… | Blocked By: | |
| Blocking: | Tester: |
Description
Andrei says:
Yesterday I was working with Michael Reuter and we found a serious bug in the design/implementation of workspace groups. Suppose I get a workspace group A, as the output of FilterEvents, containing A_0, A_1, A_2, A_3 workspaces, and I want to normalize by proton charge. If the output of NormaliseByCurrent is set to B, the B group contains B_1, B_2, B_3, B_4. Note the shift in numbers. This shift causes problems if I happen to choose the output name to be A. For the first workspace A_0 will become A_1=A_0/PC. And A1 is going to be overwritten. By induction A2=A_0/PC2, A_3=A_0/PC3 and so on. So at my output I will get copies of A_0 divided by proton charge different number of times instead of individual workspaces divided ONCE by proton charge.
Is anyone willing to come up with a nice design so that this thing does not happen? I was thinking that just take the output name and append the individual workspace names, but if you run a lot of algorithms, you might get A_A_A_A_A_A_0, A_A_A_A_A_A_1, and so on. But this has the advantage that we can track the origin for each of the workspaces.
The problem is that the code for trying to figure out if the workspaces have similar names (in Algorithm::checkGroups) only looks at what comes before a '_', and assumes that what comes after counts from 1 (as it does if you start out loading a multi-period ISIS file).
My first thought was that you could just check if input & output workspace names are set to the same thing, but this breaks down when you realise that there could be more than input and/or output.