{5} *Not Used" Assigned, Active Tickets by Owner (Full Description) (1043 matches)

Look at the usage of graphical workflow tools to drag and drop algorithms and connect properties to create new custom workflow algorithms and export as python.

This is an investiggation ticket to look at the toolss support and likely effort and benefits.

This should be an easy fix. The NumSteps parameter in PeakIntensityVsRadius throws the following error when the NumSteps is less than 0:

Error in execution of algorithm PeakIntensityVsRadius: vector::_M_default_append

My guess would be that adding a bounded validator would fix this no problem.

I've written a Python function with Attributes as well as parameters. I can select it in the Fit Function pane and the attributes are listed (first) and initialised to the default values specified in the code. If I then change the numbers in the pane, the function does not vary as expected but keeps the initial values of the attributes. Even Fitting, changing the parameters manually, or removing and adding the Guess curve does not prompt it to look again at the attributes.

Instead, if I call Fit(...) from the Python window I can initialise the Attributes to any values I want and it all seems to work OK.

James Lord. (Mantid 2.6)

Simplified code below, based on the examples:

class AttributeExample(IFunction1D):
        def init(self):
                self.declareParameter("Amplitude",0.2)
                self.declareParameter("Baseline",0.1)
                self.declareAttribute("Frequency",0.26)
                self.declareAttribute("Sine",False)

        def setAttributeValue(self,name,value):
                if name == "Frequency":
                        self._freq = value
                if name == "Sine":
                        self._sine = value

        def function1D(self,xvals):
                ampl=self.getParameterValue("Amplitude")
                base=self.getParameterValue("Baseline")

                if(self._sine):
                        ybins=numpy.sin(xvals*self._freq*2.0*math.pi)*ampl+base
                else:
                        ybins=numpy.cos(xvals*self._freq*2.0*math.pi)*ampl+base
                return ybins

FunctionFactory.subscribe(AttributeExample)

A really annoying feature of the windows version of Mantid that I’ve been meaning to mention for a long time is as follows. If I use a machine with 2 screens and place mantid on the 2nd screen and close it down it remembers where it was. However, if I then log onto the machine via a remote desktop Mantid does not detect that the second screen is missing and continues to place itself off screen. There is no easy way to get it back, unfortunately. There is a similar problem with detaching the various sub windows within the GUI. If they are placed off screen you cannot drag them back. Can someone have a look into the Mantid window size detection to try and resolve this. Thanks Rob

For example, having the following script as the Processing Step:

out1 = CloneWorkspace(input)
out2 = CloneWorkspace(input)
GroupWorkspaces('out1,out2',OutputWorkspace=output)

along with no post-processing gives the following error on the second time around:

Error in execution of algorithm MonitorLiveData:
Enter a name for the Input/InOut workspace

If I add a post-processing algorithm (e.g. ScaleX), I see the following error in the log (though it doesn't stop things):

MonitorLiveData started
Error storing output workspace in AnalysisDataService
Error in execution of algorithm StartLiveData:
WorkspaceProperty doesn't point to a workspace
Loading live data chunk 0 at 21:01:11

These were found while testing #7019, but were pre-existing problems.

From Pascal:

If you make a mistake by choosing Direct instead of elastic, it seems to remember somehow and subsequent conversion don;t work, see below. This is not urgent as you can reload from scartch and start with proper "elastic" option again and it works.

###################################################################### #Python Script Generated by GeneratePythonScript Algorithm ###################################################################### LoadRaw(Filename=r'/archive/ndxwish/Instrument/data/cycle_13_3/WISH00025470.raw', OutputWorkspace='25470') CropWorkspace(InputWorkspace='25470',OutputWorkspace='25470',XMin='6000',XMax='99000') ConvertUnits(InputWorkspace='25470',OutputWorkspace='25470',Target='Wavelength') ConvertUnits(InputWorkspace='25470',OutputWorkspace='25470',Target='TOF') ConvertUnits(InputWorkspace='25470',OutputWorkspace='25470',Target='Wavelength') ConvertUnits(InputWorkspace='25470',OutputWorkspace='25470',Target='Wavelength') ConvertUnits(InputWorkspace='25470',OutputWorkspace='25470',Target='TOF') ConvertUnits(InputWorkspace='25470',OutputWorkspace='25470',Target='Wavelength')

Axes page of Plot details dialog should disable the axis options in the combo boxes which not shown on the plot.

Dear Mantid team, I just stumbled accross some inconvenience as I wanted to declare an array property where the individual values are supposed to have a minimum, but not a maximum value.

For single numbers it is very convenient:

self.declareProperty('SingleNonNegativeInt', 0,

direction = Direction.Input, doc = "a non-negative integer", validator=IntBoundedValidator(lower=0.))

But for an array it does not work like this:

theProp = IntArrayProperty(name='PositiveNumbers',

validator = IntArrayBoundedValidator(lowerBound=1), direction = Direction.Input)

self.declareProperty(theProp, doc = "Positive integers")

# (Nasty anyway that here it is 'lowerBound' # whereas for non-arrays it is 'lower'...)

This is because 'IntArrayBoundedValidator' does not have default arguments nor understands 'None'. This is the workaround:

onlyLowerBound = IntArrayBoundedValidator(lowerBound=1, upperBound=1) onlyLowerBound.clearUpper() theProp = IntArrayProperty(name='PositiveNumbers',

validator = onlyLowerBound, direction = Direction.Input)

self.declareProperty(theProp, doc = "Positive integers")

Would be nice if setting bounds on single values or arrays would behave similarly (and in an easy way)...

Rather than have a separate configuration file for grouping/masking than the rest of mantid, migrate towards the common grouping and masking files/workspaces that the rest of mantid is working with (#2474). There will likely be need for an algorithm that converts the grouping/masking columns of the existing .cal file to the new common format.

This call on matrixworkspace throws if grouped detectors are found.

Go through algorithms using this call and assess if they can be made group friendly, then either fix them or create specfic tickets.

Once all usages are gone then the boolean itself should be removed and the method always return group capable data.

The same applies to getDetectorIDToWorkspaceIndexVector(??, ?? ,true)

It is currently impossible to set the default colourmap for MantidPlot. It is hardwired in the code and any selection for colour fill plots is not persisted.

We should allow a file to be set as default and fallback to the inbuilt one if the file cannot be accessed.

When in View->preferences...->Mantid->'Curve Fitting' an auto background is selected then if a fitting peak is added to graph the height of the peak is shown from the background.

However when no auto background is selected and a user manually adds a background then this does not apply (it measures the height of the peak in the fit Plot window from the bottom of the y-axis rather than from the where the background function is)

Allow the following IDF syntax

Currently you can do, see http://www.mantidproject.org/IDF#Using_.3Cfacing.3E

<location something >

<facing something />

</location>

Also allow

<locations something >

<facing something />

</locations>

What I report here you may reproduce using loading the file below and opening the ColorFillPlot on it.

​http://trac.mantidproject.org/mantid/attachment/ticket/7865/19675_sans_2d.nxs

• Select Layer1 -> Tab Geometry -> Change size width to 600 (some axis will desappear). The same occur if you have Keep aspect Ratio on Windows resize.
• When you open the ColorFillPlot the widget of Data opens as well (annoying)
• What is the meaning of UserHelperFunction?
• Select UserHelperFunction -> Tab Colors -> Change the ColorBarScale to Top: The axis on the right remains. As a side effect, changing the scale of that axis still applies to the image. (Explaining, close the Plot Properties. Open the Axis Dialog, Tab(Scale), change to Logarithm, and the image colors will change, although the color map (on the top) does not change).
• Select UserHelperFunction -> Tab Colors -> Change the ColorBarScale to Bottom. You have lost 'forever' the positions of the horizontal axis. (it is not really true, it just is applied now in the top, but it is by default invisible).
• Select UserHelperFunction : Why do we have a Plot Type with a combobox with only one option?
• Select UserHelperFunction -> Tab Axes: What is expected if you attach curve to xAxis Bottom or Top? It is not clear. (Tool tip?)
• Select UserHelperFunction -> Tab CountourLines. Select ShowContourLines. The 'Set Levels' change things in the image, but it is not correct until you click on Apply.
• Select UserHelperFunction-> Tab CountourLines. What is the purpose of Use Table Custom Pen?
• It is not clear that the labels tab will be enabled only if you show contour lines, and why you cannot add label to this plot as well.

Finally, it could be possible to save the options to be the new default for that user?

When sprecta are plotted from several workspaces only the name of the first workspace appears in the title. A title that indicates all workpaces or has an etc if there are many would be more accurate.

It is a source of slow builds and memory leaks. Rewrite it to read the data from a file.

Line 107 in LoadParameterFile has a dodgy pointer cast as explained in comment above it

  // TODO: Refactor to remove the need for the const cast
  Instrument_sptr instrument = boost::const_pointer_cast<Instrument>(localWorkspace->getInstrument()->baseInstrument());

This ticket is basically that TODO.

It has not yet caused a known problem, but the functionality of the code is useful for putting parameters into a workspace (e.g. from a fullprof file).

Once we've fixed things so that WorkspaceGroups can be passed around by pointer, we shouldn't any longer need the special handling code that was added to this algorithm in #8226.

Current MD axis implementation is not in any way related to Axis.

This creates various difficulties in comparing/working with MD workspaces as separate workflow is necessary to work with MD Axis.

This does not allow, for example, easy check if two workspaces are compatible, as current MD units are just captions which have noting in common with Mantid units (which identify that the data in two workspaces can not be usually added together and have to be converted one to another).

The purpose of this ticket is to provide as much similar behaviour between MD Axis and Axis as reasonable. Ideally they have to become one.

In minimal scenario, MD Axis should use the same units as Axis. (and this is Mantid Units provided by the unit factory)

This was reported by a user, Carl Jindra, from GE.

We currently do not have any way of displaying a table workspace from a script.

Add a simple command to the mantidplot language, something like display, that can display a workspace in the most sensible manner, i.e display the matrix for Workspace2D and show a table for a TableWorkspace.

If the workspace history contains xml that contains quotes the script will give an error when running. For example the SANS reduction can call MaskDetectorsInShape() which leads to an unrunable script like the attached

Plotting a 1D graph and then changing the axes scale causes the graph to not be rescaled to fit the window correctly when there are negative values.

There is already a "Rescale to show all" button the on interface. A call to this after changing the axes scale would probably fix this.

Run the following script:

wsName = "CNCS_7860_event.nxs"

Load(Filename=wsName,OutputWorkspace=wsName)
SaveNexus(InputWorkspace=wsName, Filename="temp.nxs")
LoadNexus(Filename="temp.nxs", OutputWorkspace="roundtrip")

print CheckWorkspacesMatch(wsName, "roundtrip")

This prints:

Axis 0 values mismatch

Essentially, it appears as if raw event data is not surviving a save/load round-trip, though it may be the case that CheckWorkspacesMatch is not doing a correct/meaningful check in this case.

Mantid does not accept any mouse input under a certain set of circumstances and has to be closed unless the Alt+F4 keyboard shortcut is used. To reproduce:

• Open up the Python scripting window and place it in a position similar to that shown in the attached image.
• Set the Python window to be "Always on Top".
• Type "Load" and press enter into the Algorithm field as shown in the image.

The ​modal nature of the dialog means that you can't click outside of the dialog, but the Python scripting window will block you from clicking on the dialog!

Use Alt+F4 to close the dialog and regain control of Mantid.

I've set this to minor since this will probably be quite a rare occurrence.

When moving a color or 2d plot, if the Major and Minor ticks are set to "in" rather than "Out", the ticks appear in the grabbed image and the grabbed image doesn't update when being dragged only when released.

The predefined axis views should operate in the same mode as VisIt and/or ParaView. Both programs agree that the direction of the predetermined view is away from the observer. Also, the locations of the other axes should be aligned to the way these programs work. They both agree on the orientations for Z and Y, but not X, so for that one any choice will do. Also, the programs specify their labels with the signs in front, so we should make them consistent (i.e. +Z). Here are the orientations for the axes:

• +Z: +Y up, +X left
• -Z: +Y up, +X right
• +Y: +Z up, +X right
• -Y: +Z up, +X left

ParaView

• +X: +Z up, +Y left
• -X: +Z up, +Y left

VisIt

• +X: +Y up, +Z right
• -X: +Y up, +Z left

I have loaded many files (all files that are loaded inside the LoadLotsOfFiles)

if __name__== "__main__":
  a = LoadLotsOfFiles()
  files = a.__getDataFileList__()
  for f in files:
	Load(f,OutputWorkspace=str(f).split('/')[-1])

Than, after, I selected all of them, and clicked in Delete. It took more than 2 minutes to delete all of them, and i got this strange error message:

Workspace CSP85423.nxs could not be found.
Workspace MUSR00015192.nxs could not be found.
Workspace NewGroup could not be found.
Workspace OFFSPEC00010791.nxs could not be found.
Workspace OFFSPEC00010791.raw could not be found.
Workspace OFFSPEC00010792.raw could not be found.
Workspace OFFSPEC00010793.raw could not be found.
Workspace POLREF00003014.raw could not be found.
Workspace POLREF00004699.nxs could not be found.
Workspace POLREF00004699.raw could not be found.
Workspace SRF92132.nxs could not be found.
Workspace SRF92132.raw could not be found.
Workspace emu00031895.nxs could not be found.
Workspace irs26176_graphite002_QLr_Parameters.nxs could not be found.

This happened in ubuntu 12.04. In windows 7 MantidPlot will eventually crash with Windows trying to send the report of the failure.

Many interfaces use the standard red star as a validator marker. The only problem is that it is implemented differently and some have ended up with different variants of the colour. It should be simple to write a small widget that encapsulates the validator and export it as a designer plugin.

I have added some basic validation to this GUI in #3737, but that was simply to stop it crashing, the GUI really needs some more validation in cases where the program may not crash, but it would be nice to tell the user why nothing happened.

This is most notable when even though the shape tree is valid in terms of structure and shape parameters, nothing renders. In this case the 3d environment could do with a message popping up in it; not a dialogue box that has to be clicked, just something in the environment that will say "this can't render".

This could also extend to invalid points given to shapes

in view -> preferences -> General -> Floating windows you can select the types of window that are contained within the mantid main window or floating on it's own. 3d plots don't float no matter what it set and will always be restricted to the mantid main window.

Try adding a new layer to an existing plot using the following instructions:

http://www.mantidproject.org/MBC_Displaying_data_Complex

Unfortunately, to get the titles of the two layers to align like they do in the image, you have to adjust the sizes of the layers manually.

It would be nice if the "add layer" functionality was clever enough to see what size layers are there already, and just use that size.

In a similar way that we now colour monitors in the workspace, colour the background of the row if a spectrum is masked

This is a weird behavior that was observed while testing #10842.

Open the muon data analysis interface and switch to different tabs. Depending on your platform the behavior may vary, but sooner or later you will see how the "Data Display" toolbar visibility changes.

I see no reason why changing to different tabs in the muon interface should modify the visibility of the application toolbars.

The cursor for the screen reader tool for 2d graphs (and perhaps other applications) seems to have it's hitzone one pixel too many to the right as the line that appears after a click is one pixel to the right of the guidelines on the cursor itself.

Reported by Russell Ewings:

I can reproducibly crash Mantid when using the He3TubeEfficiency algorithm. See attached for code that illustrates the bug, together with the crash report. I was running this on a Windows 7 machine.

Two small bugfixes/enhancements related to load with operations requested by the instrument scientist

1) Try to load group of files which are absent (or one is absent) e.g.:

Load('LET00014305.nxs+LET00014300.nxs',OutputWorkspace='w1') # here second file is missing and first is in system tests data folder

Algorithm generates confusing message: RuntimeError: Instrument search object LET00014305.nxs+LET Which is incomplete (last file name is cut) and confusing. Should report: Can not find file LET00014300.nxs

2) Try to run:

Load('LET00014305.nxs+LET00014319.nxs',OutputWorkspace='w1',LoadMonitors='1')

These are two files collected in event mode with monitors collected in histogram mode.

Monitors are not loaded and not summed together -- just missed.

Should be loaded separately and summed together like main workspaces.

and reconcile it with slice/bin transformations

u,v,w vectors define additional transformation while converting to MD and describe in some way something partially similar to affine transformations available in BinMD/SliceMD transformations

They also, like BinMD/SliceMD store its information for subsequent use somewhere in workspace properties.

The purpose for this ticket is:

Extract common part of the transformation, defined by ConvertToMD and Bin/Slice MD and make it accessible through the same interface.

Store both transformations in the same place of MD workspace (currently they are storing different things)

Carefully verify all its options working properly in different conversion modes (NoQ Orthogonal HKL, HKL) and describe what they are doing in each mode.

Describe it and compare with Horace.

ConvertTo MD interface become complicated and overloaded.

It should be simplified either according to the agreed suggestions, offered by the letter below , or by the interface improvements, suggested in the ticket #6855

Now when MDWorkspaces factory is fully developed and virtual method allow adding events to MD workspace, MDWorkspaceWrapper become obsolete.

Any additional functionality still left there can be easy moved to MDWorkspacesFactory.

Improves code clarity and removes unnecessary code duplication.

There are few for the code I have written.

Not important but worth decreasing the noise

I am writing this ticket straggling again to remember and identify an algorithm appropriate for creating a testing workspace.

I think, creating a category of Testing algorithm and gathering these algorithms together in Mantid documentation for further references would greatly simplify such job in a future.

For the same reasons as #11049.

In ReductionHelper.py:261 there is code that changes the default facility and instrument that should not need to.

You can loop over facilities using config.getFacilities() to find a given instrument.

This is failing because of missing files:

• A large amount of MARI runs as .nxspe which just need to be put onto external data

Since this will take a considerable time to execute it should be considered if this test should be made to run as it is (possibly a version that runs on less files should replace it).

Load HYS_13656_event, rebin with a step of 10 preserving events, then ConvertToMD, using CopyToMD, and OtherDimensions='s1'. It would be nice if MD events were associated with the correct log value, instead of the first log value.

If m_pConf has keys that have been removed, getKeys(const std::string& keyName) will still return them. Happens on Windows at least, unconfirmed in Linux and Mac.

Presumably related to the try-catch block catching an exception thrown by getString

Discovered when fixing #4495 as it caused an error when populating the "Send To" menu after deleting a program from the "Send To" list (without restarting the program) as GetKeys was returning the items that had been deleted (or at least marked with the removed flag)

This is a requirement for macro-molecular work, e.g. MANDI at SNS.

Contact Leighton Coates at SNS for more detailed requirements.

Priority 3

Investigate whether values that the GUI needs arae available in metadata within the files, or other stores withinin the facilities, and use as appropriate. This needs an investigataion phase at each facility before implementation can begin.

Seperate the Instrument definition and parsing of XML.

This is likely to include

• Creation of an XSD file
• Auto Generated code from the XSD
• Refactor so the InstrumentDefinitionParser works on the generated Code, not the XML
• Refactor other places where the XML is used directly

See http://www.mantidproject.org/NormaliseByDetector, which uses IDF type="fitting" to associate an equation with a detector. However, for this case the scope of this type="fitting" parameter is that particular algorithm only.

See http://www.mantidproject.org/NormaliseByDetector, which uses type="fitting" associate an equation with a detector. What we really want is to avoid confusion by being able to say that a particular equation in the parameter file belongs to a specific algorithm. i.e. type="Algorithm:NormaliseByDetector", and make it incompatible with fit functions so that it doesn't get automatically applied (for the wrong purpose) in the fitting framework.

Please talk to me about this if it doesn't make sense.

Investigation done for ticket #7383 shows a need for a poisson cost function when dealing with low counts. The attached paper 'Effecieint Levenberg-Marquardt Minimization of the Maxiumum Likelihood Estimator for Poisson Deviates' describes the poisson cost function and it's derivatives.

Following #8214 and #8223 add tests that checks that when logfile parameters like

 <parameter name="x">
    <logfile id="trolley2_x_displacement" extract-single-value-as="position 1" />
  </parameter>) 

are defined in instrument definition file of nexus file that when raw nexus files are loaded (not mantid processed nexus files) than such parameters are updated according to log file information in a given raw file.

This is based on the observation from #8844 where it was observed that adding an additional SANS2D IDF caused a noticeable increase for the SANS2D systemtests.

Specifically it was observed from ​https://builds.sns.gov/view/Tests/job/ornl_test_rhel6_develop/System_tests_performance/ that the systemtest SystemTests.SANS2DFrontNoGrav.SANS2DFrontNoGrav saw a noticeable increase at revision 811 (when 2nd SAND2D IDF was added) and exactly the same drop when removed at revision 859. The is also observed for the other SANS2D systemtests, e.g. SystemTests.SANS2DBatch.SANS2DBatch.

The increase in performance is about 3 seconds, this about matches the increase of SystemTests.LoadLotsOfInstruments.LoadLotsOfInstruments and indicates that the entire IDF may be loaded during the process of Mantid deciding which IDF to load.

It is noted that all the SANS2D systemtests would have failed had the new SANS2D IDF been used rather than the old SANS2D IDF, hence the correct select of IDF is made by Mantid.

It should be possible to improve the Mantid code such that it takes less than 3 seconds to decide which of the two SANS2D IDFs to load.

Without looking in detail at the code the recollection is that we are using the SAX parser for investigating IDF dates, however this code may never have been checked for performance.

The purpose of this ticket is to improve the performance of the SANS2D systemtests, which is also expected to cause a performance gain for other instruments.

Emmanuel Farhi has started the process of creating an algorithm for transforming an IDF to PLY format, see attached IDF_to_PLY.py.

His idea is that if such a transformation is available it could open up an alternative door for exporting Mantid IDFs into instrument simulation software like McStas.

In this ticket work with Emmanuel to complite such an algorithm

Explicit description of the error propagation/calculation procedure should be added to http://www.mantidproject.org/Error_Propagation for Rebin, CalculateFlatBackground (and similar) and ConvertMDHistoToMatrixWorkspace.

I heard complains about their procedure and suspect follow up tickets there.

Richard Heenan has identified the SANS2D dataset, run 17915, as a dataset that is believe to suffer from significant multiple scatter.

The investigation here is to try to use McStas to calculate the multiple scattering for this sample.

I have left the component Framework, since although this investigation is using a SANS2D dataset, if this study is successful than it should in theory provide a technique independent method for calculating multiple scattering

There needs to be an algorithm that changes the coordinates of MD events/boxes, such as rotation, scaling, stretching, etc. This would allow conversion to different view (for example (1,1,0),(1,-1,0),(0,0,1))

Includes porting Horace Planner, Chop, etc to Mantid.

MDNormDirectSC and MDNormSCD should have better tests and usage examples

This is a request from Georg Ehlers (CNCS instrument scientist):

He would like to (for powder data) be able to arbitrarily 'rebin' the spectrum axis into angles (polar) of a given width. This is basically so he can easily produce data in 'rings' without having to create a mapping file for each case - as he might not know how wide the rings need to be ahead of time.

I think that this should be 'relatively' straight forward :-) and will probably be along the lines of the new SofQW algorithm... or maybe not!

Create an algorithm to save the cut format (.cut) files that can be produced by mslice and loading into TobyFit.

So that by default the dimensions are shown as the middle of that bin.

In integration, the code should be replaced by calling CropWorkspace, Then Rebin. This will also make partial bins compute the correct error bars.

Create an algorithm similar to SmoothByComponent (#7236), that collapses the number of spectra

When using ConvertToMD with single crystal data using the "SCD Event Data Reduction" interface with MAND_306_event.nxs, Max |Q| set to 5, and Apply Lorentz Correction turned on, the data (as viewed in the slice viewer) is over sub-divided. This can be seen by finding peaks and looking at one in the slice view. There will be boxes with zero counts next to ones with thousands of counts.

The suggested fix is that if a subdivision results in boxes with zero counts (when the source box has more than enough counts), don't do the subdivision.

Change all Load* algorithms to add the filename to the run object on the workspace

Make it more efficient. Allow energy dependent cross section

When one creates an MDHisto workspace with ImportMDHistoWorkspace, one cannot add an oriented lattice since there is no ExperimentInfo attached to the MD workspace. One should be able to copy an experiment info, or add one

Priority 5 (lowest)

Contacts:

• William Heller
• Richard Heenan
• Andrew Jackson (ESS)

Original suggestion from Gesner:

I think the following systemtests should be added for SANS2D:

• Normal reduction in batch mode
• Copy of the single mode reduction and double check with the result in batch mode.
• ADD a run twice and perform full reduction checking that the result is compatible with loading a run and applying the reduction to 2XRun.
• Performing the reduction as in the single mode (GUI) twice produces the same result
• Perform a full 2D reduction
• Searching the centre

Perform all these tests for low angle and high angle detectors.

Misc suggestions from Gesner which you should sift through and interpret as you see fit. Some of these may not be necessary:

• Transform #7643 and #8052 in systemtests
• UnitTests for SANSUtility methods.
• Add many SANS2D files
• Monitor getLogData from SANS2D #7612
• Multi period - check mult period files available
• UnitTest for maskfile
• Perform slicing and reduction.
• Avoid error similar to #5942
• Create a system test exposing the problem with long log run.

Richard has agreed to provide us with data (as small as possible) to cover the routes through the code that he feels are important. Do these first then consider whether further coverage is necessary based on Gesner's suggestions.

When a view is created in the VSI it currently stores a pointer to the source in a field called origsrc. When a view is switched to MULTISLICE, this source pointer gets copied into the new view.

If there is a second workspace, it is possible to delete the active source, i.e. setting origsrc to null and to switch the views. Essentially a null is copied. In the MULTISLICE view a representation is created in setupData(). This requires origsrc, but since it is null, this is not possible.

The branch feature/7363_vates_paraview_git contains changes made by Steven Hahn, Owen Arnold and Utkarsh Ayachit of ParaView to the VSI with ParaView 4.2 in the background.

The current VSI is based on ParaView 3.98.1. This branch aims to integrate the above changes into the current VSI and ensure that conflicts are resolved.

At the Vates AA meeting it was discussed to have the following settings enabled:

1. Having the labelled axis on by default in QuadView
2. Make text underneath the views in QuadView smaller
3. Display appropriate units
4. Control the tick marks (this needs to be discussed further).

Steve writes:

Please could you create a ticket for the following.

This weekend on SANS2D we measured the first ever flux line lattice superconductors at ISIS with neutrons, and things went pretty well.

One of the contributing user groups has some clever software they have written to simulate the expected 2D QxQy intensities, tested against experiments at ILL. Obviously their program will need tweaking to simulate t-o-f data.

As input data to the simulation, they would like Mantid to output (as one or more files) which detector pixels are contributing to any given QxQy point in a reduced 2D pattern for any given time bin.

This could be a script they could run from within Mantid.

But on first thought it seemed to me that it should be possible to extract this information during a reduction...?

Probably create python script for this since an algorithm which will likely not be executed often, where speed is less of a concern, and where the user may even want to be able adjust exactly what is outputted

Current status: wait to see what user come back with in their ‘spec’ of exactly what they want.

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/PC^{2, A_3=A_0/PC}3 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.

From Garrett Granroth

The graphics part of the instrument window does not go behind the active window.

version 1.31.15022

To reproduce:

• Bring up the instrument window
• Bring up a non-python interface (e.g. Step Scan Analysis)
• Make sure neither are 'floating' windows

http://www.mantidproject.org/SaveIsawPeaks is not working for non-rectangular instruments, such as WISH.

• Plan A. Algorithm should be made to work for non-rectangular detectors if possible
• Plan B. Algorithm should give-up and suggest using SaveNexus if not possible (above). See #4443
• Plan B. In addition to the step above. The documentation for this algorithm should inform users on what this algorithm is capable of working for.

When installing MantidPlot on a Mac, the default defaultsave directory is the location of the executable, as it is in Windows and Linux.

However, this location is not accessible, which will present the user with errors if they try and save something (as I think most of our users will want to do).

Could we perhaps choose a saner place? Ie, create a directory in the users /home or whatever the Mac-y equiv is.

This may also be the case on RPM builds.

It's become clear that we need to add some more options to history generation. At the moment we take a best guess of what is actually desired, but we need to cover.

1. History to the last load event
2. Full history excluding intermediate load/save event
3. Full History

Ensure these are available both in the algorithm and in the History window.

Since the unit cell angles are often known exactly, an option should be added to the FindUBUsingLatticeParameters algorithm to use the exact angles specified by the user, rather than allowing them to vary. A Boolean property should be used to control whether or not the angles can be varied.

SaveMask() is not able to work with workspaces with grouped detectors, i.e., one spectrum contain more than one detectors.

Users sometime need to group detectors (such as SumSpectra()) and then create mask from MantidPlot's instrument view.

This ticket is to make SaveMask() works under this situation.

SNAP has 4 motor positions of the East and West sides in the logs. Need mapping from log positions to more accurate positions in the IDF. Also need CalibrateRectangularDetectors to output log positions and accept as input corrected positions from user.

If one runs startLiveData and tests it using FakeEventDataListener, the FakeEventDataListener generate events in the range from 40000 to 60000 but user have no ways of determining that without running a debugger.

The event workspace comes with ranges from 0 to 10^{-308 which also not helping to identify the range of the data.}

Needed: Some description of the FakeEventDataListener with the range of the events it generates.

correct X-axis ranges in generated workspace.

Some description of the FileEventData Listener. It works, but it is absolutely unclear how to use it.

3D plots currently always include the whole workspace.

Alter them to only take selected data row if only a few are selected.

Also the default scaling of the graph is poor. if you select something with 10 spectra, 1000 time bins and counts up to 10000, the resulting graph is almost flat and useless.

OutputWorkspace should appear as optional argument in python function signature. It doesn't seem to appear at all at the moment.

This was a suggestion made during the Python in Mantid training course 10/Sept/2013.

According to one of our users QtiPlot now allows you to create a graph template onto which you can drag data. This seems like a quite a useful option, and this has been requested for implementation.

Write one. The class is in API.

This appear to have the effect of selecting Use color Map

Create a new Table. Right click on the second column and select Set column values. Enter col("2") in the text coltrol. Press Apply.

Found on Windows 7. To reproduce:

• Copy a data file to a local drive and change the read permissions of that file to "Deny".
• Run MantidPlot and open the Load dialog.
• Ensure that only the File and Workspace properties are shown. Enter a nonsensical string in the "File" field if necessary.
• Attempt to access your non-readable file by typing in the path (and NOT by browsing via the browse button).
• Click "Run", and close the dialog that successfully reports that Mantid has been unable to load the file.

The File and Workspace fields are now unresponsive to any user input.

[Set to minor as you have to jump through a few hoops to get to this stage, and it can be worked around by simply closing and reloading the dialog.]

I find if I select some test in the Python 'Script Output' window and copy and paste it. I find it has not been copied to to the clipboard.

This would be useful for E-mailing python script error or saving the results of trials.

To reproduce:

• Load a workspace and plot a spectrum.
• Drag and drop another workspace onto the graph and choose another spectrum to plot. A second curve should appear. This works fine and as expected.
• Now remove all the curves via the right-click menu.
• Try to drag and drop another workspace on to the graph - nothing happens.

Not sure if I'm missing something and this is intended functionality, but if we can display another curve via drag and drop in this situation then we probably should.

To reproduce:

• Go to View->Preferences->Mantid->Options and uncheck "show invisible workspaces"
• Click Load;
• Pick a file and prefix the suggested workspace name with __
• The algorithm will run but there should be nothing in the list
• Click load again and run the same thing but without the prefix. The invisible workspace will appear alongside the visible after the algorithm completes

If multiple Mantid processes are started on Windows you get a cryptic message on the console "Cannot open file" for all but the first one. It turns out that this is coming from the logging framework - the first time (& only the 1st time) the second process tries to log something to the mantid.log file it finds it cannot open it.

I'm not sure this is if sufficient concern to try and fix, but I thought I'd record it nonetheless.

N.B. You don't see the message with MantidPlot as it goes to stderr, though the issue is presumably still there.

If in MantidPlot, one creates a table then converts it to a table workspace, one cannot then give a column in that table workspace a name that contains a space character. This space character is removed if one attempts to do this.

While this may be a necessary restiction on QTI tables, it is not needed for table workspaces. Furthermore, some algorithms such as ApplyCalibration require a table workspace whose columns have specific names that have a space character.

For example, if you give LoadRaw an OutputWorkspace name that already exists in the ADS, you can tell before you commence exec that the existing workspace will be overwritten. Transient memory usage would be reduced if you deleted that one before you created the new workspace.

This can possible be implemented as a general feature in the Algorithm base class, but could certainly be easily put into LoadRaw.

Under Windows, the Xming X-server will crash when trying to open an instrument view in MantidPlot over ssh x-forwarding.

Theres a lot of if spectra, else if numeric, else if..... going on. We should make better use of virtual methods.

During the install, computing the space requirements can take a long time to run. Other times it completes instantly. These spurious time durations have also been observed by Martyn Gigg. This has been observed with the release candidate for iteration 28.

The current size can be altered using ctrl (or cmd) and scrolling the mouse wheel, but we should have a way in the preferences to set the default size and possibly other font details.

In order to make system tests take less time, write a tool that takes an existing event NeXus file and copies it with less events.

Create a script like

def doSomething():
    algorithm1(...)
    algorithm2(...)
    algorithm3(...)

Load...
doSomething()

During execution, the arrow showing the progress along the script in the script window is staying at the "doSomething()" line after "Load...". Instead, it should move inside the doSomething function, and point to algorithms 1, 2 or 3.

A number of common algorithms are gaining very specialised properties that the vast majority of user will not care about or understand. Have these hidden by default in the gui (obviously with a check-box to show them).

Examples are: "AllowDifferentNumberSpectra" on Plus and "VULCANDspacemapFile" on AlignDetectors

I saw this on the Mac.

• Load a data set
• Double-click on the workspace to bring up the matrix
• Menu 3D Plot->3D Polygons
• Rotate the box inside the plot
• Try and drag the matrix over the plot, it will only go under it.

The ability to draw only some symbols on a plot was added under #2656. Presently, this can only be controlled from Python.

Add the possibility to set this via the symbol settings dialog (see attached screenshot of current QtiPlot dialog).

To think about having two handlers per notification: one for fast non-GUI updates running in the caller's thread and the other for the GUI and non-time critical general updates running in the receiver's thread.

Since after ConvertUnits, the event's coordinate is NOT the time-of-flight. This can cause confusion for developers and possibly if the event gets exposed to python.

If you give GroupDetectors an XML file with a '.map' extension it falls over immediately.

I would think it be possible to peek at the first line and if it has an <?XML tag then assume it's XML

NOTE: auto-completion should only be done after Martyn is done messing with scripting, because the relevant code is there.

It's in QtiPlot's AddWidgetTool class (called from methods/shortcuts in ApplicationWindow). Allows adding rectangles & ellipses/circles (& equations) to plots.

The fact that the algorithm dialog's input workspace combo-box only shows valid workspaces is very useful for reducing clutter, but does mean that you can't see why a particular workspace is not valid (unless you go off and try to run it via python). This can be awkward if it's not obvious to the user why it isn't valid. Add some (not too intrusive) mechanism so that a user can find out why invalid workspaces were excluded.

Create a plugin for live data that watches for a file to modified and reload the file. This is useful for interacting with outside programs that can be configured to output to the same file frequently.

If you try to save a MD workspace using save>nexus. The current response is that the save dialog box closes as normal after you click save, but an error message appears in the results log. This response should make it more evident that the save had not happened, i.e. the save box should not close as normal.

This is an old tool that probably pre-dates our usage of CTest, and definitely pre-dates our move to git Code/Tools/TestViewer/. Needs to be removed.

The PhysicalConstants class doesn't appear to be exported to the python API. It would be nice to have it available.

In principle the return should be std::size_t since it will be returning the result of MatrixWorkspace_sptr->blocksize().

This follows on from #3832 & #3240. We should check whether there are other places where checks for the Graph::ColorMapContour curve type should be added (should look at all the places where Graph::ColorMap & Graph::Contour appear).

Actually, it's not obvious to me that adding this extra curve type was the right thing to do. Isn't this actually 2 curves - a colorfill & a contour? I ask because I find that although I can switch the contour lines on and off in this type of plot, I can't remove the color map - even though the 'Plot Details' dialog suggests that I ought to be able to. (N.B. It's the same situation with both the 'Color Fill' & 'Contour Lines' plot types: contour lines can be toggled, but not the color fill).

Also, why is it referred to as a 'UserHelperFunction' in the 'Plot Details' dialog? That doesn't seem a description that is helpful to the user.

I ran the SANS 2D analysis and plotted a 3D polygon plot. The graph looked fine and zooming works but initially the cube containing the data was not centred within the window, it was pushed over the right as if the lower left-hand corner was being placed at the centre of the window

There's a new log in the event nexus files that come out of the STS that is different to a standard log so unfortunately will need special handling in LoadNexusLogs.

The format is:

/entry/DASlogs/comments
time (FLOAT64) - comment timestamp in seconds from beginning of run.
offset (UINT32) - comment data offset
length (UINT32) - comment length
data (CHAR) - comment string data block

Need to talk to Mark Telling, Sanghamitra and Spencer for more detail here

To begin with, push "MuScat" library files and Python script.

They both do very similar things, but FuryFitMult uses a multi domain function instead. We can combine most of the functionality and make the output of the parameters table more consistent.

Part of the issue with this is that multi domain functions cannot be converted to a function string from the C++ API. Roman has a ticket to fix this as part of #9251.

If you have an algorithm with an optional WorkspaceProperty, and if you run that algorithm in child mode, then calling isDefault on your property will not behave as you expect it to. Even if you have set the property, isDefault will return true.

Looking at the implementation:

      bool isDefault() const
      {
        return  m_initialWSName == m_workspaceName;
      }

It's using the workspace names for comparision. If the workspaces are outside the ADS, then their names are not set, and so you are comparing two empty strings (returns True).

Andrew Seel is after an option to fit directly in y-space, skipping the TOF conversion. More discussion with Andrew and Martyn about how this should be done is required.

Add the ability to plot a fitted output in Q or Q^2.

This test fails as the Tau spectrum has an artefact in it that is far enough out of the comparison tolerance to fail the test.

This is pretty much just a call to PlotPeakByLogValue anyway and a calculation of EISF which can be documented on the RST page for the interface if users ever want it.

If users want to do this type of fitting outside of the interface they would just use either the fit wizard or multi data fitting so trying to stuff this into an algorithm is pointless.

Only one input workspace specified
Logic Error in execution of algorithm MergeRuns
Only one input workspace specified

And the algorithm cannot be terminated.

I had originally assumed that this might allow me to merge multi period data without having to type the same workspace name 6 times.

Currently ConvFit works by knowing what fit functions are used and building menu options and composite functions based on that.

It would be nice if it could do this by inspecting the fit functions and adding/removing UI options as required and allowing the user to specify any of the quasielastic fit functions.

One notable exception would be the options for with one or two lorentzians.

In S(Q,w), if you plot the output as a spectra graph and have over a certain number of spectra, a dialogue appears to make sure you are certain. However, if you already have a spectra plot up that was created by a different algorithm, even if you click cancel, it will have already overwritten that graph with the newly calculated spectra plot. In this circumstance the dialogue is effectively useless.

To reproduce:

• Open Indirect > Data Reduction > S(Q, w)
• Load input file: irs26176_graphite002_red.nxs
• Q binning: 0.6, 0.1, 1.8
• Energy binning: -0.5, 0.05, 0.5
• Plot output = spectra
• Run with one Rebin type, leaving the spectra plot window up
• Run with other Rebin type, click cancel on dialogue and note the plot has changed anyway

From discussion with Saurabh Kabra.

Now #8760 has been done the next bigger task is to provide EnginX Python scripts that make external calls to GSAS, replicating existing typcial GSAS analysis on EnginX.

Note the main output of #8760 are two parameters Difc and Zero, which can be feed into GSAS input file. In addition from Mantid GSAS *.gss can be generated, and where necessary *.prm. Also, EnginX has a collection of GSAS phaseinformation (*.exp) files and GSAS sequence command files. The script will takes such inputs and returned a GSAS output that can be viewed with GSAS GUI.

Currently EnginX make calls to GSAS from OpenGenie scripts. Replicate these to python scripts that makes calls to GSAS.

For this ticket assume that GSAS is pre-installed on the computer. If the script detect that this is not the case then the user should be pointed at a web-site explaning how to install GSAS so that the script can be used.

These scripts may be located in ​https://github.com/mantidproject/mantid/tree/master/Code/Mantid/scripts/Engineering or some subfolder of ​https://github.com/mantidproject/scriptrepository

Current IDF file is a placeholder which isn't using correct values, it should be improved.

Only one IDF file/description for IMAT at present covering the 'small' instrument but there will need to be some description for the larger camera as well.

When entering a list of expectedPeaks into FitPeaks, if one expected peak is not there, the algorithm will stop and not produce any results. If just one peak is out of range of the data then this should be stated but otherwise ignored. If all expectedPeaks are not there then the algorithm should fail gracefully.

This affects EnginXCalibrate and CalibrateFull which both utilise FitPeaks.

As explained in ​http://trac.mantidproject.org/mantid/ticket/8172#comment:18, the LoadEventNexus algorithm class has several static methods that are used from other algorithms:

• LoadEventNexus::LoadEntryMetadata: used by LoadTOFRawNexus, LoadNexusMonitors
• LoadEventNexus::runLoadIDFFromNexus: used by LoadISISNexus2
• LoadEventNexus::runLoadInstrument: used by LoadTOFRawNexus, LoadPreNexus
• LoadEventNexus::runLoadNexusLogs: used by LoadTOFRawNexus

To re-use the already open NeXus file instead of re-opening it several times, these algorithms would need to be updated at once, so this was left out of ticket #8172.

In principle it should be possible to pass the (static) methods listed above a reference or pointer to the NeXus::File objects instead of/in addition to the file name.

Also, this use of static methods looks a bit suspicious and calling for maintenance trouble. Clarify and/or fix this issue.

Once a first version is available, the current code should be MVP-fied, and a battery of unit tests should be written before new features are added in.

getRemoteJobManager() is superseded by the RemoteJobManagerFactory (#11124).

When the remote algorithms are reorganized (#11126), FacilityInfo::getRemoteJobManager should not be needed any longer, and in general (I)RemoteJobManager should not be used in FacilityInfo.

Note: in #11126, rather than revamping the v1 remote algorithms breaking backwards compatibility, new version 2 remote algorithms have been introduced. Versions 1 still use getRemoteJobManager() and related chunks of code in FacilityInfo. So this ticket has to wait until the version 1 remove algorithms are removed (for which we could create a new ticket, or we could do it as part of this ticket).

Assertions commented out in SaveNXTomoTest.h to stop unit test failing due to #10519.

Lines: 105 and 153

With doxygen 1.8.7 I'm getting warnings about these two options, which are listed in Mantid.doxyfile but no value is assigned to them.

Just remove them to prevent possible future issues.

Kate Page was keen to see live data rolled out across more instruments at the SNS.

Save should store the structure and values of the fit function toolbar.

Load should restore them.

This will be the realisation of the design agreed in 10501.

For release 3.4 or later.

User request for both GUIs. It would be good to have an option to print out (possibly also filter) all log messages generated by the GUI, and show them in some kind of scrolling pane directly in the GUIs.

A couple weren't done during previous tickets

• ​DgsConvertToEnergyTransfer
• ​DgsDiagnose
• ​DgsPreprocessData
• ​DgsProcessDetectorVanadium

The command parsing could do with being more modular. Currently there's a big block of code that handles quite a lot of branching. When someone else comes to extend the syntax, it would be nicer if there were seams available to perform the extension. Even just calling some other functions for each operation would make it more readable.

Found when testing #7586

When loading a Mantid project where the active window is a matrix the top menu options usually associated with a metrix window (Matrix, Analysis, etc.) are not displayed.

The only way to gain access to them seems to be to switch to a window of a different type and switch back to the matrix or open a new matrix and immediately close it.

This can be reproduced by:

• Create a new workspace with a single matrix
• Save the project and close Mantid
• Open Mantid and load the project
• Notice that the matrix window is the active window within Mantid but the menu bar shows the default options

This was suggested by a user in the 3.2 release presentation.

When one or more algorithm properties are invalid, stars are placed next to them and clicking the "Run" button displays an error to the user. Instead the "Run" button should be disabled while any of its properties are invalid.

This issue was reported by Timothy Charlton. He's having Stitch1DMany output workspaces named Ws when he runs the script from #11390.

This bug was originally in #11429, but has been separated out into its own ticket (this one).

So far, this has not been reproduced. Awaiting further information / scripts to reproduce with.

This algorithm is shipped with Mantid, but does not have a test harness. All algorithms shipped with Mantid should undergo frequent automated testing.

Create a Unit test, or a system test, or both, to cover the functionality of this algorithm.

The isis refl gui works for some instruments where the instrument parameters and logs have been correctly setup. In theory, this workflow could be applied to a wider set of instruments. This can happen when:

• The new ReflGui is developed, because that has a column for overrides, so instrument parameters aren't strictly required. #8692
• The log values are abstracted in the same sort of way.
• The ReflGui uses ReflectometryReductionAuto and CreateTransmissionWorkspace for processing. For this to be realistic, we need the nested history problem to be sorted. #8913

Need input from instrument scientists. Need an agreed away to sum spectra to achieve a point detector. Max and Tim and Artur to agree this.

​https://github.com/aglavic/quicknxs/pull/5 introduces many comments annotating areas of the QuickNXS code that are troublesome for ISIS. These hardcoded values and strings need to be resolved before ISIS can begin to use QuickNXS.

There are three comments introduced:

• TODO MAGIC NUMBER - Highlights a hardcoded numbers
• TODO HARDCODED STRING - Highlights hardcoded strings
• TODO HARDCODED INSTRUMENT - Highlights hardcoded dependencies on an instrument

They should be easily findable using git grep. The goal of this ticket is to review each highlighted area and resolve it, until all of the TODO comments have been removed.

I won't have to use the slits left/right/top and bottom value any more but just the DAS hardware value of the opening for those slits.

The following are issues found while testing ticket #7404. Those issues are not related to the work of that ticket but should still be dealt with separately.

• Started the REFL Reduction UI and entered run 70977 in the Data Set Run number field.
• I then get the following:
  • The Y vs TOF (2D) button doesn't work and generates the following error:

    Traceback (most recent call last):
      File "/home/m2d/git/mantid_branch/Code/Mantid/scripts/Interface/reduction_gui/widgets/reflectometer/base_ref_reduction.py", line 937, in _plot_data_count_vs_tof_2d
        self.ref_det_view = mantidqtpython.MantidQt.RefDetectorViewer.RefMatrixWSImageView(ws_output_base, peak_min, peak_max, back_min, back_max, tof_min, tof_max)
    Exception: unknown
    

  • Clicking the TOF distribution button doesn't do anything (no errors reported either).
  • Unchecking the "Apply normalization" checkbox doesn't work, it still complains that I don't have a normalization run when I hit reduce.

    Error in execution of algorithm RefLReduction:
    RefLReduction: could not find run 0
    Add your data folder to your User Data Directories in the File menu
      at line 628 in '/home/m2d/git/mantid_branch/Code/Mantid/Framework/PythonInterface/plugins/algorithms/RefLReduction.py'
    RuntimeError: RefLReduction: could not find run 0
    Add your data folder to your User Data Directories in the File menu
      at line 628 in '/home/m2d/git/mantid_branch/Code/Mantid/Framework/PythonInterface/plugins/algorithms/RefLReduction.py'
      at line 41 in '<Interface>'
      caused by line 45 in '/home/m2d/mantid_build/branch/bin/mantidsimple.py'
    

• Reducing with either Background checkboxes checked off doesn't work.
• Reducing a second time after having reduced once doesn't seem to work. It returns immediately with the last result/error and doesn't try to re-run the whole thing.
• The sfcalculator UI has a lot of the same issues described above.

As requested by the Instrument Scientists, they want to be able to visualize and modify on the same plot, the peak and background of data and normalization. Also, the low-res plot will also be available in the same frame.

Parts of the ORNL reduction code for reflectometry is in LargeScaleStructure, and parts of it in scripts/reduction.

Since the reduction infrastructure in scripts/reduction uses the old python API, we should move the reflectometry code from that directory and put it with the rest of the code in LargeScaleStructure.

This can only be done once the reflectometry reduction and UI code has been moved to the python API v2 (tickets #7240 and #6577).

Since the reduction situation with REFL and REFM has evolved at SNS, it's not clear which reflectometry algorithm is actually used.

Someone needs to go through the following algorithms and decide whether they need to be removed:

1. RefLReduction.py (this is the main REFL reduction algorithm, but it hasn't been touched for 8 months. Is it still in use?)
2. RefReduction.cpp (removing this will also mean removing REFM from the reduction UI - an easy task)
3. RefRoi.cpp (this algorithm is called by RefReduction)
4. REFLReprocess.py (this algorithm was written to quickly re-reduce data files that have already been reduced. If that's not something that's used, this algorithm should probably go.)

If those algorithms are kept, they should be properly documented with an RST file and given usage examples as necessary.

There is help on how to document the algorithms in the following links: http://www.mantidproject.org/Algorithm_Documentation http://www.mantidproject.org/Algorithm_Usage_Examples And there are examples implemented for Fit, Load, LoadISISNexus and Rebin.

As an upgrade to the existing REF_L geometry switch to a RectangularDetector. An example for REF_M is below

<instrument xmlns="http://www.mantidproject.org/IDF/1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.mantidproject.org/IDF/1.0 Schema/IDFSchema.xsd" 
 name="REF_M" valid-from="1900-12-08 11:36:21.935542" 
                                             valid-to="2100-01-31 23:59:59"
                                             last-modified="2011-12-08 00:00:00">
  <defaults>
    <length unit="metre"/>
    <angle unit="degree"/>
    <reference-frame>
      <along-beam axis="z"/>
      <pointing-up axis="y"/>
      <handedness val="right"/>
    </reference-frame>
    <components-are-facing x="0.0" y="0.0" z="0.0" />
  </defaults>
  <!--SOURCE AND SAMPLE POSITION-->
  <component type="moderator">
    <location z="-18.703"/>
  </component>
  <type is="Source" name="moderator"/>
  <component type="sample-position">
    <location x="0.0" y="0.0" z="0.0"/>
  </component>
  <type is="SamplePos" name="sample-position">
    <cuboid is="sample-shape">
      <left-front-bottom-point x="-0.001" y="-0.01" z="-0.01"/>
      <left-front-top-point x="-0.001" y="0.01" z="-0.01"/>
      <left-back-bottom-point x="-0.001" y="-0.01" z="0.01"/>
      <right-front-bottom-point x="0.001" y="-0.01" z="-0.01"/>
    </cuboid>
    <algebra val="sample-shape"/>
  </type>
  <!--MONITORS-->
  <!--DETECTOR-->
  <component type="wire2d"  idstart="0" idfillbyfirst="y" idstepbyrow="256">
    <location r="2.5505" t="0." p="0." name="BNLDetector"/>
    <parameter name="t-position">
      <logfile id="DANGLE" extract-single-value-as="mean" eq="3.5-value"/>
    </parameter>
    <facing x="0.0" y="0.0" z="0.0"/>
  </component>
  <type name="wire2d" is="RectangularDetector" type="pixel" 
        xpixels="304" xstart="-0.1064" xstep="+0.0007"
        ypixels="256" ystart="-0.896" ystep="+0.0007" >
  </type>
  <type is="detector" name="pixel">
    <cuboid id="pixel-shape">
      <left-front-bottom-point x="-0.00035" y="-0.00035" z="-0.0005"/>
      <left-front-top-point x="-0.00035" y="0.00035" z="-0.0005"/>
      <left-back-bottom-point x="-0.00035" y="-0.00035" z="0.0005"/>
      <right-front-bottom-point x="0.00035" y="-0.00035" z="-0.0005"/>
    </cuboid>
    <algebra val="pixel-shape"/>
  </type>
</instrument>

At least for certain types of function attributes (integer, float) one is unable to set their values in the Fit Wizard of Mantidplot, or maybe it does allow setting but the set value is not displayed

(Originated from a suggestion by Douglas L. Abernathy)

The fitting range gets reset everytime a new fit is performed. This is the correct behaviour but very annoying if one wants to do various fitting within one project, since one is force to enter the numeric values every single time. An option to select enduring fitting ranges would increase the appeal of the Fit Wizard

(Originated from a suggestion by Douglas L. Abernathy)

This ticket covers the tasks of #8917 that have been moved to Release 3.3

This includes #9126 #9128 and #9190

ISIS instrument scientists use ​journal viewer to find information on their runs. I observed that the search results returned from the journal viewer are different from the results which can be found using Mantid's ICAT GUI for searching.

Example one

Searching on journal viewer

1. Go to the ​journal viewer website.
2. Click HTML for the MARI instrument (or click ​https://data.isis.rl.ac.uk/journals/ndxmari/journal_main.html)
3. From the from cycle(s) drop-menu select Current.
4. From the sorted by drop-menu select RB number and Ascending from the adjacent drop-menu.
5. Click the Refresh button.

You should now observe that there are nine proposals with the following IDs:

1010514;
1310471;
1320246;
1320539;
1410203;
1410359;
1410388;
1410550;
1410559;

Searching on ICAT

1. Open the ICAT GUI within Mantid.
2. Enter a start-date of 11/02/2014 and end-date of 04/04/2014 (according to the ​last cycle dates)
3. Click Search and observe that zero results are returned.
4. Perform the same searches on the ​ICAT web interface (TOPCAT)

Example two

1. Log into the Catalog in Mantid.
2. Enter 19247-19295 in the Run range field.
3. Click Search. 0 investigations are returned.

When performing the search on the journal viewer above the run range entered in the search relate to those specific runs.

Conclusion

The results that I get from Mantid are different from the data journal, which will prevent certain users from using ICAT within Mantid. This looks to be an ICAT specific issue, and I think may be related to permissions.

Other minor issues

1. Searching by cycle is a very convenient option that scientists would like.
2. Some investigations do not have run numbers in ICAT, but they do on the data journal.
3. There are occasions when a name appears in the run-range column rather than a run-range.

As suggested by Ron:

The script build.bat in UserAlgorithm requires that the user has opted to install the include files when installing mantid.

By default the includes are not added by default.

Let build.bat look to see if there is a MantidInstall\include directory. If not than let user know that for the build.bat to work the user needs to opt to install the include files.

If the following xml is present in a IDF parameter file:

<import name="some parameter file" />

then the parameter file specified (in the example above "some parameter file") must to loaded first (if it exist).

Further allow the user to only specify one <import> element. If a user has specified more than one, then only load one of these and display a warning message along the lines of "Only one <import> element is processed in a Parameter file......, see www.mantidproject.org/IDF"

Update www.mantidproject.org/IDF accordingly

Follow-on from #2504.

We should:

• Put in place a faster polling of the server (e.g. by using Poco methods just to see if a connection can be opened).
• When the server is down mark the tests as skipped rather than silently passing.
• (Also add this skipping to the LoadDAE test, which does nothing if not run at RAL.)
• Make sure CatalogDownloadDataFilesTest passes if the network is completely down.

Probably, when the SNS ICat server is fully operational these tests should point there when run at ORNL, and to the ISIS one otherwise. This should also speed them up.

There exists several instances of the older ICAT3 credentials in the unit tests of ​ICAT. These credentials ( ​these) are causing errors with the user office as reported by Hannah Griffin.

To address this issue, all occurences of the above username (mantid_test) & password (mantidtestuser) should be replaced with the new ICAT4 username & password. This ICAT4 credentials are already in some tests, and can be viewed (​here).

As the username/password will be public you must inform Tom who will update the user of ICAT such that it is only possible to log in with that account info from within RAL and ORNL. Having discussed this with Tom, he plans to use the IP addresses of these facilities to facilitate this.

In Add/remove curves dialog the new style setting works only for qtiplot lines. We should either disable the checkbox for mantid curves or make it work

I've found that the name attribute of the Detector ID column is saved as Dectector ID. This needs fixing.

Also check all the other columns and get unit test to check them all.

Ensure that params in IDF are used to set params in fit functions generated from hitting the 'Find Peaks' button.

Ensure that 'Find peaks' only find peaks within the area specified by the left/right vertical adjustable lines

See observations below.

First observation in MantidPlot:

1) use HRP39182.raw 2) add a BackToBackExponential function 3) Look at its parameters and note that e.g. the instrument parameters A and B parameters are tied to parameter values set in the IDF. 4) Hit the 'Find Peaks' button 5) This generates a list of BackToBackExponential function 6) HOWEVER, the A and B params of these functions does not appear to have be set from params in the in IDF!

Second observation:

1) Load focussedGEM38370_TOF.nxs 2) Use IkedaCarpenterPV function 3) When using the FindPeaks algorithms it appears to find peaks outside the area specified by the left/right vertical adjustable lines for selecting the fitting area

I find that when loading a large processed nexus file, the progress bar first goes from 0 to 100% as normal as it loads the data. Then it goes back to 0% and finishes about 40% to load sample and instrument information.

Ticket #2027 is reveals a use case where a user wants to create a workspace padded with trailing zeroes.

Supporting this in Mantid would require changes in the algorithms usede by the C++ code.

This ticket is help users remove trailing zeroes before creating a workspace. This could be documentation or perhaps python scripts.

For all the workflow diagrams a common legend might be useful. Make a diagram with all possible elements (algorithms, inputs, workspaces, decision blocks, etc) and link the image to all pages where there is a workflow diagram. Michael has added a few elements.

Nearly all the loaders how a runLoadInstrument methods which appart from in LoadEmptyInstrument does the same job. Consider created a helper class to put in API or elsewhere which can be accessed from the Nexus and DataHandling loaders and which has a common implementation of runLoadInstrument (other code which is replicated in the loaders may also be put in this helper class).

Note doing a search for runLoadInstrument gives the result:

  C:\Documents and Settings\ajm64\Desktop\Mantid\Code\Mantid\DataHandling\inc\MantidDataHandling\LoadCanSAS1D.h(88):      void runLoadInstrument(const std::string & inst_name, API::MatrixWorkspace_sptr localWorkspace);
  C:\Documents and Settings\ajm64\Desktop\Mantid\Code\Mantid\DataHandling\inc\MantidDataHandling\LoadDAE.h(94):      void runLoadInstrument(DataObjects::Workspace2D_sptr, const char* iName);
  C:\Documents and Settings\ajm64\Desktop\Mantid\Code\Mantid\DataHandling\inc\MantidDataHandling\LoadEmptyInstrument.h(75):      API::MatrixWorkspace_sptr runLoadInstrument();
  C:\Documents and Settings\ajm64\Desktop\Mantid\Code\Mantid\DataHandling\inc\MantidDataHandling\LoadEventPreNeXus.h(179):  void runLoadInstrument(const std::string &eventfilename, API::MatrixWorkspace_sptr localWorkspace);
  C:\Documents and Settings\ajm64\Desktop\Mantid\Code\Mantid\DataHandling\inc\MantidDataHandling\LoadPreNeXusMonitors.h(77):  void runLoadInstrument(const std::string& instrument, API::MatrixWorkspace_sptr localWorkspace);
  C:\Documents and Settings\ajm64\Desktop\Mantid\Code\Mantid\DataHandling\inc\MantidDataHandling\LoadRaw.h(86):      void runLoadInstrument(DataObjects::Workspace2D_sptr);
  C:\Documents and Settings\ajm64\Desktop\Mantid\Code\Mantid\DataHandling\inc\MantidDataHandling\LoadRaw.h(87):      void runLoadInstrumentFromRaw(DataObjects::Workspace2D_sptr);
  C:\Documents and Settings\ajm64\Desktop\Mantid\Code\Mantid\DataHandling\inc\MantidDataHandling\LoadRaw2.h(88):      void runLoadInstrument(DataObjects::Workspace2D_sptr);
  C:\Documents and Settings\ajm64\Desktop\Mantid\Code\Mantid\DataHandling\inc\MantidDataHandling\LoadRaw2.h(89):      void runLoadInstrumentFromRaw(DataObjects::Workspace2D_sptr);
  C:\Documents and Settings\ajm64\Desktop\Mantid\Code\Mantid\DataHandling\inc\MantidDataHandling\LoadRawHelper.h(102):      void runLoadInstrument(const std::string& fileName,DataObjects::Workspace2D_sptr);
  C:\Documents and Settings\ajm64\Desktop\Mantid\Code\Mantid\DataHandling\inc\MantidDataHandling\LoadRawHelper.h(105):      void runLoadInstrumentFromRaw(const std::string& fileName,DataObjects::Workspace2D_sptr);
  C:\Documents and Settings\ajm64\Desktop\Mantid\Code\Mantid\DataHandling\inc\MantidDataHandling\LoadSpice2D.h(76):      void runLoadInstrument(const std::string & inst_name,DataObjects::Workspace2D_sptr localWorkspace);
  C:\Documents and Settings\ajm64\Desktop\Mantid\Code\Mantid\DataHandling\src\LoadCanSAS1D.cpp(193):  runLoadInstrument(instname, dataWS);
  C:\Documents and Settings\ajm64\Desktop\Mantid\Code\Mantid\DataHandling\src\LoadCanSAS1D.cpp(233):void LoadCanSAS1D::runLoadInstrument(const std::string & inst_name,
  C:\Documents and Settings\ajm64\Desktop\Mantid\Code\Mantid\DataHandling\src\LoadDAE.cpp(366):          runLoadInstrument(localWorkspace, iName);
  C:\Documents and Settings\ajm64\Desktop\Mantid\Code\Mantid\DataHandling\src\LoadDAE.cpp(457):    void LoadDAE::runLoadInstrument(DataObjects::Workspace2D_sptr localWorkspace, const char* iName)
  C:\Documents and Settings\ajm64\Desktop\Mantid\Code\Mantid\DataHandling\src\LoadEmptyInstrument.cpp(61):      MatrixWorkspace_sptr ws = this->runLoadInstrument();
  C:\Documents and Settings\ajm64\Desktop\Mantid\Code\Mantid\DataHandling\src\LoadEmptyInstrument.cpp(114):    API::MatrixWorkspace_sptr LoadEmptyInstrument::runLoadInstrument()
  C:\Documents and Settings\ajm64\Desktop\Mantid\Code\Mantid\DataHandling\src\LoadEventPreNeXus.cpp(236):  this->runLoadInstrument(event_filename, localWorkspace);
  C:\Documents and Settings\ajm64\Desktop\Mantid\Code\Mantid\DataHandling\src\LoadEventPreNeXus.cpp(267):void LoadEventPreNeXus::runLoadInstrument(const std::string &eventfilename, MatrixWorkspace_sptr localWorkspace)
  C:\Documents and Settings\ajm64\Desktop\Mantid\Code\Mantid\DataHandling\src\LoadEventPreNeXus.cpp(316)://    runLoadInstrumentFromRaw(fileName,localWorkspace);
  C:\Documents and Settings\ajm64\Desktop\Mantid\Code\Mantid\DataHandling\src\LoadPreNeXusMonitors.cpp(227):  this->runLoadInstrument(instrumentName, localWorkspace);
  C:\Documents and Settings\ajm64\Desktop\Mantid\Code\Mantid\DataHandling\src\LoadPreNeXusMonitors.cpp(242):void LoadPreNeXusMonitors::runLoadInstrument(const std::string &instrument,
  C:\Documents and Settings\ajm64\Desktop\Mantid\Code\Mantid\DataHandling\src\LoadRaw.cpp(179):          runLoadInstrument(localWorkspace );
  C:\Documents and Settings\ajm64\Desktop\Mantid\Code\Mantid\DataHandling\src\LoadRaw.cpp(326):    void LoadRaw::runLoadInstrument(DataObjects::Workspace2D_sptr localWorkspace)
  C:\Documents and Settings\ajm64\Desktop\Mantid\Code\Mantid\DataHandling\src\LoadRaw.cpp(369):        runLoadInstrumentFromRaw(localWorkspace);
  C:\Documents and Settings\ajm64\Desktop\Mantid\Code\Mantid\DataHandling\src\LoadRaw.cpp(374):    void LoadRaw::runLoadInstrumentFromRaw(DataObjects::Workspace2D_sptr localWorkspace)
  C:\Documents and Settings\ajm64\Desktop\Mantid\Code\Mantid\DataHandling\src\LoadRaw2.cpp(155):        runLoadInstrument(localWorkspace );
  C:\Documents and Settings\ajm64\Desktop\Mantid\Code\Mantid\DataHandling\src\LoadRaw2.cpp(239):          runLoadInstrument(localWorkspace );
  C:\Documents and Settings\ajm64\Desktop\Mantid\Code\Mantid\DataHandling\src\LoadRaw2.cpp(356):    void LoadRaw2::runLoadInstrument(DataObjects::Workspace2D_sptr localWorkspace)
  C:\Documents and Settings\ajm64\Desktop\Mantid\Code\Mantid\DataHandling\src\LoadRaw2.cpp(403):        runLoadInstrumentFromRaw(localWorkspace);
  C:\Documents and Settings\ajm64\Desktop\Mantid\Code\Mantid\DataHandling\src\LoadRaw2.cpp(408):    void LoadRaw2::runLoadInstrumentFromRaw(DataObjects::Workspace2D_sptr localWorkspace)
  C:\Documents and Settings\ajm64\Desktop\Mantid\Code\Mantid\DataHandling\src\LoadRaw3.cpp(128):  runLoadInstrument(m_filename,localWorkspace);
  C:\Documents and Settings\ajm64\Desktop\Mantid\Code\Mantid\DataHandling\src\LoadRaw3.cpp(547):  runLoadInstrument(fileName,localWorkspace);
  C:\Documents and Settings\ajm64\Desktop\Mantid\Code\Mantid\DataHandling\src\LoadRawHelper.cpp(547):    void LoadRawHelper::runLoadInstrument(const std::string& fileName,DataObjects::Workspace2D_sptr localWorkspace)
  C:\Documents and Settings\ajm64\Desktop\Mantid\Code\Mantid\DataHandling\src\LoadRawHelper.cpp(584):        runLoadInstrumentFromRaw(fileName,localWorkspace);
  C:\Documents and Settings\ajm64\Desktop\Mantid\Code\Mantid\DataHandling\src\LoadRawHelper.cpp(600):    void LoadRawHelper::runLoadInstrumentFromRaw(const std::string& fileName,DataObjects::Workspace2D_sptr localWorkspace)
  C:\Documents and Settings\ajm64\Desktop\Mantid\Code\Mantid\DataHandling\src\LoadSpice2D.cpp(269):      runLoadInstrument(instrument, ws);
  C:\Documents and Settings\ajm64\Desktop\Mantid\Code\Mantid\DataHandling\src\LoadSpice2D.cpp(309):    void LoadSpice2D::runLoadInstrument(const std::string & inst_name,
  C:\Documents and Settings\ajm64\Desktop\Mantid\Code\Mantid\Nexus\inc\MantidNexus\LoadISISNexus.h(100):            void runLoadInstrument(DataObjects::Workspace2D_sptr);
  C:\Documents and Settings\ajm64\Desktop\Mantid\Code\Mantid\Nexus\inc\MantidNexus\LoadISISNexus2.h(84):      void runLoadInstrument(DataObjects::Workspace2D_sptr);
  C:\Documents and Settings\ajm64\Desktop\Mantid\Code\Mantid\Nexus\inc\MantidNexus\LoadMuonNexus.h(81):      void runLoadInstrument(DataObjects::Workspace2D_sptr);
  C:\Documents and Settings\ajm64\Desktop\Mantid\Code\Mantid\Nexus\inc\MantidNexus\LoadMuonNexus.h(115):      void runLoadInstrumentFromNexus(DataObjects::Workspace2D_sptr);
  C:\Documents and Settings\ajm64\Desktop\Mantid\Code\Mantid\Nexus\inc\MantidNexus\LoadMuonNexus2.h(81):      //void runLoadInstrument(API::MatrixWorkspace_sptr localWorkspace);
  C:\Documents and Settings\ajm64\Desktop\Mantid\Code\Mantid\Nexus\inc\MantidNexus\LoadNexusMonitors.h(68):    void runLoadInstrument(const std::string& instrument,
  C:\Documents and Settings\ajm64\Desktop\Mantid\Code\Mantid\Nexus\inc\MantidNexus\LoadNexusProcessed.h(99):      void runLoadInstrument(const std::string & inst_name, DataObjects::Workspace2D_sptr local_workspace);
  C:\Documents and Settings\ajm64\Desktop\Mantid\Code\Mantid\Nexus\inc\MantidNexus\LoadSNSEventNexus.h(109):      void runLoadInstrument(const std::string &nexusfilename, API::MatrixWorkspace_sptr localWorkspace);
  C:\Documents and Settings\ajm64\Desktop\Mantid\Code\Mantid\Nexus\inc\MantidNexus\LoadTOFRawNeXus.h(90):  void runLoadInstrument(DataObjects::Workspace2D_sptr);
  C:\Documents and Settings\ajm64\Desktop\Mantid\Code\Mantid\Nexus\src\LoadISISNexus.cpp(164):            runLoadInstrument(localWorkspace );
  C:\Documents and Settings\ajm64\Desktop\Mantid\Code\Mantid\Nexus\src\LoadISISNexus.cpp(173):          runLoadInstrument(localWorkspace );
  C:\Documents and Settings\ajm64\Desktop\Mantid\Code\Mantid\Nexus\src\LoadISISNexus.cpp(471):    void LoadISISNexus::runLoadInstrument(DataObjects::Workspace2D_sptr localWorkspace)
  C:\Documents and Settings\ajm64\Desktop\Mantid\Code\Mantid\Nexus\src\LoadISISNexus.cpp(515):      //    runLoadInstrumentFromNexus(localWorkspace);
  C:\Documents and Settings\ajm64\Desktop\Mantid\Code\Mantid\Nexus\src\LoadISISNexus2.cpp(202):      runLoadInstrument(local_workspace);
  C:\Documents and Settings\ajm64\Desktop\Mantid\Code\Mantid\Nexus\src\LoadISISNexus2.cpp(515):    void LoadISISNexus2::runLoadInstrument(DataObjects::Workspace2D_sptr localWorkspace)
  C:\Documents and Settings\ajm64\Desktop\Mantid\Code\Mantid\Nexus\src\LoadISISNexus2.cpp(559):      //    runLoadInstrumentFromNexus(localWorkspace);
  C:\Documents and Settings\ajm64\Desktop\Mantid\Code\Mantid\Nexus\src\LoadMuonNexus.cpp(180):            runLoadInstrument(localWorkspace );
  C:\Documents and Settings\ajm64\Desktop\Mantid\Code\Mantid\Nexus\src\LoadMuonNexus.cpp(188):          runLoadInstrument(localWorkspace );
  C:\Documents and Settings\ajm64\Desktop\Mantid\Code\Mantid\Nexus\src\LoadMuonNexus.cpp(454):    void LoadMuonNexus::runLoadInstrument(DataObjects::Workspace2D_sptr localWorkspace)
  C:\Documents and Settings\ajm64\Desktop\Mantid\Code\Mantid\Nexus\src\LoadMuonNexus.cpp(497):        runLoadInstrumentFromNexus(localWorkspace);
  C:\Documents and Settings\ajm64\Desktop\Mantid\Code\Mantid\Nexus\src\LoadMuonNexus.cpp(502):    void LoadMuonNexus::runLoadInstrumentFromNexus(DataObjects::Workspace2D_sptr localWorkspace)
  C:\Documents and Settings\ajm64\Desktop\Mantid\Code\Mantid\Nexus\src\LoadMuonNexus2.cpp(175):          runLoadInstrument(localWorkspace );
  C:\Documents and Settings\ajm64\Desktop\Mantid\Code\Mantid\Nexus\src\LoadNexusMonitors.cpp(161):  this->runLoadInstrument(instrumentName, this->WS);
  C:\Documents and Settings\ajm64\Desktop\Mantid\Code\Mantid\Nexus\src\LoadNexusMonitors.cpp(174):void LoadNexusMonitors::runLoadInstrument(const std::string &instrument,
  C:\Documents and Settings\ajm64\Desktop\Mantid\Code\Mantid\Nexus\src\LoadNexusProcessed.cpp(435):  runLoadInstrument(instname, local_workspace);
  C:\Documents and Settings\ajm64\Desktop\Mantid\Code\Mantid\Nexus\src\LoadNexusProcessed.cpp(981):void LoadNexusProcessed::runLoadInstrument(const std::string & inst_name,
  C:\Documents and Settings\ajm64\Desktop\Mantid\Code\Mantid\Nexus\src\LoadSNSEventNexus.cpp(163):  runLoadInstrument(m_filename, WS);
  C:\Documents and Settings\ajm64\Desktop\Mantid\Code\Mantid\Nexus\src\LoadSNSEventNexus.cpp(532):void LoadSNSEventNexus::runLoadInstrument(const std::string &nexusfilename, MatrixWorkspace_sptr localWorkspace)

Implement a fall-back solution for when information from ICAT is not available. Currently autoreduction fails if ICAT information cannot be retrieved.

Option to disable web interface during maintenance. I.e. user can't rerun jobs (or run passed jobs)

Have this option combined with displaying a message, notification on the WebApp

Currently data is stored in directory /instName/CYCLENAME/autoreduced/rbnumber/runnumber/results

The excitations group would rather have their data stored with all runs in the same rbnumber folder, so no runnumber or results folder.

Additionally they would like the relevant logs stored there.

When staff/admin is logged in they will only see staff only notifications and not the standard public ones.

Instead of just saying 'processing' on the status page for when data is being reduced/sent to data server, 'processing' should be used for when it is being reduced, and 'saving' for when it is being sent.

Follow the README.md in ​https://github.com/mantidproject/autoreduce/tree/master/ISISPostProcessRPM to setup a worker + activemq and run the test specified

Update the documentation where not clear or out of date.

Test this on a different computer from the production server.

New RHEL and windows servers have been requested from the service desk. They need to be set up with the autoreduction environment.

At present activemq lives on the same machine that will be the worker machine for this coming cycle.

activemq will take up an unknown amount of resources on this machine, and resource requirements will only go up, e.g. with IMAT.

This ticket is to separate out activemq on a separate server, this should also help with diagnosing an activemq hardware issue from a worker hardware issue.

This ticket may be done in more than one ticket.

Steps to take:

• Read up on best practice on activemq versus it's hardware requirements, and note SNS has now a number of years experience with activemq

• ISIS are currently using activemq 5.8, it is time for an upgrade?

• Request facility IT for server instance

• Split the activemq documentation out of ​https://github.com/mantidproject/autoreduce/blob/master/ISISPostProcessRPM/README.md into separate activemqSetup.md documentation file

• Likely after this coming cycle introduce this server into production

Jobs coming off the instrument should be set as top priority, and any jobs for previous cycles should be able to be set to a lower priority.

Currently in autoreduction, jobs can be rerun only one at a time. Users would like to be able to rerun jobs in batches for convenience.

Currently backed up as part of the Window server VM backup, but if the database itself becomes corrupt then we lose data.

Marcus suggested we could e.g. periodically dump out mysql files for backup.

This ticket is to back up the database in e.g. this way

Currently, even if the default in the reduce_vars.py script is an empty string, if entering variables through the GUI a value is required, and the reduction will not proceed otherwise. Change this so the entry system is more flexible. Ideally both the box can be left blank, or 'none' can be entered.

Currently when specifying an additional save location in the reduce.py script, it will blindly save to that exact location. Ideally it would save in an generic way similar to archive/ceph saving eg. '/userdirectory/data/inst$/rb$/run$' rather than just in the '/userdirectory/data/' directory.

Currently when a run fails, it shows as a notification stating just the run number. It would be useful if it gave more information ie the Instrument name, and perhaps RB Number.

Additionally it would be useful if deleting said notifications were made easier and could be done all at once.

It may be that not all runs need reducing.

It may be nice to provide the ability to specify run numbers to skip.

If many runs have run with the wrong reduction variables its could be laborious to go through each one and re-run them with the correct variables.

It would be nice to be able to perform a batch re-run by selecting all desired runs and then entering the variables once.

Considerations needs to be made to prevent this monopolising the systems time and resources. (Possible a priority option?)

​http://activemq.apache.org/how-can-i-support-priority-queues.html

If priority queues are used there may need to be changes made to how the messages are consumed.

Currently it is possible for a run to fail without its status being set to 'Error'.

Known situations:

• Unable to access the network path
• Autoreduction queueProcessor is killed while its running.

Currently the status page on the autoreduction webpage (eg ​http://reduce.isis.cclrc.ac.uk/runs/queue/) needs to be manually refreshed to see whether data has changed from queued to processing. Would be of benefit to users if it automatically refreshed.

Currently when setting the 'help' info for variable x, special characters such as '\n' and '\t' are not taken into consideration. If they were, the help messages would look more appealing to users.

To prevent hammering ICAT too often with the same query (if a user is associated with an instrument etc.) it would be best if it could be stored in some sort of cache that expires after, say, 1 hour.

The cache should be able to store something similar to:

{
  "user" : 123,
  "instruments" : ["ins1", "ins2"],
  "last_checked" : "2014-01-01 12:20"
}

The cache should intercept the call to the ICAT helper and only proceed through if the cached values are too old or not found.

Update: Not sure yet if this is needed or not. Will reassess once page logic is in place.

Improve the variables regex to handle dictionaries where the closing '}' is on the same line as the final variable.

for speed on limited laptops

This is a specific implementation for C2E in the first case.

This has been raised by Rob (cc'd). The versions of Numpy that we use are quite different. This makes saving numpy arrays and reloading them on different platforms impossible.

Looks like we get/use the following versions on platforms I've looked at so far: 1.6.1 Mountain Lion 1.6.2 Windows 7 x64 1.4.1 RHEL6

A standardised Numpy version would probably solve the issue that Rob is experiencing. Not sure what the wider caveats of this will be. Could we do something about this for release 3.0?

Umbrella ticket for plotting improvements

• Fitting plots: Residuals should be underneath data - See #3671
• Better defaults on contour plots based on inspecting data.
• Shifting curves by arbitrary amounts to see overlayed peaks (convert to waterfall plot?) See #11559
• Generate script or commands to reproduce current plot
• Changing horizontal axis from Q->Q2 (square and cube axis scaling)
• Support other relation units (to the current unit) there are indirect examples.
• Saving project can somtimes miss plot settings (validation and fix)

​http://ipython.org/ipython-doc/stable/interactive/public_server.html

Questions:

1. Given a collection of ELNs, are/can they be searchable?
2. Can graphs be interactive, zoomable?
3. Can we get input to the notebook from instrument control, etc

Leighton Coates has an example where ConvertToMD is extremely slow. This needs profiling to understand why.

The INES instrument at ISIS have 164 spectra with the monitors defines as 145-148. LoadISISNexus assumes that monitors occur in blocks at the start or end of the detector list and so loads the data incorrectly. Any of the INS nxs files will show this problem

Basically this means that you can't use a pointer to a WorkspaceGroup in a child algorithms the WorkspaceProperty won't accept it.

Sample code that won't work:

    Mantid::API::FrameworkManager::Instance().exec("Load", 4, "Filename", "CSP79590.raw", "OutputWorkspace", "test_ws");

    auto ws = Mantid::API::AnalysisDataService::Instance().retrieveWS<Mantid::API::Workspace>("test_ws");

    Mantid::API::IAlgorithm * alg = Mantid::API::FrameworkManager::Instance().createAlgorithm("Scale");
    alg->initialize();
    alg->setChild(true);
    alg->setProperty("InputWorkspace",ws);
    alg->setPropertyValue("OutputWorkspace","__anonymous");
    alg->execute();

The problem lies with the WorkspaceProperty around these lines (253-261):

            try 
            {
              wksp = AnalysisDataService::Instance().retrieve(m_workspaceName);
            }
            catch( Kernel::Exception::NotFoundError &)
            {
              // Check to see if the workspace is not logged with the ADS because it is optional.
              return isOptionalWs();
            }

They correctly check for a group but the only way to satisfy the property is to have a string value, which it won't have if its been set by pointer.

Doing the following: Load a Python algorithm into the Scripting Console (or write a new one) Execute it - it installs in the Algorithms list Run that algorithm which produces a Workspace Right-click on the workspace - History - copy to Clipboard Open a new tab in the Scripting console Paste Execute All

• there's an error, the name of my new script is not recognised.

This works properly (of course) if the Algorithm is one of Mantid's standard ones, and also if it's my own algorithm loaded on start-up (but see other bug report for doing that).

(Mantid 2.4)

James Lord.

From James Lord:

(a) trying to copy error messages, etc out of the Results Log window. I select the text and either do ctrl-C or Edit-Copy Selected. I get an error (image attached)

I don't know if it is possible to show this with mantid script, but, consider this unit test for CheckWorkspaceMatch where I create a workspace, save it, and them, load it again, to give to the CheckWorkspaceMatch. It complains that the instrument has different name.

In another ticket I'm working with, there is a complain about the sample name mismatch. Because, one is empty (before saving workspace) and the other is a single space (after reloading).

For this reason, we are forced to disable some tests in the systemtests, but, as a side effect, I had problems with not loading sample correctly.

While testing #9137 it became apparent that it took too long a time to populate the Load dialog (about 20 seconds). A quick look at the stack trace in debug seems to indicate it is spending a long time walking the tree hierarchy with NeXus.

This needs to be investigated and fixed. The test file is noted in the description on #9137

Currently the track interception methods contain some magic values that used to shift points, i.e. in the Object::calcValidType method

const Geometry::V3D shift(uVec*Surface::getSurfaceTolerance()*25.0);

The value of 25 seems arbitrary and shouldn't need to be this large, a value of just over 1 should suffice.

The interception methods are rather sensitive to these values a review of this code is necessary to improve their accuracy.

The algorithm as it currently stand is not very useable. The main problem is that it both loads information from the raw file and adjusts the X bins meaning that it has to appear in a very odd place in conversion scripts.

It's functionality should be changed to simply load the raw file information in to the parameter map. This way the load step in the inelastic scripts can be isolated properly.

The offset information can then be used at the most appropriate point in a script by either a modified existing algorithm or by a new algorithm.

My suggestion would be a modification to ChangeBinOffset so that it has an option to correct the X data for the efficiency information that may have been loaded.

What would be nice as well would be to change the way that the algorithm loads the parameters. Most of the time the numbers are identical for each detector and currently we store an entry in the parameter map for each one. It would be more efficient to have an instrument wide parameter set to the first value in the list within the raw file and then only set detector level ones that are different.