mantidproject / mantid Goto Github PK

For storing meeting minutes into the SVN repository

Original Reporter: Russell Taylor

Add a method to Workspace2D to retriece the number of Histogram1D’s stored in it.

Original Reporter: @FreddieAkeroyd

Add in the code used to build an ISIS converter for Gaudi

The algorithm converts all of the tof axes in a 2D workspace to there wavelength values.

The algorithm is
wavelength = m,,n,, \* (d1+d2)/tof

where
m,,n,, is the mass of a neutron (this should be in a constants class
d1 is the distance from the source to the sample
d2 is the distance from the sample to the detector
tof is the time of flight value.

We should use the std::franform function for efficiency

Chane all of the classes to use two part Namespaces
- Mantid::Kernel
- Mantid::Algorithm
- Mantid::DataHandling
- etc

At the same time alter the DEF symbols for each .h file to include the namespace
eg.
#ifndef MANTID_KERNEL_FRAMEWORKMANAGER_H_[[BR]]
#define MANTID_KERNEL_FRAMEWORKMANAGER_H_

Create an integration algorithm for the GAUDI framework,

This should produce a single count number for each detector.

The result will need to be stored in a suitable DataObject in the TDS.

Talk to Anders to ensure that your algorithms are comparable.

Keywords: GAUDI, Algorithm

Based on the workspace class.

This will need to store a 1D array
e.g. detector number against value (double)
and associated error information??

Import as required from Gaudi

On the algorithm base class we will have to consider the interface as in GAUDI the execution was never public. For Mantid it will be.

Gaudi had
sysInitialise calls Initialise
sysExecute calls Execute
etc.

We will probably need
Initialise calls a private init
Execute calls a private exec
etc

Original Reporter: Russell Taylor

Issue details are blank in trac

Develop geometry objects sufficient to support the definition of an instrument and suffiecient operation to allow the distances and angles to be calculated between any two objects.

It will need to be able to search for a detector by detector number.

Original Reporter: @FreddieAkeroyd

Issue details are blank in trac

This should be an implementation of the DynamicFactory base factory class.

Talk to Russell and use his examples for file and method header comments and style.

Understand the CMT tool used in GAUDI build management and post a page on the wiki of the findings. Particularly how to improve the speed of repeated debug compile cycles.

Keywords: CMT, GAUDI

We currently have several Factories within Mantid (and this may grow further).
- AlgorithmFactory (serves instances)
- WorkspaceFactory (serves instances)
- ServiceFactory (serves singletons)

The common factors of these algorithms should be refactored out to an object factory that the specific factories inherit from.

The message service should not be imported straight from GAUDI.
It should be reimplmented using the C++ port of Log4J (the most common logging component around).
Log4Cxx is hosted by apache and there is some documentation on their site, also most of the Java documentation will apply.

There may be a need to change the messageService interface and we will have to discuss this.

Original Reporter: Russell Taylor

Issue details are blank in trac

Create a converter capable of saving the results of the Integration algorithm to disk.

I suggest a simple tab separated text file format.

Detector No \t Count

You will need to speak to Dickon to get info about the DataObject

Keywords: GAUDI, Converter

Issue details are blank in trac

Look into how python code can be used with GAUDI.
Investigate the options for using python to run the GAUDI framework interactively.

Create a python algorithm, look into using services creating and storing dataobjects on the TDS.
Extracting data objects from the TDS both during and lagorithms and after.

Add an AlgorithmManager class that inherits from AlgorithmFactory.
The job of this class is to
- provide a facade for the factory (code should not call the Factory Direct)
- To maintain a list of all the algorithms that have been served out of the factory to allow the proper finilization and destruction.
- You may want to implement this as an instance of a DataService

This will use BOOST.Python (and possibly the py++ code generatot to make things simpler).

The primary objects that will be exposed through the interface are
- The FrameworkManager
- The base Aglorithm Class
- The base worksspace
- Probably the workspace implementations.

Original Reporter: Russell Taylor

Add the Eclipse-generated makefile structure to the repository, along with a script to run the unit tests.

Create a simple converter class to read a text file into an object in the TDS.

The EvtCols example in GAUDI appears to perform both read and write functionality.
Although this may not be too helpful.

Keywords: GAUDI, Converter

As agreed and defined here http://www.mantidproject.org/Coding_Standards

Create a data handling command capable of saving to a (comman, tab, user specified) seperated file the contents for a workspace.

Create a converter capable of reading a RAW file and entering the file into an object in the TDS.

Keywords: GAUDI, Converter

Please take a look at CruiseControl and LuntBuild to see how well they will integrate into building C++.

Create an integration algorithm for the LOQ framework,

This should produce a single count number for each detector.

The result will need to be outputted into a text file, I suggest a simple tab separated text format.

Detector No \t Counts

Talk to Dickon to ensure that your algorithms are comparable.

Create a DataObject for storing a Raw file of histograms and errors into the TDS.

Keywords: GAUDI, dataobject

Create a PluginManager to allow the loading of shared libraries at run time.
This will require conditional comiplation as the required calls are OS specific.

Look at the following in GAUDI for inspiration
DLLClassManager (in GAUDIsvc)
and
System (in GAUDIKernel) where the real code calls are hidden.

The ADD explains how I want the plug in to work http://svn.mantidproject.org/mantid/trunk/Documents/Design/Architecture%20Design%20Document.doc

As agreed and defined here http://www.mantidproject.org/Coding_Standards

Original Reporter: Russell Taylor

Issue details are blank in trac

Issue details are blank in trac

This will include getting some of the required parts of Boost.python and python itself brought into ThirdParty.

Original Reporter: Russell Taylor

Issue details are blank in trac

Create a concrete implmentation for a 2D workspace, inheriting from the Workspace class.

This will need to store
Neutron counts (double) against time bins and detector number
Also the values of the time bins will need to be recorded

Error information will need to be stored in another array.

As agreed and defined here http://www.mantidproject.org/Coding_Standards

This should initially contain

void initialise()
- to create all of the required services etc
Algorithm createAlgorithm (string algName)
- use the algorithm factory to create an instance of an algorithm
Algorithm createAlgorithm (string algorithm, string[] properties)
- as above but use the array of strings to set algorithm properties
Algorithm exec(string algorithm, string[] properties)
- as above but also execute the algorithm
Workspace getWorkspace (string wsName)
- returns a shared pointer to the workspace requested

All of these need to throw realistic exceptions for error cases.

There is an available PC by my desk that should be suitable for this.

We should use LINUX (fedora or enterprise) for now.
We should install a continuous integration environment eg. cruisecontrol or luntbuild.
This will spot checkings to subversion and initiate a build.

The underlying compiler shoud be gcc, but the choice of build tools is flexible at the momnet, but we should aim for the same build mechanism to the available for the developers to use locally as well.

At the end of the build the unit tests need to be performed.

Should we consider SCons?

As dicussed in the design meeting 10/09/2007

Code
Mantid
—Kernel
--(repeated under each directory at this level)
—doc
--inc
—src
--test
—Services
—Algorithms
—DataHandling
—DataObjects

As agreed and defined here http://www.mantidproject.org/Coding_Standards

The history needs to contain several sections.
1. An environment sections containing
1. The version of Mantid
2. The OS name and version
3. The user name
2. The algorithm History of a workspace (i.e. for every algorithm that has been run on this workspace of it’s parents).
1. The name and version of the algorithm
2. The date and time applied
3. The values of every alogirthm property
4. How long the algorithm took to run

The majority of the History data filling can take place in the Workspace Factory.
If we change the main factory method to take (string workspaceType, Workspace parentWorkspace, algorithm currentAlgorithm) then the workspace would have all of the info required to.
1. Copy all of the History from the parentWorkspace to the new one
2. Create a new algorithm History record from the current Algorithm

We may need to think later about how we handle branched histories.
eg.
WS1 = LoadRaw(“file1”)
WS2 = LoadRaw(“Vanadium2”)
WS3 = WS1/WS2
At this point WS3 would need to contain the history of both WS1 and WS2

Keywords: History

Issue details are blank in trac

The same algorithm as was created for the GAUDI pilot, but this time reading a 2D workspace from the Analysis Data Service, recoring the result in a 1D workspace.

Consider what types of files we need to create a suitable test set of data files.

Select an example file for each category and post a page on the wiki with the files and how to get them.

This will be useful both for the pilots and for standard test files well beyond then.

At the meeting I suggested a simplistic set based solely on size (small, medium, Large). It was suggested that file differ somewhat across the different instruments and that we may want a file that is large in terms of detectors and another which is large in terms of time channels.

Keywords: Test Data

Create a Data handling command to load a specified RAW file and populate a 2D workspace.

Look at how this was done in the ISIS converter we wrote for GAUDI.

Issue details are blank in trac

Investigate the use of FORTAN within the GAUDI framework.
Look at wrapping fortran code within a GAUDI algoritm.
Investigate issues such as accessing the data stores, creating and using data objects and passing these over to the TDS. Also look at any issues about accessing the other services.

This will need to provide an abstract iterator for accessing the data in the workspace (which will be provided in the concrete implementation).

Also stub properties for accessing

Detector

Sample

History

and SampleEnvironment data will be required.

Original Reporter: Russell Taylor

Issue details are blank in trac