Ticket #9888 (closed: fixed)
Better design for MultiPeriod group workspaces
Reported by: | Owen Arnold | Owned by: | Owen Arnold |
---|---|---|---|
Priority: | major | Milestone: | Release 3.3 |
Component: | Reflectometry | Keywords: | |
Cc: | Blocked By: | ||
Blocking: | #9848 | Tester: | Nick Draper |
Description
Design changes to Mantid that satisfy the requirements for leaner multiperiod group workspaces.
- Logs and common meta data should be shared until the point that they diverge in the group
- X-arrays should be kept common. Ideally only have one for the group, so that ConvertUnits, Rebin etc operations are more efficient
- Multiperiod group workspaces should give better access (via the python API) to run and log information. See comment below.
This work needs to be understood, designed and approved before any coding is done.
Note from user Max Skoda:
It seems we all agree now as to what the problem is. Regarding the pooling of meta-information we need to be a bit careful. What you say (only Y and E are period specific) is I believe almost correct, though there probably are a few other period specific values (such as duration, monitor_sum?, I'm not sure how things are saved in the nexus file). So it'll probably have to be a mix of common and period specific metadata. Perhaps one could have pointers from each period to the common information or something like that. Ideally though, a (MultiPeriod) GroupWorkspace should have the same methods and properties as a 'normal' workspace - that would also simplify our code. Also, if the X values are common, mathematical operations, or the like of ConvertUnits would also be a lot faster.
Change History
comment:3 Changed 6 years ago by Owen Arnold
- Status changed from assigned to verify
- Resolution set to fixed
I have created the design document and presented it to the TSC https://github.com/mantidproject/documents/blob/master/Design/MultiPeriodGroupWorkspace.md
Our decision is to profile the test case in #9848 and then to make fixes based on the profile results. My feeling is that it will identify loading/saving as the bottlenecks. The aim will then be to make fixes highlighted by the profiling results rather than introducing a new workspace type. No code changes made as part of this ticket.
comment:4 Changed 6 years ago by Nick Draper
- Status changed from verify to verifying
- Tester set to Nick Draper