Ticket #11416 (new)
Long term handling of embedding Nexus IDFs
Reported by: | Anders Markvardsen | Owned by: | Karl Palmen |
---|---|---|---|
Priority: | critical | Milestone: | Release 3.5 |
Component: | Framework | Keywords: | core |
Cc: | Blocked By: | ||
Blocking: | Tester: |
Description
As approved by TSC implement suggestion 2 in https://github.com/mantidproject/documents/blob/master/Design/EmbeddedInstrumentInfoNexus.md
Change History
comment:2 Changed 6 years ago by Karl Palmen
The implementation of
If(Embedded PF) load it else if (external PF) load it
appears to be split between two or more algorithms. The details of this implementation need to be found out before work can proceed on this ticket. It appears that only SNS make use of the second line and ISIS use only embedded parameters if the IDF is embedded.
comment:4 Changed 5 years ago by Karl Palmen
I've found out that
Load Embedded IDF If(Embedded PF) load it else if (external PF) load it
is implemented in LoadIDFFromNexus, which is called by LoadISISNexus2. Hopefully, this is the only place it is implemented.
comment:5 Changed 5 years ago by Karl Palmen
Refactoring is necessary. Both
Load Embedded IDF If(Embedded PF) load it
are done by ExperimentInfo::LoadInstrumentInfoNexus. These two need separating to allow the loading of the parameters to be deferred and possibly replaced by a different parameter load.
comment:6 Changed 5 years ago by Karl Palmen
ExperimentInfoTest does not have a unit test for ExperminentInfo.loadInstrumentInfoNexus .
comment:7 Changed 5 years ago by Karl Palmen
Planned work on this ticket
(1) Unit test ExperminentInfo.loadInstrumentInfoNexus (#11719).
(2) Make separate functions to Load embedded IDF and Load embedded parameters (currently both done together by ExperminentInfo.loadInstrumentInfoNexus).
(3) Make one function to Load embedded parameters or if not found load parameter file. This is currently done separately in ExperminentInfo.loadInstrumentInfoNexus and LoadIDFFromNexus.
(4) Function or code to search for and find the XML file that has the corrections to parameters in it, henceforth referred to as the correction file. This must not take a long time if no such file exists.
(5) Function or Algorithm to read the correction file and output a filename & append flag as required.
(6) Code that makes use of the products of the previous steps to implement the ticket in each loader that may make use on an embedded IDF (may be one step per loader).
After a talk with Anders, it was decided to go ahead with the second version of Suggestion 2.
What we currently do can be expressed as
This would be changed to
This assumes that the date ranges of the correction items do not overlap and does not explicitly attempt to detect such an overlap. Instead, this can be done when the correction file is loaded and an exception thrown if an overlap is found.