Engin-X - Umbrella Issue/ticket - up to a first basic GUI

[PeterParker]

This issue was originally TRAC 8368

This ticket is blocked by :

• TRAC8760
• TRAC9783
• TRAC9784
• TRAC9789
• TRAC9790
• TRAC9791
• TRAC10587- Issue Use the convertUnits algorithm in EnginX FitPeaks #11429 - use ConvertUnits wherever possible
• TRAC10589 - became duplicate
• TRAC10907 - Issue EnginXFitPeaks expected Peak analysis problem #11746 - FindPeaks behavior with expected peaks
• TRAC10909 - Issue EnginX FitPeaks Output #11748 - EnginXFitPeaks output table
• TRAC10910 - Issue Improve EnginX expectedPeaks loading for all EnginX algorithms #11749 - expected peaks loading
• TRAC10921 - Issue EnginX Algorithms unit tests #11760 - unit tests
• TRAC10967 - Issue EnginX Calibrate Output #11806 - EnginXCalibrate output table
• TRAC10968 - Issue Bank interpretation on EnginX Algorithms #11807 - bank interpretation (dupl).
• TRAC10969 - Issue Bank interpretation on EnginX Algorithms #11808 - bank interpretation
• TRAC11588 - Issue Add Vanadium (V-Nb) consideration into EnginX algorithms #12426 - add Vanadium
• TRAC11770 - Issue Create mock up for the first version of the ENGIN-X GUI #12608 - mock up for first GUI
• TRAC11771 - Issue Save calibration file for ENGIN-X (output from EnginXCalibrateFull) #12609 - save calibration file
• TRAC11772 - Issue Make first version of ENGIN-X GUI #12610 - first GUI
• TRAC11773 - Issue ENGIN-X: define what exact .par file to produce from EnginXCalibrate #12611 - save .par files as needed
• TRAC11862 - Issue Change the EnginXCalibrateFull algorithm to apply the calibration to the input workspace #12700 - apply calibration from EnginXCalibrate full to input workspace detector positions.
• Issue Change EnginX algorithms to take InputWorkspace instead of an input Filename #12926, use InputWorkspace input properties in all EnginX algorithms.
• issue Engg: EnggVanadiumCorrections algorithm #13184, add EnggVanadiumCorrections algorithm.

An "umbrella" ticket for any work to be done for Engin-X.

2015/06/22: edited with new github issue numbers and current status.

[PeterParker]

@PeterParker (2013-11-22T14:51:46):
Nick and I met with Joe and Saurabh on 2013/11/22:

• Both Joe and Saurabh were very enthusiastic about getting their existing reduction into Mantid.
• Their code is OpenGENIE based, and split into three main chunks.
• They were keen to have us work on the "underlying algorithms" while they spend time with Balsamiq to mock up some potential GUI interfaces which could then be used to wrap the functions.
• They suggested that it also might be helpful with the transition to have reader/writer algorithms that work with a current intermediate file type they use, called "G3 intermediate". A potential use for these algorithms would be to allow event data to be translated within Mantid to histo data, and then used in their current OpenGENIE reduction. Further inspection of the code will reveal how much of a priority this is. Nick mentioned that Freddie would be a good person to talk to about this format, should help be needed.
• Joe and Saurabh pointed out that there are things about their current reduction they'd like to change and improve upon. We stressed that we are more than happy to take things forward and make improvements once the initial "translation" has been done.

I also have in my possession a printout of some details they've typed up about their current reduction. I will add this in a future comment.

---

@PeterParker (2013-11-25T15:59:24):
Information provided to us about the current reduction:

There are three main functions in OpenGENIE at the moment.

1. '''Analyse Scan'''

   The most extensive of the three programs. Linked to Calibrate.

   Takes a range of runs. For each run, apply intensity normalisation, export to GSAS.EXP file with relevant calibration values, refine the lattice parameter in GSAS, read the result back in from the .EXP file, average the associated relevant log values, and collect these result for all runs in the range into a single structured .HDF.

2. '''Find Pin'''

   The simplest of the three programs.

   This takes a range of runs and averages the intensity value for each of the two banks. Plots this intensity against some logged value, usually a motor position. Fits a function, usually a Guassian, to the intensity value and reports the parameters of the fit. The current function takes its name from the usual use of finding the position at which a metal pin, when scanned across the beam, gives the maximum intensity.

3. '''Calibrate'''

   The best place to start translating.

   Takes one or both of two runs - a null scatterer which is used to measure the incident beam intensity, and a measurement of a known powder (one of 4 or 5 different possibilities, usually CeO2 in practice to determine the relation between the measured time of flight and the d-spacing in the sample. The calibration date derived from this procedure is subsequently used by any subsequent analyse_scan command.

In Mantid, they would envisage having an Engineering menu in Interfaces, with the above three options. The aim should not necessarily be to replicate the existing functionality of OpenGENIE, where obvious improvement can be made. The current interface is a console-based interactive utility -- in Mantid a GUI with a "wizard" or tabs for each section of the console-based program might be a good starting point.

---

@NickDraper (2014-02-14T11:08:32):
bulk move to assigned at the into of the triage step

---

@NickDraper (2015-04-27T08:10:34):
Moved to R3.5 at the R3.4 code freeze

---

Federico M Pouzols (2015-05-06T15:52:18):
Added new ENGIN-X tickets that have been opened in the last few months as 'blocked by'.

[FedeMPouzols]

I'm adding new EnginX issues/tickets that are not listed here. I'm thinking that this umbrella issue should be closed when we get the first basic GUI (which also implies that we'll have a certain consistent state for all the EnginX algorithms). After that we could make another umbrella for the next steps, if needed.