diff --git a/Code/Mantid/docs/source/concepts/Algorithm.rst b/Code/Mantid/docs/source/concepts/Algorithm.rst
index 15613d8674ddd988063dd09372b179b23a6c0988..4c36f735d19201ce706939f0c4cdd8374494def9 100644
--- a/Code/Mantid/docs/source/concepts/Algorithm.rst
+++ b/Code/Mantid/docs/source/concepts/Algorithm.rst
@@ -8,10 +8,10 @@ What are they?
Algorithms are the verbs of Mantid. They are the actors. If you want to
manipulate your data in any way it will be done through an algorithm.
-Algorithms operate primarily on data in `workspaces <Workspace>`__. They
-will normally take one or more `workspaces <Workspace>`__ as an input,
+Algorithms operate primarily on data in :ref:`workspaces <Workspace>`. They
+will normally take one or more :ref:`workspaces <Workspace>` as an input,
perform some processing on them and provide an output as another
-`workspace <Workspace>`__ (although it is possible to have multiple
+:ref:`workspace <Workspace>` (although it is possible to have multiple
outputs).
Categories, Name and Versions
@@ -27,8 +27,7 @@ A category is a group of algorithms that have some connection in their
usage. This is primarily used to make the list of algorithms easier to
work with in graphical user interfaces. Example categories include,
DataHandling, Diffraction, Muon, Workflow and are currently
-subcategories of
-`Algorithms <http://docs.mantidproject.org/algorithms>`__ category.
+subcategories of Algorithms category.
Name
~~~~
@@ -52,7 +51,7 @@ Parameters
----------
Each algorithm will have one or more parameters, known within Mantid as
-`properties <properties>`__, that will control how it performs its
+:ref:`properties <properties>`, that will control how it performs its
processing. These parameters specify both what the inputs and outputs of
the algorithm will be as well any other options that alter the
processing.
@@ -66,10 +65,6 @@ Usage
From MantidScript(Python)
^^^^^^^^^^^^^^^^^^^^^^^^^
-.. raw:: html
-
- <div style="border:1pt dashed blue; background:#f9f9f9;padding: 1em 0;">
-
.. code:: python
# where p1,p2 & p3 are values for algorithm "Alg"'s properties
@@ -89,9 +84,6 @@ From MantidScript(Python)
print alg["Property2"]
# prints 'p2', etc
-.. raw:: html
-
- </div>
Using the C++ API
^^^^^^^^^^^^^^^^^
@@ -99,10 +91,6 @@ Using the C++ API
(for algorithm "Alg" having properties InputWorkspace, OutputWorkspace &
prop)
-.. raw:: html
-
- <div style="border:1pt dashed blue; background:#f9f9f9;padding: 1em 0;">
-
.. code:: cpp
// Explicitly setting the parameters and then executing
@@ -117,35 +105,29 @@ prop)
API::FrameworkManager::Instance().exec("Alg","InWS,OutWS,aValue");
API::Workspace* ws = API::FrameworkManager::Instance().getWorkspace("OutWS");
-.. raw:: html
-
- </div>
Example Algorithms
------------------
-- `Plus <http://docs.mantidproject.org/nightly/algorithms/Plus.html>`__
- - An algorithm for adding data in two `workspaces <Workspace>`__
+- :ref:`Plus <algm-Plus>`
+ - An algorithm for adding data in two :ref:`workspaces <Workspace>`
together
-- `Rebin <http://docs.mantidproject.org/nightly/algorithms/Rebin.html>`__
+- :ref:`Rebin <algm-Rebin>`
- An algorithm for altering the binning of the data in a
- `workspace <Workspace>`__.
-- `LoadRaw <http://docs.mantidproject.org/nightly/algorithms/LoadRaw.html>`__
+ :ref:`workspace <Workspace>`.
+- :ref:`LoadRaw <algm-LoadRaw>`
- An algorithm for loading the data from a RAW file into a
- `workspace <Workspace>`__.
-- `GroupDetectors <http://docs.mantidproject.org/nightly/algorithms/GroupDetectors.html>`__
+ :ref:`workspace <Workspace>`.
+- :ref:`GroupDetectors <algm-GroupDetectors>`
- An algorithm for grouping two or more detectors into a larger
'logical' detector.
-A full list of algorithms is avilable
-`here <http://docs.mantidproject.org/nightly/algorithms/index.html>`__
-category
Writing your own algorithm
--------------------------
-A primer for this is `here <Writing an Algorithm>`__. Also look at the
-examples in the `UserAlgorithms <UserAlgorithms>`__ directory of your
+A primer for this is `here <http://www.mantidproject.org/Writing_an_Algorithm>`__. Also look at the
+examples in the :ref:`UserAlgorithms <UserAlgorithms>` directory of your
Mantid installation.
diff --git a/Code/Mantid/docs/source/concepts/Analysis_Data_Service.rst b/Code/Mantid/docs/source/concepts/Analysis_Data_Service.rst
index f219bd05b5f373ab8af3b524f31df994703a47cf..25c0cbd1e240b1f0262d3cb300be47112d59852e 100644
--- a/Code/Mantid/docs/source/concepts/Analysis_Data_Service.rst
+++ b/Code/Mantid/docs/source/concepts/Analysis_Data_Service.rst
@@ -1,14 +1,14 @@
.. _Analysis Data Service:
-Analysis_Data_Service
+Analysis Data Service
=====================
What is it?
-----------
-The Analysis Data Service is a `Data Service <Data Service>`__ that is
-specialized to hold all of the `workspaces <Workspace>`__ that are
-created by user run `algorithms <Algorithm>`__. Whenever an algorithm is
+The Analysis Data Service is a :ref:`Data Service <Data Service>` that is
+specialized to hold all of the :ref:`workspaces <Workspace>` that are
+created by user run :ref:`algorithms <Algorithm>`. Whenever an algorithm is
executed it automatically extracts its input workspaces from the
Analysis Data Service, and inserts its output workspaces upon
completion.
@@ -16,18 +16,18 @@ completion.
Extracting a workspace from the Analysis Data Service
-----------------------------------------------------
-The most usual way in user code would be to use the `Framework
-Manager <Framework Manager>`__.
+The most usual way in user code would be to use the :ref:`Framework
+Manager <Framework Manager>`.
``Workspace* result = FrameworkManager::Instance().getWorkspace("workspaceName")``
-Or you could get it directly from the AnalysisDataService (as a `Shared
-Pointer <Shared Pointer>`__)
+Or you could get it directly from the AnalysisDataService (as a :ref:`Shared
+Pointer <Shared Pointer>`)
``Workspace_sptr result = AnalysisDataService::Instance().retrieve("test_out1");``
If you were writing an algorithm however you would most likely use a
-Workspace `Property <Properties>`__ to access or store your workspaces.
+Workspace :ref:`Property <Properties>` to access or store your workspaces.
diff --git a/Code/Mantid/docs/source/concepts/Create_an_IDF.rst b/Code/Mantid/docs/source/concepts/Create_an_IDF.rst
new file mode 100644
index 0000000000000000000000000000000000000000..4799a47a6b3db1555da9b538dd5dc2d0e49858b9
--- /dev/null
+++ b/Code/Mantid/docs/source/concepts/Create_an_IDF.rst
@@ -0,0 +1,48 @@
+.. _Create_an_IDF:
+
+Create an IDF
+=============
+
+This page will help you get started with making an instrument definition file. For documentation on individual elements of an IDF refer to the :ref:`IDF documentation <InstrumentDefinitionFile>`
+
+Basic Steps
+-----------
+
+The best way to get started is to:
+
+- `Set up an editor for XML that uses schema validation <http://www.mantidproject.org/Using_XML_Schema>`__
+- Read the :ref:`introduction to IDFs <InstrumentDefinitionFile>`
+- Read the annotated existing IDFs
+- Look for similar existing IDFs
+- Use the IDF page for more detailed documentation
+
+Using the Schema
+----------------
+
+To set up your editor with the schema, `Follow These Instructions <http://www.mantidproject.org/Using_XML_Schema>`__.
+The Schema can help with writing the IDF. For example:
+
+- In Visual Studio the schema can be used to auto-insert elements and attributes permitted by the schema.
+- In eclipse the IDF can be created in a design view by selected available elements and attributes without having to type the code yourself.
+The IDF schema (IDFSchema.xsd) is located in your mantid install directory at MantidInstall\instrument\Schema. Note this folder also includes the schema, ParameterFileSchema.xsd, which may be used to assist in writting a :ref:`parameter file <InstrumentParameterFile>`
+
+
+Find a Similar existing IDF
+---------------------------
+
+It may be that an instrument already exists that is similar to the one you wish to add. To see the existing instruments follow the procedure below.
+
+- Install Mantid
+- Open MantidPlot
+- Execute the algorithm LoadEmptyInstrument
+- This open the algorithm window for this algorithm. Click the Browse button and browse to the instrument folder of your Mantid install directory
+- The instrument folder contains all the instruments that Mantid currently support. Select for example SANS2D_Definition.xml. Fill in the output workspace name, and and click 'Run'
+- The created workspace will appear in the Workspaces window. Right click on the workspace and chose 'Show Instrument'
+- A new window appears, which is called the `Instrument view <http://www.mantidproject.org/MantidPlot:_Instrument_View>`__.
+
+In addition below is a list (for now just containing one item) of existing IDFs which have been annotated with the purpose of (hopefully) quickly learn the basis of creating an IDF:
+
+- :ref:`SANS2D: ISIS small angle scattering instrument <SANS2D_Sample_IDF>`
+- :ref:`LET: ISIS direct inelastic instrument<LET_Sample_IDF>`
+
+.. categories:: Concepts
diff --git a/Code/Mantid/docs/source/concepts/Data_Service.rst b/Code/Mantid/docs/source/concepts/Data_Service.rst
index 4462ece86a82a62201a5ccc00266e0466ae133a8..a30328f5e45a6d1f38802d2bfcea5a7beef34013 100644
--- a/Code/Mantid/docs/source/concepts/Data_Service.rst
+++ b/Code/Mantid/docs/source/concepts/Data_Service.rst
@@ -1,6 +1,6 @@
.. _Data Service:
-Data_Service
+Data Service
============
What are they?
@@ -17,10 +17,10 @@ deleting it.
Data Services in Mantid
-----------------------
-- `Analysis Data Service <Analysis Data Service>`__ - A data service
- holding all of the `workspaces <Workspace>`__ used in this session.
-- `Instrument Data Service <Instrument Data Service>`__ - A data
- service holding all of the `instruments <Instrument>`__ used in this
+- :ref:`Analysis Data Service <Analysis Data Service>` - A data service
+ holding all of the :ref:`workspaces <Workspace>` used in this session.
+- :ref:`Instrument Data Service <Instrument Data Service>` - A data
+ service holding all of the :ref:`instruments <Instrument>` used in this
session.
diff --git a/Code/Mantid/docs/source/concepts/Dynamic_Factory.rst b/Code/Mantid/docs/source/concepts/Dynamic_Factory.rst
index e52bdeb1c37fad5a39592917a8ccdfa42702912f..9802c3e18256e6886a5088e9a36425519fda2878 100644
--- a/Code/Mantid/docs/source/concepts/Dynamic_Factory.rst
+++ b/Code/Mantid/docs/source/concepts/Dynamic_Factory.rst
@@ -1,17 +1,17 @@
.. _Dynamic Factory:
-Dynamic_Factory
+Dynamic Factory
===============
What is it?
-----------
A dynamic factory is a software concept that in instrumental in
-implementing the `Plugin <Plugin>`__ technology in Mantid.
+implementing the :ref:`Plugin <Plugin>` technology in Mantid.
A factory in software terms is an class that is responsible for creating
other objects on demand. In mantid terms the AlgorithmFactory is
-responsible for creating instances of `Algorithms <Algorithm>`__ when
+responsible for creating instances of :ref:`Algorithms <Algorithm>` when
you need them.
As the factory is dynamic it does not have a set list of objects that it
diff --git a/Code/Mantid/docs/source/concepts/Error_Propagation.rst b/Code/Mantid/docs/source/concepts/Error_Propagation.rst
index e1e561e944472213454134236857d97d01c6fa18..c45bfd1fa1b9f4cbabf28c69c6998835f9494766 100644
--- a/Code/Mantid/docs/source/concepts/Error_Propagation.rst
+++ b/Code/Mantid/docs/source/concepts/Error_Propagation.rst
@@ -1,6 +1,6 @@
.. _Error Propagation:
-Error_Propagation
+Error Propagation
=================
The purpose of this document is to explain how Mantid deals with Error
diff --git a/Code/Mantid/docs/source/concepts/EventWorkspace.rst b/Code/Mantid/docs/source/concepts/EventWorkspace.rst
index a364ae053ae023c842f23bceab925a675cc73b61..7e8712b18582552f9147ff9e1d0d9f5c3c19a403 100644
--- a/Code/Mantid/docs/source/concepts/EventWorkspace.rst
+++ b/Code/Mantid/docs/source/concepts/EventWorkspace.rst
@@ -6,29 +6,29 @@ EventWorkspace
Quick Summary For Users
-----------------------
-The EventWorkspace is a type of `MatrixWorkspace <MatrixWorkspace>`__,
+The EventWorkspace is a type of :ref:`MatrixWorkspace <MatrixWorkspace>`,
where the information about each individual neutron detection event is
maintained. For you as a user, this means that:
-- You can `rebin <rebin>`__ an EventWorkspace over and over and no
+- You can :ref:`rebin <algm-rebin>` an EventWorkspace over and over and no
information is ever lost.
- The histogram (Y and E values) of an EventWorkspace are only
calculated when they are requested.
- You typically get better performance, even for very fine binning.
-- You can convert an EventWorkspace to a `Workspace2D <Workspace2D>`__
- by using the `Rebin <Rebin>`__ algorithm and changing the output
+- You can convert an EventWorkspace to a :ref:`Workspace2D <Workspace2D>`
+ by using the :ref:`Rebin <algm-Rebin>` algorithm and changing the output
workspace name.
- You cannot modify the histogram Y values (for example, with the
Divide algorithm) and keep the event data. If you use an algorithm
that modifies the Y values, the output workspace will be a
- `Workspace2D <Workspace2D>`__ using the current binning parameters.
+ :ref:`Workspace2D <Workspace2D>` using the current binning parameters.
If you set the same name on the output as the input of your
algorithm, then you will overwrite the EventWorkspace and lose that
event-based information.
- Some algorithms are EventWorkspace-aware, meaning that the output of
- it can be another EventWorkspace. For example, the `Plus <Plus>`__
+ it can be another EventWorkspace. For example, the :ref:`Plus <algm-Plus>`
algorithm will append the event lists if given two input
EventWorkspaces.
- Since it retains the most information, it is advantageous to keep
@@ -61,7 +61,7 @@ Lists of Events (EventList)
time of flight or pulse time, as needed.
- Also contained in the EventList is a std::set of detector ID's. This
- tracks which `detector <detector>`__\ (s) were hit by the events in
+ tracks which detector(s) were hit by the events in
the list.
- The histogram bins (X axis) are also stored in EventList. The Y and E
@@ -70,7 +70,7 @@ Lists of Events (EventList)
The += operator can be used to append two EventList's together. The
lists of TofEvent's get appended, as is the list of
-`detector <detector>`__ ID's. Don't mess with the udetmap manually if
+detector ID's. Don't mess with the udetmap manually if
you start appending event lists - just call
EventWorkpspace->makeSpectraMap to generate the spectra map (map between
spectrum # and detector IDs) by using the info in each EventList.
@@ -79,7 +79,7 @@ Most Recently Used List (MRUList)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
An EventWorkspace contains a list of the 100 most-recently used
-histograms, a `MRUList <MRUList>`__. This MRU caches the last histogram
+histograms, a MRUList. This MRU caches the last histogram
data generated for fastest display.
A note about workspace index / spectrum number / detector ID
@@ -95,9 +95,9 @@ Workspace2D compatibility
~~~~~~~~~~~~~~~~~~~~~~~~~
EventWorkspace is designed to be able to be read (but not written to)
-like a `Workspace2D <Workspace2D>`__. By default, if an algorithm
+like a :ref:`Workspace2D <Workspace2D>`. By default, if an algorithm
performs an operation and outputs a new workspace, the
-`WorkspaceFactory <WorkspaceFactory>`__ will create a Workspace2D *copy*
+WorkspaceFactory will create a Workspace2D *copy*
of your EventWorkspace's histogram representation. If you attempt to
change an EventWorkspace's Y or E data in place, you will get an error
message, since that is not possible.
diff --git a/Code/Mantid/docs/source/concepts/Facilities_File.rst b/Code/Mantid/docs/source/concepts/Facilities_File.rst
index 19f134edf297792b895e41cd1688ce3be30a4ef6..316a221be6f4149d6949703d1ae1fc4375f825ef 100644
--- a/Code/Mantid/docs/source/concepts/Facilities_File.rst
+++ b/Code/Mantid/docs/source/concepts/Facilities_File.rst
@@ -1,6 +1,6 @@
.. _Facilities File:
-Facilities_File
+Facilities File
===============
Summary
@@ -8,7 +8,7 @@ Summary
The facilities file, called **facilities.xml**, contains properties of
facilities and instruments that Mantid is aware of. In order for Mantid
-to function correctly for your facility then the facilites file should
+to function correctly for your facility then the facilities file should
contain the appropriate definitions as defined below.
File syntax
@@ -17,10 +17,6 @@ File syntax
Each facility is described using XML with an instrument defined as a sub
component of a facility. A simple facility definition would be
-.. raw:: html
-
- <div style="border:1pt dashed blue; background:#f9f9f9;padding: 1em 0;">
-
.. code:: XML
<?xml version="1.0" encoding="UTF-8"?>
@@ -34,10 +30,6 @@ component of a facility. A simple facility definition would be
</facilities>
-.. raw:: html
-
- </div>
-
which would define a facility called *BrandNew* with an instrument
called *ABCDEF*. The facilities attributes have the following meanings:
@@ -51,10 +43,6 @@ called *ABCDEF*. The facilities attributes have the following meanings:
An instrument can have further attributes which define properties of the
that instrument rather than the facility as a whole, e.g.
-.. raw:: html
-
- <div style="border:1pt dashed blue; background:#f9f9f9;padding: 1em 0;">
-
.. code:: XML
<?xml version="1.0" encoding="UTF-8"?>
@@ -73,10 +61,6 @@ that instrument rather than the facility as a whole, e.g.
</facilities>
-.. raw:: html
-
- </div>
-
where the attributes are defined as:
- ``shortName`` gives a shortened version of the instrument name
@@ -99,7 +83,7 @@ Location
The file should be located in the directory pointed to by the
**instrumentDefinition.directory** key in the
-`.properties <Properties_File>`__ file.
+:ref:`.properties <Properties File>` file.
diff --git a/Code/Mantid/docs/source/concepts/FitConstraint.rst b/Code/Mantid/docs/source/concepts/FitConstraint.rst
index 880d1eb6c887d5d3e3e9f9b0fff387ee62d930ab..5d26cb5ab2995431438ecfed69a634e16a9f1c38 100644
--- a/Code/Mantid/docs/source/concepts/FitConstraint.rst
+++ b/Code/Mantid/docs/source/concepts/FitConstraint.rst
@@ -1,11 +1,9 @@
.. _FitConstraint:
-FitConstraint
-=============
+Fit Constraint
+==============
+
-.. role:: math(raw)
- :format: html latex
-..
How constraints on parameters work
----------------------------------
diff --git a/Code/Mantid/docs/source/concepts/Framework_Manager.rst b/Code/Mantid/docs/source/concepts/Framework_Manager.rst
index 1003315f89d095eea0232e293bd6672e0981be5c..49ac51a1b2a593ce1733d613e2018bab748668cf 100644
--- a/Code/Mantid/docs/source/concepts/Framework_Manager.rst
+++ b/Code/Mantid/docs/source/concepts/Framework_Manager.rst
@@ -1,6 +1,6 @@
.. _Framework Manager:
-Framework_Manager
+Framework Manager
=================
What is it?
diff --git a/Code/Mantid/docs/source/concepts/Geometry.rst b/Code/Mantid/docs/source/concepts/Geometry.rst
index 0c5ad980f42e346010e421bf6cb4a18d409f374e..3fe73da9a226bd848adc3a85e5712ffbfa4577bc 100644
--- a/Code/Mantid/docs/source/concepts/Geometry.rst
+++ b/Code/Mantid/docs/source/concepts/Geometry.rst
@@ -7,15 +7,15 @@ What is it?
-----------
Geometry is the description of the physical shape (volume) of an object
-within a Mantid `instrument <Instrument>`__ and the distances and
+within a Mantid :ref:`instrument <Instrument>` and the distances and
rotations between them.
Geometry in Mantid
------------------
-In Mantid we seperate the `Geometry of the shape <Geometry of Shape>`__
-of an object from the `Geometry of it's
-position <Geometry of Position>`__. This is done primarily to save on
+In Mantid we seperate the :ref:`Geometry of the shape <Geometry of Shape>`
+of an object from the :ref:`Geometry of it's
+position <Geometry of Position>`. This is done primarily to save on
memory usage but also to improve performance. Many operations within
Mantid need to know where for example a detector is, but do not need to
know what shape it is. By keeping the Geometry and Position seperate we
diff --git a/Code/Mantid/docs/source/concepts/Geometry_of_Position.rst b/Code/Mantid/docs/source/concepts/Geometry_of_Position.rst
index 4007e956d07197d6a825b215bd93b2c675cecabf..b6cbf2f310b3c80a4092d82c12ebdee9d2c1e86f 100644
--- a/Code/Mantid/docs/source/concepts/Geometry_of_Position.rst
+++ b/Code/Mantid/docs/source/concepts/Geometry_of_Position.rst
@@ -7,7 +7,7 @@ What is it?
-----------
In Mantid we need to be able to define the position and orientation of
-every component within an `instrument <instrument>`__.
+every component within an :ref:`instrument <instrument>`.
What is a component?
--------------------
@@ -37,7 +37,7 @@ Object Component
^^^^^^^^^^^^^^^^
An object component is a component that has a
-`shape <Geometry_of_Shape>`__. Shapes can contain a lot more information
+:ref:`shape <Geometry of Shape>`. Shapes can contain a lot more information
to properly define them, and therefore take more memory. Where an
instrument contains a lot of instances of the same shape Mantid shares
one instance of the object(shape) across all of the object components
@@ -59,10 +59,10 @@ a tree structure allowing the top level structure objects to be reused
if they are repeated in an instrument. This is an example of a
simplified instrument tree, the lines show the links between the parent
and child relationships of the components. Full details on how to define
-an instrument can be found `here <InstrumentDefinitionFile>`__.
+an instrument can be found :ref:`here <InstrumentDefinitionFile>`.
-.. |SimpleInstrumentTree.png| image:: SimpleInstrumentTree.png
+.. |SimpleInstrumentTree.png| image:: ../images/SimpleInstrumentTree.png
.. categories:: Concepts
\ No newline at end of file
diff --git a/Code/Mantid/docs/source/concepts/Geometry_of_Shape.rst b/Code/Mantid/docs/source/concepts/Geometry_of_Shape.rst
index e232f7e90f72e9c009db685086d8125a33c51369..2c3284b603720eb2eeaecd4494ff81980c4ccbf5 100644
--- a/Code/Mantid/docs/source/concepts/Geometry_of_Shape.rst
+++ b/Code/Mantid/docs/source/concepts/Geometry_of_Shape.rst
@@ -1,6 +1,6 @@
.. _Geometry of Shape:
-Geometry_of_Shape
+Geometry of Shape
=================
What is it?
@@ -50,7 +50,7 @@ you get a finite capped cylinder. This is in fact how the Cylinder shape
is defined internally within Mantid.
For more on this see
-`HowToDefineGeometricShape <HowToDefineGeometricShape>`__.
+:ref:`HowToDefineGeometricShape <HowToDefineGeometricShape>`.
diff --git a/Code/Mantid/docs/source/concepts/HowToDefineGeometricShape.rst b/Code/Mantid/docs/source/concepts/HowToDefineGeometricShape.rst
index c9251bcd851eef49ca9dc5a67e98fb4e1118c59b..f15cbc9ff55612931a07c71d554840f1a1be6642 100644
--- a/Code/Mantid/docs/source/concepts/HowToDefineGeometricShape.rst
+++ b/Code/Mantid/docs/source/concepts/HowToDefineGeometricShape.rst
@@ -1,7 +1,7 @@
.. _HowToDefineGeometricShape:
-HowToDefineGeometricShape
-=========================
+How To Define Geometric Shape
+=============================
Overview
--------
@@ -10,7 +10,7 @@ Primitive Shapes
~~~~~~~~~~~~~~~~
There is direct support for defining any of the following geometric
-shapes to add `Instrument Definition File <IDF>`__.
+shapes to add :ref:`Instrument Definition File <InstrumentDefinitionFile>`.
- Sphere
- Infinite Cylinder
@@ -35,8 +35,7 @@ algebra that follows the following notation:
+------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------+
| " " | "space" shared between shapes, i,e. intersection (the common region of shapes). See e.g. also `2 <http://en.wikipedia.org/wiki/Intersection_(set_theory)>`__ | "small-circle = big-circle small-circle" (where the small circle placed within the big-circle) |
+------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------+
-| #. | Complement | #. sphere = shape defined by all points outside sphere |
-
+| #. | Complement | #. sphere = shape defined by all points outside sphere |
+------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------+
| ( ) | Brackets are used to emphasise which shapes an operation should be applied to. | box1 (# box2) is the intersection between box1 and the shape defined by all points not inside box2 |
+------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------+
@@ -78,10 +77,6 @@ Examples
Defining a sphere
~~~~~~~~~~~~~~~~~
-.. raw:: html
-
- <div style="border:1pt dashed black; background:#f9f9f9;padding: 1em 0;">
-
.. code:: xml
<sphere id="some-sphere">
@@ -91,10 +86,6 @@ Defining a sphere
<algebra val="some-sphere" />
-.. raw:: html
-
- </div>
-
Any shape must be given an ID name. Here the sphere has been given the
name "some-sphere". The purpose of the ID name is to use it in the
description, here this is done with the line . The description is
@@ -104,10 +95,6 @@ any shapes defined.
Defining a ball with a hole through it along the x-axis
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-.. raw:: html
-
- <div style="border:1pt dashed black; background:#f9f9f9;padding: 1em 0;">
-
.. code:: xml
<cylinder id="stick">
@@ -124,9 +111,6 @@ Defining a ball with a hole through it along the x-axis
<algebra val="some-sphere (# stick)" />
-.. raw:: html
-
- </div>
This algebra string reads as follows: take the *intersection* between a
sphere and the shape defined by all points *not* inside a cylinder of
@@ -141,10 +125,6 @@ Notation used to defined any of the predefined geometric shapes
Sphere
~~~~~~
-.. raw:: html
-
- <div style="border:1pt dashed black; background:#f9f9f9;padding: 1em 0;">
-
.. code:: xml
<sphere id="A">
@@ -152,17 +132,9 @@ Sphere
<radius val="3.2" />
</sphere>
-.. raw:: html
-
- </div>
-
Cylinder
~~~~~~~~
-.. raw:: html
-
- <div style="border:1pt dashed black; background:#f9f9f9;padding: 1em 0;">
-
.. code:: xml
<cylinder id="A">
@@ -172,21 +144,15 @@ Cylinder
<height val="10.2" />
</cylinder>
-.. raw:: html
-
- </div>
-.. figure:: XMLcylinderDescription.png‎
+.. figure:: ../images/XMLcylinderDescription.png
:alt: XMLcylinderDescription.png‎
XMLcylinderDescription.png‎
+
Infinite cylinder
~~~~~~~~~~~~~~~~~
-.. raw:: html
-
- <div style="border:1pt dashed black; background:#f9f9f9;padding: 1em 0;">
-
.. code:: xml
<infinite-cylinder id="A" >
@@ -195,17 +161,9 @@ Infinite cylinder
<radius val="1" />
</infinite-cylinder>
-.. raw:: html
-
- </div>
-
Slice of cylinder ring
~~~~~~~~~~~~~~~~~~~~~~
-.. raw:: html
-
- <div style="border:1pt dashed black; background:#f9f9f9;padding: 1em 0;">
-
.. code:: xml
<slice-of-cylinder-ring id="A">
@@ -215,27 +173,20 @@ Slice of cylinder ring
<arc val="45.0"/>
</slice-of-cylinder-ring>
-.. raw:: html
-
- </div>
-
This XML element defines a slice of a cylinder ring. Most importantly
the part of this shape facing the sample is flat and looks like this:
-.. figure:: XMLsliceCylinderRingDescription.png
+.. figure:: ../images/XMLsliceCylinderRingDescription.png
:alt: XMLsliceCylinderRingDescription.png
XMLsliceCylinderRingDescription.png
+
For this shape you may find it useful to specify a
-`Bounding-Box <HowToDefineGeometricShape#Bounding-Box>`__.
+:ref:`Bounding-Box <Bounding-Box>`.
Cone
~~~~
-.. raw:: html
-
- <div style="border:1pt dashed black; background:#f9f9f9;padding: 1em 0;">
-
.. code:: xml
<cone id="A" >
@@ -245,21 +196,14 @@ Cone
<height val="10.2" />
</cone>
-.. raw:: html
-
- </div>
-
-.. figure:: XMLconeDescription.png
+.. figure:: ../images/XMLconeDescription.png
:alt: XMLconeDescription.png
XMLconeDescription.png
+
Infinite cone
~~~~~~~~~~~~~
-.. raw:: html
-
- <div style="border:1pt dashed black; background:#f9f9f9;padding: 1em 0;">
-
.. code:: xml
<infinite-cone id="A" >
@@ -268,10 +212,6 @@ Infinite cone
<angle val="30.1" />
</infinite-cone>
-.. raw:: html
-
- </div>
-
Infinite plane
~~~~~~~~~~~~~~
@@ -279,10 +219,6 @@ Is the 3D shape of all points on the plane and all points on one side of
the infinite plane, the side which point away from the infinite plane in
the direction of the normal vector.
-.. raw:: html
-
- <div style="border:1pt dashed black; background:#f9f9f9;padding: 1em 0;">
-
.. code:: xml
<infinite-plane id="A">
@@ -290,17 +226,9 @@ the direction of the normal vector.
<normal-to-plane x="0.0" y="0.2" z="0" />
</infinite-plane>
-.. raw:: html
-
- </div>
-
Cuboid
~~~~~~
-.. raw:: html
-
- <div style="border:1pt dashed black; background:#f9f9f9;padding: 1em 0;">
-
.. code:: xml
<cuboid id="shape">
@@ -311,24 +239,17 @@ Cuboid
</cuboid>
<algebra val="shape" />
-.. raw:: html
-
- </div>
-
This particular example describes a cuboid with the origin at the centre
of the front face, which is here facing the negative z-axis and has the
dimensions 0.005mm x 0.2mm (in the xy-plane), and the depth of this
cuboid is 0.02mm.
-.. figure:: XMLcuboidDescription.png
+.. figure:: ../images/XMLcuboidDescription.png
:alt: XMLcuboidDescription.png
XMLcuboidDescription.png
-Another example of a cuboid is
-
-.. raw:: html
- <div style="border:1pt dashed black; background:#f9f9f9;padding: 1em 0;">
+Another example of a cuboid is
.. code:: xml
@@ -340,10 +261,6 @@ Another example of a cuboid is
</cuboid>
<algebra val="shape" />
-.. raw:: html
-
- </div>
-
which describes a cuboid with a front y-z plane (looking down the
x-axis). The origin is assumed to be the centre of this front surface,
which has dimensions 200mm along y and 20mm along z. The depth of this
@@ -352,10 +269,6 @@ cuboid is taken to be 1mm (along x).
Hexahedron
~~~~~~~~~~
-.. raw:: html
-
- <div style="border:1pt dashed black; background:#f9f9f9;padding: 1em 0;">
-
.. code:: xml
<hexahedron id="Bertie">
@@ -369,16 +282,14 @@ Hexahedron
<right-back-top-point x="0.0" y="0.5" z="2.0" />
</hexahedron>
-.. raw:: html
- </div>
-
-.. figure:: XMLhexahedronDescription.png
+.. figure:: ../images/XMLhexahedronDescription.png
:alt: XMLhexahedronDescription.png
XMLhexahedronDescription.png
+
For this shape you may find it useful to specify a
-`Bounding-Box <HowToDefineGeometricShape#Bounding-Box>`__.
+:ref:`Bounding-Box <Bounding-Box>`.
Tapered Guide
~~~~~~~~~~~~~
@@ -389,10 +300,6 @@ A tapered guide is a special case of hexahedron; a "start" rectangular
aperture which in a continued fashion changes into an "end" rectangular
aperture.
-.. raw:: html
-
- <div style="border:1pt dashed black; background:#f9f9f9;padding: 1em 0;">
-
.. code:: xml
<tapered-guide id="A Guide">
@@ -403,17 +310,15 @@ aperture.
<axis x="0.5" y="1.0" z="0.0" /> <!-- Optional. Defaults to (0, 0 ,1) -->
</tapered-guide>
-.. raw:: html
-
- </div>
-
The centre value denotes the centre of the start aperture. The specified
axis runs from the start aperture to the end aperture. "Height" is along
the y-axis and "width" runs along the x-axis, before the application of
the "axis" rotation.
For this shape you may find it useful to specify a
-`Bounding-Box <HowToDefineGeometricShape#Bounding-Box>`__.
+:ref:`Bounding-Box <Bounding-Box>`.
+
+.. _Bounding-Box:
Bounding-Box
------------
@@ -423,16 +328,12 @@ bounding box is automatically created for each geometric shape. This
works well for shapes such as cylinders and cuboids. However, for more
complex shapes and combined shapes the library used for the
visualization sometimes struggle, which can results in your instrument
-being viewed artifically very small (and you have to zoom in for a long
+being viewed artificially very small (and you have to zoom in for a long
time to see your instrument) and often in this context that the
visualization axes does not display properly. For such cases this can be
-fixed by explicitely adding a bounding-box using the notation
+fixed by explicitly adding a bounding-box using the notation
demonstrated below
-.. raw:: html
-
- <div style="border:1pt dashed black; background:#f9f9f9;padding: 1em 0;">
-
.. code:: xml
<hexahedron id="shape">
@@ -456,13 +357,7 @@ demonstrated below
<z-max val="0.0104"/>
</bounding-box>
-.. raw:: html
-
- </div>
-
Note for the best effect this bounding box should be enclosing the shape
as tight as possible.
-
-
.. categories:: Concepts
\ No newline at end of file
diff --git a/Code/Mantid/docs/source/concepts/Instrument.rst b/Code/Mantid/docs/source/concepts/Instrument.rst
index f0a453ddb681eb45b6cfb93d65d84d5f9e903447..0180cdd274d0f3fb70424b59740d6f5e0977a88e 100644
--- a/Code/Mantid/docs/source/concepts/Instrument.rst
+++ b/Code/Mantid/docs/source/concepts/Instrument.rst
@@ -24,10 +24,10 @@ Other components may also be included such as
- Link between log-files and variable parameters of the instrument
(such as the height of a detector table)
-An instrument is described using an `instrument definition
-file <InstrumentDefinitionFile>`__.
+An instrument is described using an :ref:`instrument definition
+file <InstrumentDefinitionFile>`.
-The Mantid geometry is further explained `here <Geometry>`__.
+The Mantid geometry is further explained :ref:`here <Geometry>`.
Why do we have a full instrument description, and not just a list of L2 and 2Theta values?
------------------------------------------------------------------------------------------
diff --git a/Code/Mantid/docs/source/concepts/InstrumentDefinitionFile.rst b/Code/Mantid/docs/source/concepts/InstrumentDefinitionFile.rst
index 171fa718aa1b4262d6ea627e8df1a2c33003f84e..3219b4a0fd4377b0a32c48573425195f45d7163d 100644
--- a/Code/Mantid/docs/source/concepts/InstrumentDefinitionFile.rst
+++ b/Code/Mantid/docs/source/concepts/InstrumentDefinitionFile.rst
@@ -1,19 +1,16 @@
.. _InstrumentDefinitionFile:
-InstrumentDefinitionFile
-========================
+Instrument Definition File
+==========================
-.. role:: math(raw)
- :format: html latex
-..
The documentation on this wiki page is the full detailed description of
the syntax you can use in an IDF to describe an instrument (note
parameters of instrument components may optionally be stored in
-`parameter file <InstrumentParameterFile>`__).
+:ref:`parameter file <InstrumentParameterFile>`).
-To get started creating an IDF follow the instructions on the `Create an
-IDF <Create_an_IDF>`__ page, then return here for more detailed
+To get started creating an IDF follow the instructions on the :ref:`Create an
+IDF <Create_an_IDF>` page, then return here for more detailed
explanations of syntax and structures.
Introduction
@@ -25,7 +22,7 @@ that are critically affecting the observed signal from an experiment.
Parameter values of components may also be specified such as information
about the opening height of a slit, the final energy of a detector and
so on. The value of such parameters can optionally be linked to values
-stored in log-files.
+stored in log-files.
In summary an IDF may be used to describe any or all of the following:
@@ -33,28 +30,29 @@ In summary an IDF may be used to describe any or all of the following:
for example, a detector bank containing 100 identical tubes each
containing 100 detector pixels. One option is to describe this setup
using a flat structure of 100\*100=10000 pixel components. Although
- this is a valid approach it 1) create uncessarily large files 2) but
- most importantly it does not capture the layout of the instrument.
- The prefered option is to describe this example by first defining a
+ this is a valid approach it
+ #. create unnecessarily large files
+ #. but most importantly it does not capture the layout of the instrument.
+ The preferred option is to describe this example by first defining a
“pixel†type, then a “tube†type containing 100 "pixels" and finally
a “bank†component containing 100 "tubes". This latter approach
requires the specification of 1(the bank)+100(tubes)+100(pixels)=201
components as compared to specifying 10000 components using the
former approach. The other benefit of organising the IDF according to
the layout of the instrument is that users can subsequently refer to
- the structure of the instrument as it is layed out. For example can
+ the structure of the instrument as it is laid out. For example can
then subsequently easily move entire 'bank' or associate parameters
which relevant for a specific say 'tube' or 'bank'.
#. The geometric shape and position of any component including: slits,
mirrors, detectors etc.
-#. A number of `specialised component
- types <InstrumentDefinitionFile#Special_.3Ctype.3Es>`__ are defined
+#. A number of :ref:`specialised component
+ types <Special types>` are defined
including:
- detector and monitor components: required to be associated with
unique detector or monitor ID numbers. The importance of these IDs
are described further in
- `1 <http://www.mantidproject.org/IDF#Using_detector.2Fmonitor_IDs_.3Cidlist.3E>`__
+ `1 <Using_detector.2Fmonitor_IDs_.3Cidlist.3E>`_
- SamplePos component: Purpose to store the sample position. Needed
e.g. to calculate sample-to-detector distances
- Source component: Purpose to store the source position or a
@@ -79,10 +77,6 @@ An IDF is structured as an `XML <http://en.wikipedia.org/wiki/XML>`__
document. For the purpose here it is enough to know that an XML document
follows a tree-based structure of elements with attributes. For example:
-.. raw:: html
-
- <div style="border:1pt dashed black; background:#f9f9f9;padding: 1em 0;">
-
.. code:: xml
<type name="main-detector-bank">
@@ -93,10 +87,6 @@ follows a tree-based structure of elements with attributes. For example:
</component>
</type>
-.. raw:: html
-
- </div>
-
defines an XML element with has the attribute name="main-detector-bank".
This element contains one sub-element , which again contains 3 elements.
In plain English the above XML code aims to describe a
@@ -104,15 +94,11 @@ In plain English the above XML code aims to describe a
within the bank.
If a component is a cylindrical tube where slices of this types are
-treated as detector pixels the tube detector performance enhacement can
+treated as detector pixels the tube detector performance enhancement can
optionally be used, which will e.g. make the display of this tube in the
instrument viewer faster. This can be done by adding 'outline' attribute
to the tag and setting its value to "yes".
-.. raw:: html
-
- <div style="border:1pt dashed black; background:#f9f9f9;padding: 1em 0;">
-
.. code:: xml
<type name="standard-tube" outline="yes">
@@ -123,9 +109,6 @@ to the tag and setting its value to "yes".
</component>
</type>
-.. raw:: html
-
- </div>
The 'outline attribute' only affects the 3D view of the instrument,
which appears by default. It may lead to a less accurate placing of the
@@ -137,8 +120,8 @@ IDF filename convention
-----------------------
An IDF can be loaded manually from any file with extension .xml or .XML
-using `LoadInstrument <LoadInstrument>`__ or
-`LoadEmptyInstrument <LoadEmptyInstrument>`__.
+using :ref:`LoadInstrument <algm-LoadInstrument>` or
+:ref:`LoadEmptyInstrument <algm-LoadEmptyInstrument>`.
IDFs located in the MantidInstall instrument directory are automatically
loaded together with e.g. the loading of raw data file. Such files are
@@ -146,20 +129,16 @@ required to have the format INSTRUMENTNAME\_DefinitionANYTHING.xml,
where INSTRUMENTNAME is the name of the instrument and ANYTHING can be
any string including an empty string. Where more than one IDF is defined
for an instrument the appropriate IDF is loaded based on its
-`valid-from <#Top_level_.3Cinstrument.3E>`__ and
-`valid-to <#Top_level_.3Cinstrument.3E>`__ dates. Note for this to work
-the `Workspace <Workspace>`__ for which an IDF is loaded into must
+:ref:`valid-from <Top level instrument>` and
+`valid-to <Top level instrument>` dates. Note for this to work
+the :ref:`Workspace <Workspace>` for which an IDF is loaded into must
contain a record of when the data were collected. This information is
-taken from the workspace's `Run <Run>`__ object, more specifically the
+taken from the workspace's :ref:`Run <Run>` object, more specifically the
*run\_start* property of this object.
In order to programmatically determine which is the correct filename for
a given date/time you can access a helper method from Python:
-.. raw:: html
-
- <div style="border:1pt dashed blue; background:#f9f9f9;padding: 1em 0;">
-
.. code:: python
import mantid.api
@@ -167,10 +146,6 @@ a given date/time you can access a helper method from Python:
currentIDF = mantid.api.ExperimentInfo.getInstrumentFilename("ARCS")
otherIDF = mantid.api.ExperimentInfo.getInstrumentFilename("ARCS", "2012-10-30")
-.. raw:: html
-
- </div>
-
More detailed descriptions of various parts of the IDF
------------------------------------------------------
@@ -178,17 +153,15 @@ Geometry shapes
~~~~~~~~~~~~~~~
For information on how to define geometric shapes see
-`HowToDefineGeometricShape <HowToDefineGeometricShape>`__.
-
-Top level
-~~~~~~~~~~
+:ref:`HowToDefineGeometricShape <HowToDefineGeometricShape>`.
- is the top level XML element of an IDF. It takes attributes, two of
-which must be included. An example is
+.. _Top level instrument:
-.. raw:: html
+Top level <instrument>
+~~~~~~~~~~~~~~~~~~~~~~
- <div style="border:1pt dashed black; background:#f9f9f9;padding: 1em 0;">
+<instrument> is the top level XML element of an IDF. It takes attributes, two of
+which must be included. An example is
.. code:: xml
@@ -197,10 +170,6 @@ which must be included. An example is
valid-to="2100-01-31 23:59:59"
last-modified="2010-10-12 08:54:07.279621">
-.. raw:: html
-
- </div>
-
Of the four attributes in the example above
- name is (at present) optional, although it is recommended to specify
@@ -209,7 +178,7 @@ Of the four attributes in the example above
from (+). This date must be larger than or equal to 1900-01-31
23:59:01
- valid-to may optionally be added to indicate the date to which the
- IDF is valid to. If not used, the file is permenently valid. (+)
+ IDF is valid to. If not used, the file is permanently valid. (+)
- last-modified is optional. Changing it can be used as an alternative
to force MantidPlot to reload the IDF, which e.g. might be useful
during the build up of an IDF
@@ -221,8 +190,10 @@ Valid ranges may overlap, provided the valid-from times are all
different. If several files are currently valid, the one with the most
recent valid-from time is selected.
-Using and
-~~~~~~~~~~
+.. _Using component and type:
+
+Using <component> and <type>
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Use the element to define a physical part of the instrument. A requires
two things
@@ -230,16 +201,12 @@ two things
#. It must have a type="some type" attribute. This specify the 'type' of
the component and this type must be specified somewhere in the IDF
using: .
-#. It must contain at least one element. If multiple are specified then
+#. It must contain at least one <location> element. If multiple <location> are specified then
this is essentially a shorthand notation for defining multiple
components of the same type at different locations.
Here is an example
-.. raw:: html
-
- <div style="border:1pt dashed black; background:#f9f9f9;padding: 1em 0;">
-
.. code:: xml
<component type="slit" name="bob">
@@ -249,27 +216,22 @@ Here is an example
<type name="slit"></type>
-.. raw:: html
- </div>
-
-Which defined two slits at two difference locations. Optionally a can be
+Which defined two slits at two difference locations. Optionally a <component> can be
given a 'name', in the above example this name is "bob". If no 'name'
-attribute is specified the name of the defaults to the 'type' string, in
+attribute is specified the name of the <component> defaults to the 'type' string, in
the above this is "slit". Giving sensible names to components is
-recommended for a number of reasons including 1) The 'Instrument Tree'
-view of an instrument in MantidPlot uses these names 2) when specifying
-s through s these names are used.
-
-Special s
-^^^^^^^^^
+recommended for a number of reasons including
+#. The 'Instrument Tree' view of an instrument in MantidPlot uses these names
+#. when specifying <parameter>s through <component-link>s these names are used.
-Within Mantid certain s have special meaning. A special is specified by
-including an 'is' attribute as demonstrated below
+.. _Special types:
-.. raw:: html
+Special <type>s
+^^^^^^^^^^^^^^^
- <div style="border:1pt dashed black; background:#f9f9f9;padding: 1em 0;">
+Within Mantid certain <type>s have special meaning. A special <type> is specified by
+including an 'is' attribute as demonstrated below
.. code:: xml
@@ -282,33 +244,26 @@ including an 'is' attribute as demonstrated below
</cuboid>
</type>
-.. raw:: html
-
- </div>
-
-where the 'is' attribute of is used to say this is a detector- (note
-this particular detector- has been assigned a geometric shape, in this
+where the 'is' attribute of is used to say this is a detector-<type> (note
+this particular detector-<type> has been assigned a geometric shape, in this
case a cuboid, see
-`HowToDefineGeometricShape <HowToDefineGeometricShape>`__). Special
+:ref:`HowToDefineGeometricShape <HowToDefineGeometricShape>`). Special
types recognised are:
#. Detector (or detector)
#. Monitor (or monitor)
-#. `RectangularDetector <InstrumentDefinitionFile#Creating_Rectangular_Area_Detectors>`__
+#. :ref:`RectangularDetector <Creating Rectangular Area Detectors>`
(or rectangularDetector, rectangulardetector, or
rectangular\_detector)
#. Source (or source)
#. SamplePos (or samplePos)
#. ChopperPos (or chopperPos)
-For example it is important to specify the location of one Source- and
-one SamplePos- in order for Mantid to be able to calculate L1 and L2
+For example it is important to specify the location of one Source-<type> and
+one SamplePos-<type> in order for Mantid to be able to calculate L1 and L2
distances and convert time-of-flight to, for instance, d-spacing. An
example of specifying a Source and SamplePos is shown below
-.. raw:: html
-
- <div style="border:1pt dashed black; background:#f9f9f9;padding: 1em 0;">
.. code:: xml
@@ -318,9 +273,6 @@ example of specifying a Source and SamplePos is shown below
<component type="some sample holder"> <location /> </component>
<type name="some sample holder" is="SamplePos" />
-.. raw:: html
-
- </div>
Using detector/monitor IDs
~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -336,9 +288,9 @@ important reason to insist on this.
Hence the job here to match the IDs in the data file with the IDs of
the IDF. Where unique IDs are not stored with the data the creator of
an IDF have some flexibility to chose these ID numbers since the data
- themself does not contain such number. However a link between the IDs
+ themselves does not contain such number. However a link between the IDs
and spectra in a workspace still needs to be made. By default the
- `LoadInstrument <LoadInstrument>`__ algorithm, see in particular the
+ :ref:`LoadInstrument <algm-LoadInstrument>` algorithm, see in particular the
RewriteSpectraMap parameter of this algorithm, will map the
detector/monitor IDs with spectrum numbers as follows: the
detector/monitor IDs in the IDF are ordered from smallest to largest
@@ -347,20 +299,16 @@ important reason to insist on this.
- Mantid needs to have a way to associate data which the
detectors/monitors of the instrument, which is do this using the
detector IDs. Although not mandatory it is recommended to give
- memorizable names to collection of detectors/monitors or individual
+ memorisable names to collection of detectors/monitors or individual
detectors/monitors that a user is likely to want to refer. This allow
a user to refer to a collection of detectors by name rather than
trying to remember a sequence of IDs. Note the counts in a histogram
spectrum may be the sum of counts from a number of detectors and
Mantid, behind the scene, use the IDs to keep track of this.
-The element and the idlist attribute of the elements is used to assign
+The <idlist> element and the idlist attribute of the elements is used to assign
detector IDs. The notation for using idlist is
-.. raw:: html
-
- <div style="border:1pt dashed black; background:#f9f9f9;padding: 1em 0;">
-
.. code:: xml
<component type="monitor" idlist="monitor-id-list">
@@ -382,26 +330,21 @@ detector IDs. The notation for using idlist is
<id val="650" /> <!-- specifies ID: 650 -->
</idlist>
-.. raw:: html
-
- </div>
-As can be seen to specify a sequence of IDs use the notation , where if
+As can be seen to specify a sequence of IDs use the notation <id start="500" step="10" end="530" />, where if
the step attribute defaults to step="1" if it is left out. Just specify
-just a single ID number you may alternatively use the notation . Please
+just a single ID number you may alternatively use the notation <id val="650" />. Please
note the number of ID specified must match the number of
detectors/monitors defined.
+.. _Creating Rectangular Area Detectors:
+
Creating Rectangular Area Detectors
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
There is a shortcut way to create 2D arrays of detector pixels. Here is
an example of how to do it:
-.. raw:: html
-
- <div style="border:1pt dashed black; background:#f9f9f9;padding: 1em 0;">
-
.. code:: xml
<component type="panel" idstart="1000" idfillbyfirst="y" idstepbyrow="300">
@@ -432,9 +375,6 @@ an example of how to do it:
<algebra val="pixel-shape"/>
</type>
-.. raw:: html
-
- </div>
- The "panel" type defined above has the special "is" tag of
"RectangularDetector". The same type definition then needs these
@@ -455,7 +395,7 @@ an example of how to do it:
- Detectors of the type specified ("pixel" in the example) will be
replicated at the X Y coordinates given. The usual rotation and
translation of the panel will rotate the pixels as needed.
-- Each instance of a "panel" needs to set these attributes, at the tag,
+- Each instance of a "panel" needs to set these attributes, at the <component> tag,
in order to specify the Pixel IDs of the 2D array.
- idstart: detector ID of the first pixel
@@ -484,10 +424,12 @@ an example of how to do it:
- Must have constant pixel spacing in each direction.
- Must be rectangular shape.
-Using
-~~~~~~
+.. _Using location:
-The element allows the specification of both the position of a component
+Using <location>
+~~~~~~~~~~~~~~~~
+
+The <location> element allows the specification of both the position of a component
and a rotation or the component's coordinate system. The position part
can be specified either using standard x, y and z coordinates or using
spherical coordinates: r, t and p, which stands for radius, theta and
@@ -496,10 +438,6 @@ azimuth angle in the xy-plane
`3 <http://en.wikipedia.org/wiki/Spherical_coordinate_system>`__.
Examples of translations include
-.. raw:: html
-
- <div style="border:1pt dashed black; background:#f9f9f9;padding: 1em 0;">
-
.. code:: xml
<component type="something" name="bob">
@@ -507,68 +445,46 @@ Examples of translations include
<location r="1.0" t="90.0" p="0.0"/>
</component>
-.. raw:: html
-
- </div>
-
The above two translations have identical effect. They both translate a
-component along the x-axis by "1.0". Note that optionally a can be given
-a name similarly to how a can optionally be given a name. In a 'name'
-attribtute is not specified for a element it defaults to the name of the
-.
+component along the x-axis by "1.0". Note that optionally a <location> can be given
+a name similarly to how a <location> can optionally be given a name. If a 'name'
+attribute is not specified for a <location> element it defaults to the name of the
+<component>.
The rotation part is specified using the attributes 'rot', 'axis-x',
'axis-y', 'axis-z' and these result in a rotation about the axis defined
-by the latter three atttributes. As an example the effect of
-
-.. raw:: html
-
- <div style="border:1pt dashed black; background:#f9f9f9;padding: 1em 0;">
+by the latter three attributes. As an example the effect of
.. code:: xml
<location rot="45.0" axis-x="0.0" axis-y="0.0" axis-z="1.0"/>
-.. raw:: html
-
- </div>
-
is to set the coordinate frame of the this component equal to that of
the parent component rotated by 45 degrees around the z-axis.
-Both a translation and rotation can be defined within one element. For
+Both a translation and rotation can be defined within one <location> element. For
example
-.. raw:: html
-
- <div style="border:1pt dashed black; background:#f9f9f9;padding: 1em 0;">
-
.. code:: xml
<location x="1.0" y="0.0" z="0.0" rot="45.0" axis-x="0.0" axis-y="0.0" axis-z="1.0"/>
-.. raw:: html
- </div>
-
-will cause this componet to be translation along the x-axis by "1.0"
+will cause this component to be translation along the x-axis by "1.0"
relative to the coordinate frame of the parent component followed by a
rotation of the coordinate frame by 45 degrees around the z-axis as
demonstrated in the figure below.
-.. figure:: Location-element-transformation.png
+.. figure:: ../images/Location-element-transformation.png
:alt: Location-element-transformation.png
Location-element-transformation.png
Any rotation of a coordinate system can be performed by a rotation about
some axis, however, sometime it may be advantageous to think of such a
-rotation as a composite of two or more rotations. For this reason a
+rotation as a composite of two or more rotations. For this reason a <location>
element is allowed to have sub-rotation-elements, and an example of a
composite rotation is
-.. raw:: html
-
- <div style="border:1pt dashed black; background:#f9f9f9;padding: 1em 0;">
.. code:: xml
@@ -578,9 +494,6 @@ composite rotation is
</rot>
</location>
-.. raw:: html
-
- </div>
The outermost is applied first followed by the 2nd outermost operation
and so on. In the above example this results in a -20.6 degree rotation
@@ -589,22 +502,15 @@ about the y-axis followed by a 102.8 degree rotation about the z-axis
followed by another rotation about the y-axis, this time by 50 degrees.
The ISIS NIMROD instrument (NIM\_Definition.xml) uses this feature.
-The translation part of a element can like the rotation part also be
+The translation part of a <location> element can like the rotation part also be
split up into a nested set of translations. This is demonstrated below
-.. raw:: html
-
- <div style="border:1pt dashed black; background:#f9f9f9;padding: 1em 0;">
-
.. code:: xml
<location r="10" t="90" >
<trans r="8" t="-90" />
</location>
-.. raw:: html
-
- </div>
This combination of two translations: one moving 10 along the x-axis in
the positive direction and the other in the opposite direction by 8 adds
@@ -612,16 +518,12 @@ up to a total translation of 2 in the positive x-direction. This
feature, for example, is useful when the positions of detectors are best
described in spherical coordinates with respect to an origin different
from the origin of the parent component. For example, say you have
-defined a with contains 3 pixels. The centre of the bank is at the
+defined a <type name="bank"> with contains 3 pixels. The centre of the bank is at the
location r="1" with respect to the sample and the positions of the 3
pixels are known with respect to the sample to be at r="1" and with
t="-1", t="0" and t="1". One option is to describe this bank/pixels
structure as
-.. raw:: html
-
- <div style="border:1pt dashed black; background:#f9f9f9;padding: 1em 0;">
-
.. code:: xml
<component type="bank">
@@ -636,17 +538,9 @@ structure as
</component>
</type>
-.. raw:: html
-
- </div>
-
However a better option for this case is to use nested translations as
demonstrated below
-.. raw:: html
-
- <div style="border:1pt dashed black; background:#f9f9f9;padding: 1em 0;">
-
.. code:: xml
<component type="bank">
@@ -661,20 +555,12 @@ demonstrated below
</component>
</type>
-.. raw:: html
-
- </div>
-
since this means the bank is actually specified at the right location,
and not artificially at the sample position.
-Finally a combination of and sub-elements of a element can be used as
+Finally a combination of <trans> and <rot> sub-elements of a <location> element can be used as
demonstrated below
-.. raw:: html
-
- <div style="border:1pt dashed black; background:#f9f9f9;padding: 1em 0;">
-
.. code:: xml
<location x="10" >
@@ -683,9 +569,6 @@ demonstrated below
</rot>
</location>
-.. raw:: html
-
- </div>
which put something at the location (x,y,z)=(10,-8,0) relative to the
parent component and with a 90 rotation around the z-axis, which causes
@@ -694,20 +577,18 @@ the x-axis to be rotated onto the y-axis.
Most of the attributes of have default values. These are: x="0" y="0"
z="0" rot="0" axis-x="0" axis-y="0" axis-z="1"
-Using
-^^^^^^
+.. _Using facing:
+
+Using <facing>
+^^^^^^^^^^^^^^
-The element is an element you can use together with a . Its purpose is
+The <facing> element is an element you can use together with a <location>. Its purpose is
to be able, with one line of IDF code, to make a given component face a
point in space. For example many detectors on ISIS instruments are setup
-to face the sample. A element must be specified as a sub-element of a
-element, and the facing operation is applied after the translation
+to face the sample. A <facing>element must be specified as a sub-element of a
+<location> element, and the facing operation is applied after the translation
and/or rotation operation as specified by the location element. An
-example of a element is
-
-.. raw:: html
-
- <div style="border:1pt dashed black; background:#f9f9f9;padding: 1em 0;">
+example of a <facing> element is
.. code:: xml
@@ -715,56 +596,45 @@ example of a element is
or
<facing r="0.0" t="0.0" p="0.0"/>
-.. raw:: html
-
- </div>
-
-In addition if the is set under , i.e. by default any component in the
-IDF will be rotated to face a default position then
-
-.. raw:: html
-
- <div style="border:1pt dashed black; background:#f9f9f9;padding: 1em 0;">
+In addition if the <components-are-facing> is set under <defaults>,
+i.e. by default any component in the IDF will be rotated to face a
+default position then
.. code:: xml
<facing val="none"/>
-.. raw:: html
-
- </div>
can be used to overwrite this default to say you don't want to apply
'facing' to given component.
-The process of facing is to make the xy-plane of the geometric shape of
-the component face the position specified in the element. The z-axis is
-normal to the xy-plan, and the operation of facing is to change the
-direction of the z-axis so that it points in the direction from the
-position specified in the facing towards the position of the component.
-
- supports a rot attribute, which allow rotation of the z-axis around it
-own axis before changing its direction. The effect of rot here is
-identical to the effect of using rot in a where axis-x="0.0"
-axis-y="0.0" axis-z="1.0". Allowing rot here perhpas make it slightly
-clearly that such a rot is as part of facing a component towards another
-component.
+The process of facing is to make the xy-plane of the geometric shape
+of the component face the position specified in the <facing> element.
+The z-axis is normal to the xy-plan, and the operation of facing is
+to change the direction of the z-axis so that it points in the direction
+from the position specified in the facing <facing> towards the position
+of the component.
-which rotate the is a convenient element for adjusting the orientation
-of the z-axis. The base rotation is to take the direction the z-axis
-points and change it to point from the position specified by the element
-to the positon of the component.
+<facing> supports a rot attribute, which allow rotation of the
+z-axis around it own axis before changing its direction. The
+effect of rot here is identical to the effect of using rot in a
+<location> where axis-x="0.0" axis-y="0.0" axis-z="1.0". Allowing
+rot here perhaps make it slightly clearly that such a rot is as
+part of facing a component towards another component.
-Using
-^^^^^^
+which rotate the is a convenient element for adjusting the orientation
+of the z-axis. The base rotation is to take the direction the z-axis
+points and change it to point from the position specified by the
+<facing> element to the position of the component.
-A specifies the location of a . If this type consists of a number of
-sub-parts can be used to exclude certain parts of a type. For example
-say the type below is defined in an IDF
+.. _Using exclude:
-.. raw:: html
+Using <exclude>
+^^^^^^^^^^^^^^^
- <div style="border:1pt dashed black; background:#f9f9f9;padding: 1em 0;">
+A <location> specifies the location of a <type>. If this type consists
+of a number of sub-parts <exclude> can be used to exclude certain parts
+of a type. For example say the type below is defined in an IDF
.. code:: xml
@@ -778,18 +648,10 @@ say the type below is defined in an IDF
</component>
</type>
-.. raw:: html
-
- </div>
-
-and the instrument consists of a number of these doors but where some of
-the doors are different in the sense that for example the 1st and/or the
-2nd tube is missing from some of these. Using this can be succinctly
-described as follows:
-
-.. raw:: html
-
- <div style="border:1pt dashed black; background:#f9f9f9;padding: 1em 0;">
+and the instrument consists of a number of these doors but where some of
+the doors are different in the sense that for example the 1st and/or the
+2nd tube is missing from some of these. Using <exclude> this can be
+succinctly described as follows:
.. code:: xml
@@ -805,10 +667,6 @@ described as follows:
</location>
</component>
-.. raw:: html
-
- </div>
-
where the sub-part of refers to the 'name' of a part of the type 'door'.
Extra options for indirect geometry instruments
@@ -816,39 +674,30 @@ Extra options for indirect geometry instruments
Optionally, both physical and 'neutronic' detector positions can be
specified for indirect geometry instrument. This is described
-`here <Indirect Instrument Definition Options>`__.
-
-Using
-~~~~~~
+`here <http://www.mantidproject.org/Indirect_Instrument_Definition_Options>`__.
-Most instruments have detectors which are orderered in some way. For a
-`rectangular array of
-detectors <IDF#Creating_Rectangular_Area_Detectors>`__ we have a
-shorthand notation. The tag is a shorthand notation to use for a
-linear/spherical sequence of detectors, as any of the position
-coordinates or the coordinate rotation angles of a tag are changing.
+.. _Using locations:
-For example a element may be used to describe the position of equally
-distanced pixels along a tube, in the example below along the y variable
+Using <locations>
+~~~~~~~~~~~~~~~~~
-.. raw:: html
+Most instruments have detectors which are ordered in some way. For a
+:ref:`rectangular array of
+detectors <Creating Rectangular Area Detectors>` we have a
+shorthand notation. The <locations> tag is a shorthand notation to use
+for a linear/spherical sequence of detectors, as any of the position
+coordinates or the coordinate rotation angles of a <location> tag are changing.
- <div style="border:1pt dashed black; background:#f9f9f9;padding: 1em 0;">
+For example a <locations> element may be used to describe the position
+of equally distanced pixels along a tube, in the example below along
+the y variable
.. code:: xml
<locations y="1.0" y-end="10.0" n-elements="10" name="det"/>
-.. raw:: html
-
- </div>
-
The above one line of XML is shorthand notation for
-.. raw:: html
-
- <div style="border:1pt dashed black; background:#f9f9f9;padding: 1em 0;">
-
.. code:: xml
<location y="1.0" name="det0"/>
@@ -862,36 +711,20 @@ The above one line of XML is shorthand notation for
<location y="9.0" name="det8" />
<location y="10.0" name="det9" />
-.. raw:: html
-
- </div>
-
-As is seen n-elements is the number of elements this element is
-shorthand for. y-end specifies the y end position, and the equal
-distance in y between the pixels is calculated in the code as
-('y'-'y-end')/('n-elements'-1). Multiple 'variable'-end attributes can
-be specified for the tag, where 'variable' here is any of the
-attributes: x, y, z, r, t, p and rot. The example below describes a list
-of detectors aligned in a semi-circle:
-
-.. raw:: html
-
- <div style="border:1pt dashed black; background:#f9f9f9;padding: 1em 0;">
+As is seen n-elements is the number of <location> elements this <locations>
+element is shorthand for. y-end specifies the y end position, and the equal
+distance in y between the pixels is calculated in the code as
+('y'-'y-end')/('n-elements'-1). Multiple 'variable'-end attributes can be
+specified for the <locations> tag, where 'variable' here is any of the
+<location> attributes: x, y, z, r, t, p and rot. The example below
+describes a list of detectors aligned in a semi-circle:
.. code:: xml
<locations n-elements="7" r="0.5" t="0.0" t-end="180.0" rot="0.0" rot-end="180.0" axis-x="0.0" axis-y="1.0" axis-z="0.0"/>
-.. raw:: html
-
- </div>
-
The above one line of XML is shorthand notation for
-.. raw:: html
-
- <div style="border:1pt dashed black; background:#f9f9f9;padding: 1em 0;">
-
.. code:: xml
<location r="0.5" t="0" rot="0" axis-x="0.0" axis-y="1.0" axis-z="0.0"/>
@@ -902,50 +735,38 @@ The above one line of XML is shorthand notation for
<location r="0.5" t="150" rot="150" axis-x="0.0" axis-y="1.0" axis-z="0.0"/>
<location r="0.5" t="180" rot="180" axis-x="0.0" axis-y="1.0" axis-z="0.0"/>
-.. raw:: html
-
- </div>
+If name is specified, e.g. as name="det" in the first example, then as seen the
+<location> elements are given the 'name' plus a counter, where by default this counter starts from zero. This counter can optionally be changed by using
+attribute name-count-start, e.g. setting name-count-start="1" in the above
+example would have named the 10 <location> elements det1, det2, ..., det10.
-If name is specified, e.g. as name="det" in the first example, then as
-seen the elements are given the 'name' plus a counter, where by default
-this counter starts from zero. This counter can optionally be changed by
-using attribute name-count-start, e.g. setting name-count-start="1" in
-the above example would have named the 10 elements det1, det2, ...,
-det10.
+When one <locations> tag was used in ISIS LET_Definition.xml the number of
+lines of this file reduced from 1590 to 567.
-When one tag was used in ISIS LET\_Definition.xml the number of lines of
-this file reduced from 1590 to 567.
+.. _Using parameter:
-Using
-~~~~~~
+Using <parameter>
+~~~~~~~~~~~~~~~~~
-Parameters which do not change or are changed via should be stored using
+Parameters which do not change or are changed via <logfile> should be stored using
this element inside the IDF, however parameters which may need to be
accessed and changed manually on a regular basis should be stored in a
-separate `parameter file <InstrumentParameterFile>`__.
+separate :ref:`parameter file <InstrumentParameterFile>`.
- is used to specify a value to a parameter which can then be extracted
-from Mantid. One usage of is to link values stored in log-files to
+<parameter> is used to specify a value to a parameter which can then be extracted
+from Mantid. One usage of <parameter> is to link values stored in log-files to
parameter names. For example
-.. raw:: html
-
- <div style="border:1pt dashed black; background:#f9f9f9;padding: 1em 0;">
-
.. code:: xml
<parameter name="x">
<logfile id="trolley2_x_displacement" extract-single-value-as="position 1" />
</parameter>
-.. raw:: html
-
- </div>
-
reads: “take the first value in the “trolley2\_x\_displacement" log-file
and use this value to set the parameter named 'x'.
-The name of the is specified using the 'name' tag. You may specify any
+The name of the <parameter> is specified using the 'name' tag. You may specify any
name for a parameter except for name="pos" and name="rot". These are
reserved keywords. Further a few names have a special effect when
processed by Mantid
@@ -967,7 +788,7 @@ processed by Mantid
any rotation. Regardless of what order rotx, roty and rotz is
specified in the IDF the combined rotation is equals that obtained by
applying rotx, then roty and finally rotz.
-- "Efixed". If specified the `ConvertUnits <ConvertUnits>`__ algorithm
+- "Efixed". If specified the :ref:`ConvertUnits <algm-ConvertUnits>` algorithm
uses this value in unit conversion
- "SplitInto". How many MD boxes to split into when converting to MD.
- "SplitThreshold". The threshold number of MDEvents in an MDBox before
@@ -977,14 +798,14 @@ processed by Mantid
- "offset-phi". Effective boolean for turning on/off Phi offsets by PI.
Set to Always to apply.
-The value of the parameter is in the above example specified using a
-log-file as specified with the element . The required attribute of is
+The value of the parameter is in the above example specified using a log-file as
+specified with the element <logfile>. The required attribute of <logfile> is
- *id* - the logfile name minus the file extension and the ISIS raw
file name. For example the id for the logfile 'CSP78173\_height.txt'
is 'height'.
-Optional attributes of are:
+Optional attributes of <logfile> are:
- *extract-single-value-as* - specify which value (or values) from the
logfile should be used to. This attribute takes any of the following
@@ -1016,31 +837,19 @@ Optional attributes of are:
Another option for specifying a value for a parameter is to use the
notation:
-.. raw:: html
-
- <div style="border:1pt dashed black; background:#f9f9f9;padding: 1em 0;">
-
.. code:: xml
<parameter name="x">
<value val="7.2"/>
</parameter>
-.. raw:: html
+Here a value for the parameter with name "x" is set directly to 7.2. The only and
+required attribute of the <value> element is 'val'.
- </div>
-
-Here a value for the parameter with name "x" is set directly to 7.2. The
-only and required attribute of the element is 'val'.
-
-For a given you should specify its value only once. If by mistake you
-specify a value twice as demonstrated in the example below then the
-first encountered element is used, and if no element is present then the
-first encountered element is used.
-
-.. raw:: html
-
- <div style="border:1pt dashed black; background:#f9f9f9;padding: 1em 0;">
+For a given <parameter> you should specify its value only once. If by mistake you
+specify a value twice as demonstrated in the example below then the first encountered
+<value> element is used, and if no <value> element is present then the first
+encountered <logfile> element is used.
.. code:: xml
@@ -1049,24 +858,17 @@ first encountered element is used.
<logfile id="trolley2_x_displacement" extract-single-value-as="position 1" />
</parameter>
-.. raw:: html
- </div>
+In the above example <value val="7.2"/> is used.
-In the above example is used.
+.. _Accessing parameter:
-Accessing
-~~~~~~~~~~
+Accessing <parameter>
+~~~~~~~~~~~~~~~~~~~~~
-Parameters are by default accessed recursively, see for instance methods
-of
-`ParametrizedComponent <http://doxygen.mantidproject.org/classMantid_1_1Geometry_1_1ParametrizedComponent.html>`__.
+Parameters are by default accessed recursively.
Demonstrated with an example:
-.. raw:: html
-
- <div style="border:1pt dashed black; background:#f9f9f9;padding: 1em 0;">
-
.. code:: xml
<component type="dummy">
@@ -1086,26 +888,20 @@ Demonstrated with an example:
</component>
</type>
-.. raw:: html
-
- </div>
this implies that if you for instance ask the component with
name="pixel1" what parameters it has then the answer is two:
something1=25.5 and something=35.0. If you ask the component
name="dummy" the same question the answer is one: something=35.0 and so
-on. Recursive look-up can be diabled see for instance
-`ParametrizedComponent <http://doxygen.mantidproject.org/classMantid_1_1Geometry_1_1ParametrizedComponent.html>`__.
+on.
-Using *string*
-~~~~~~~~~~~~~~~
-
-This is a special category of parameters where the value specified for
-the paramter is string rather than a double. The syntax is
+.. _Using string parameter:
-.. raw:: html
+Using *string* <parameter>
+~~~~~~~~~~~~~~~~~~~~~~~~~~
- <div style="border:1pt dashed black; background:#f9f9f9;padding: 1em 0;">
+This is a special category of parameters where the value specified for
+the parameter is string rather than a double. The syntax is
.. code:: xml
@@ -1113,12 +909,11 @@ the paramter is string rather than a double. The syntax is
<value val="closed"/>
</parameter>
-.. raw:: html
- </div>
+.. _Using fitting parameter:
-Using *fitting*
-~~~~~~~~~~~~~~~~
+Using *fitting* <parameter>
+~~~~~~~~~~~~~~~~~~~~~~~~~
This is a special category of parameters, which follows the same syntax
as other but allows a few extra features. Fitting parameters are meant
@@ -1129,33 +924,21 @@ process starts, where optionally these may, for instance, be specified
to be treated as fixed by default. To specify a fitting parameter use
the additional tag type="fitting" as shown in the example below
-.. raw:: html
-
- <div style="border:1pt dashed black; background:#f9f9f9;padding: 1em 0;">
-
.. code:: xml
<parameter name="IkedaCarpenterPV:Alpha0" type="fitting">
<value val="7.2"/>
</parameter>
-.. raw:: html
-
- </div>
-
It is required that the parameter name uses the syntax
NameOfFunction:Parameter, where NameOfFunction is the name of the
fitting function the parameter is associated with. In the example above
-the fitting function name is `IkedaCarpenterPV <IkedaCarpenterPV>`__ and
+the fitting function name is :ref:`IkedaCarpenterPV <func-IkedaCarpenterPV>` and
the parameter name is Alpha0.
To specify that a parameter should be treated as fixed in the fitting
process use the element as demonstrated in the example below
-.. raw:: html
-
- <div style="border:1pt dashed black; background:#f9f9f9;padding: 1em 0;">
-
.. code:: xml
<parameter name="IkedaCarpenterPV:Alpha0" type="fitting">
@@ -1163,18 +946,10 @@ process use the element as demonstrated in the example below
<fixed />
</parameter>
-.. raw:: html
-
- </div>
-
A parameter can be specified to have a min/max value, which results in a
constraint being applied to this parameter. An example of this is shown
below
-.. raw:: html
-
- <div style="border:1pt dashed black; background:#f9f9f9;padding: 1em 0;">
-
.. code:: xml
<parameter name="IkedaCarpenterPV:Alpha0" type="fitting">
@@ -1182,17 +957,9 @@ below
<min val="4"/> <max val="12"/>
</parameter>
-.. raw:: html
-
- </div>
-
The min/max values may also be specified as percentage values. For
example:
-.. raw:: html
-
- <div style="border:1pt dashed black; background:#f9f9f9;padding: 1em 0;">
-
.. code:: xml
<parameter name="IkedaCarpenterPV:Alpha0" type="fitting">
@@ -1201,60 +968,44 @@ example:
<penalty-factor val="2000"/>
</parameter>
-.. raw:: html
-
- </div>
-
results in Alpha0 being constrained to sit between 250\*0.8=200 and
250\*1.20=300. Further this example also demonstrates how a can be
specified to tell how strongly the min/max constraints should be
enforced. The default value for the penalty-factor is 1000. For more
-information about this factor see `FitConstraint <FitConstraint>`__.
+information about this factor see :ref:`FitConstraint <FitConstraint>`.
A value for a parameter may alternatively be set using a look-up-table
or a formula. An example demonstrating a formula is
-.. raw:: html
-
- <div style="border:1pt dashed black; background:#f9f9f9;padding: 1em 0;">
-
.. code:: xml
<parameter name="IkedaCarpenterPV:Alpha0" type="fitting">
<formula eq="100.0+10*centre+centre^2" unit="TOF" result-unit="1/dSpacing^2"/>
</parameter>
-.. raw:: html
-
- </div>
-
'centre' in the formula is substituted with the centre-value of the peak
shape function as known prior to the start of the fitting process. The
attributes 'unit' is optional. If it is not set then the peak
centre-value is directly substituted for the centre variable in the
formula. If it is set then it must be set to no one of the units defined
-in `Unit\_Factory <Unit_Factory>`__, and what happens is that the peak
+in :ref:`Unit Factory <Unit Factory>`, and what happens is that the peak
centre-value is converted to this unit before assigned to the centre
variable in the formula.
The optional 'result-unit' attribute tells what the unit is of the
output of the formula. In the example above this unit is "1/dSpacing^2"
(for the 'result-unit' this attribute can be set to an algebraic
-expression of the units defined in `Unit\_Factory <Unit_Factory>`__). If
+expression of the units defined in :ref:`Unit Factory <Unit Factory>`). If
the x-axis unit of the data you are trying to fit is dSpacing then the
output of the formula is left as it is. But for example if the x-axis
unit of the data is TOF then the formula output is converted into, it in
this case, the unit "1/TOF^2". Examples where 'unit' and 'result-unit'
are used include:
-`CreateBackToBackParameters <CreateBackToBackParameters>`__ and
-`CreateIkedaCarpenterParameters <CreateIkedaCarpenterParameters>`__.
+:ref:`CreateBackToBackParameters <algm-CreateBackToBackParameters>` and
+:ref:`CreateIkedaCarpenterParameters <algm-CreateIkedaCarpenterParameters>`.
An example which demonstrate using a look-up-table is
-.. raw:: html
-
- <div style="border:1pt dashed black; background:#f9f9f9;padding: 1em 0;">
-
.. code:: xml
<parameter name="IkedaCarpenterPV:Alpha0" type="fitting">
@@ -1266,30 +1017,25 @@ An example which demonstrate using a look-up-table is
</lookuptable>
</parameter>
-.. raw:: html
-
- </div>
As with a formula the look-up is done for the 'x'-value that corresponds
to the centre of the peak as known prior to the start of the fitting
process. The only interpolation option currently supported is 'linear'.
The optional 'x-unit' and 'y-unit' attributes must be set to one of the
-units defined in `Unit\_Factory <Unit_Factory>`__. The 'x-unit' and
+units defined in :ref:`Unit Factory <Unit Factory>`. The 'x-unit' and
'y-unit' have very similar effect to the 'unit' and 'result-unit'
attributes for described above. 'x-unit' converts the unit of the centre
before lookup against the x-values. 'y-axis' is the unit of the y values
listed, which for the example above correspond to Alpha0.
-Using
-~~~~~~
+.. _Using component-link:
-Allow s to be linked to components without needing s to be defined
-inside, as sub-elements, of the components they belong to. The standard
-approach for defining a parameter is
-
-.. raw:: html
+Using <component-link>
+~~~~~~~~~~~~~~~~~~~~~~
- <div style="border:1pt dashed black; background:#f9f9f9;padding: 1em 0;">
+Allow <parameter>s to be linked to components without needing <parameter>s to be
+defined inside, as sub-elements, of the components they belong to. The standard
+approach for defining a parameter is
.. code:: xml
@@ -1298,20 +1044,12 @@ approach for defining a parameter is
<parameter name="test"> <value val="50.0" /> </parameter>
</component>
-.. raw:: html
-
- </div>
-
where a parameter 'test' is defined to belong to the component with the
name 'bank\_90degnew'. However, alternatively the parameter can be
defined using the notation in the an example below. Note that if more
than one component e.g. have the name 'bank\_90degnew' then the
specified parameters are applied to all such components.
-.. raw:: html
-
- <div style="border:1pt dashed black; background:#f9f9f9;padding: 1em 0;">
-
.. code:: xml
<component type="bank" name="bank_90degnew">
@@ -1322,65 +1060,41 @@ specified parameters are applied to all such components.
<parameter name="test"> <value val="50.0" /> </parameter>
</component-link>
-.. raw:: html
-
- </div>
-
- is the only way parameters can be defined in a **parameter file** used
-by the `LoadParameterFile <LoadParameterFile>`__ algorithm.
+<component-link> is the only way parameters can be defined in a **parameter file** used
+by the :ref:`LoadParameterFile <algm-LoadParameterFile>` algorithm.
If there are several components with name 'bank\_90degnew' but you want
specified paramentes to apply to only one of them, then you can specify
the name by a path name.
-.. raw:: html
-
- <div style="border:1pt dashed black; background:#f9f9f9;padding: 1em 0;">
-
.. code:: xml
<component-link name="HRPD/leftside/bank_90degnew" >
<parameter name="test"> <value val="50.0" /> </parameter>
</component-link>
-.. raw:: html
-
- </div>
-
The path name need not be complete provided it specifies a unique
component. Here we drop the instrument name HRPD.
-.. raw:: html
-
- <div style="border:1pt dashed black; background:#f9f9f9;padding: 1em 0;">
-
.. code:: xml
<component-link name="leftside/bank_90degnew" >
<parameter name="test"> <value val="50.0" /> </parameter>
</component-link>
-.. raw:: html
+.. _Using combine-components-into-one-shape:
- </div>
-
-.
-
-Using
-~~~~~~
+Using <combine-components-into-one-shape>
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The standard way of making up geometric shapes as a collection of parts
is described here:
-`HowToDefineGeometricShape <HowToDefineGeometricShape>`__. However,
+:ref:`HowToDefineGeometricShape <HowToDefineGeometricShape>`. However, <combine-components-into-one-shape>
offers in some circumstances a more convenient way of defining more
complicated shapes, as for example is the case for the ISIS POLARIS
instrument. This tag combining components into one shape as demonstrated
below:
-.. raw:: html
-
- <div style="border:1pt dashed black; background:#f9f9f9;padding: 1em 0;">
-
.. code:: xml
<component type="adjusted cuboid"
@@ -1432,26 +1146,22 @@ below:
</bounding-box>
</type>
-.. raw:: html
+which combines two components "A" and "B" into one shape. The resulting
+shape is shape is shown here:
- </div>
+.. figure:: ../images/CombineIntoOneShapeExample.png
+ :alt: CombineIntoOneShapeExample.png
-which combines two components "A" and "B" into one shape. The resulting
-shape is shape is shown here:\ |CombineIntoOneShapeExample.png‎|.
+ CombineIntoOneShapeExample.png
Note for this to work, a unique name for each component must be provided
and these names must be used in the algebra sting (here "A : B", see
-`HowToDefineGeometricShape <HowToDefineGeometricShape>`__). Further a
-bounding-box may optionally be added to the to the type , see
-`HowToDefineGeometricShape#Bounding-Box <HowToDefineGeometricShape#Bounding-Box>`__.
+:ref:`HowToDefineGeometricShape <HowToDefineGeometricShape>`). Further a
+bounding-box may optionally be added to the to the type.
Note the above geometric shape can alternatively be defined with the XML
(Mantid behind the scene translates the above XML to the XML below
before proceeding):
-.. raw:: html
-
- <div style="border:1pt dashed black; background:#f9f9f9;padding: 1em 0;">
-
.. code:: xml
<component type="adjusted cuboid">
@@ -1475,89 +1185,81 @@ before proceeding):
<algebra val="A : B" />
</type>
-.. raw:: html
-
- </div>
-
- for now works only for combining cuboids. Please do not hesitate to
+<combine-components-into-one-shape> for now works only for combining cuboids. Please do not hesitate to
contact the Mantid team if you would like to extend this.
-This applies when defining any geometric shape, but perhaps something
-which a user has to be in particular aware of when defining more
-complicated geometry shapes, for example, using the tag: the coordinate
-system in which a shape is defined can be chosen arbitrary, and the
-origin of this coordinate system is the position returned when a user
-asked for its position. It is therefore highly recommended that when a
-user define a detector geometric shape, this could be simple cuboid,
-that it is defined with the origin at the centre of the front of the
-detector. For detector shapes build up of for example multiple cuboids
-the origin should be chosen perhaps for the center of the front face of
-the 'middle' cuboid. When Mantid as for the position of such a shape it
-will be with reference to coordinate system origin of the shape.
-However, sometimes it may simply be inconvenient to build up a geometry
-shape with an coordinate system as explained above. For this case, and
-for now only when using it possible to get around this by using the
-element , which takes the same attributes as a element. The effect of
-this element is basically to redefine the shape coordinate system origin
-(in fact also rotate it if requested).
-
-Using
-~~~~~~
+This applies when defining any geometric shape, but perhaps something which a user
+has to be in particular aware of when defining more complicated geometry shapes, for
+example, using the <combine-components-into-one-shape> tag: the coordinate system in
+which a shape is defined can be chosen arbitrary, and the origin of this coordinate
+system is the position returned when a user asked for its position. It is therefore
+highly recommended that when a user define a detector geometric shape, this could be
+simple cuboid, that it is defined with the origin at the centre of the front of the
+detector. For detector shapes build up of for example multiple cuboids the origin
+should be chosen perhaps for the center of the front face of the 'middle' cuboid.
+When Mantid as for the position of such a shape it will be with reference to
+coordinate system origin of the shape. However, sometimes it may simply be
+inconvenient to build up a geometry shape with an coordinate system as explained above.
+For this case, and for now only when using <combine-components-into-one-shape> it
+possible to get around this by using the element <translate-rotate-combined-shape-to>,
+which takes the same attributes as a <location> element. The effect of this element
+is basically to redefine the shape coordinate system origin (in fact also rotate it
+if requested).
+
+.. _Using defaults:
+
+Using <defaults>
+~~~~~~~~~~~~~~~~
Used for setting various defaults.
-Used to make the xy-plane of the geometric shape of any component by
-default face a given location. For example
+.. _components-are-facing:
-.. raw:: html
+<components-are-facing>
+^^^^^^^^^^^^^^^^^^^^^^^
- <div style="border:1pt dashed black; background:#f9f9f9;padding: 1em 0;">
+Used to make the xy-plane of the geometric shape of any component by
+default face a given location. For example
.. code:: xml
<components-are-facing x="0.0" y="0.0" z="0.0" />
-.. raw:: html
-
- </div>
-
If this element is not specified the default is to *not* attempt to
apply facing.
+.. _offsets:
+
+<offsets>
+^^^^^^^^^
+
Originally introduced to handle detector position coordinates as defined
by the
`Ariel <http://www.isis.rl.ac.uk/Disordered/GEM/ariel/index_ariel.htm>`__
software.
-.. raw:: html
-
- <div style="border:1pt dashed black; background:#f9f9f9;padding: 1em 0;">
-
.. code:: xml
<offsets spherical="delta" />
-.. raw:: html
-
- </div>
-
When this is set all components which have coordinates specified using
spherical coordinates (i.e. using the r, t, p attributes, see
-description of ) are then treated as offsets to the spherical position
+description of <location>) are then treated as offsets to the spherical position
of the parent, i.e. the value given for :math:`r` are added to the
parent's :math:`r` to give the total radial coordinate, and the same for
:math:`\theta` and :math:`\phi`. Note using this option breaks the
-symmetry that the element of a child component equals the position of
+symmetry that the <location> element of a child component equals the position of
this component relative to its parent component.
+.. _reference-frame:
+
+<reference-frame>
+^^^^^^^^^^^^^^^^^
+
Reference frame in which instrument is described. The author/reader of
an IDF can chose the reference coordinate system in which the instrument
is described. The default reference system is the one shown below.
-.. raw:: html
-
- <div style="border:1pt dashed black; background:#f9f9f9;padding: 1em 0;">
-
.. code:: xml
<reference-frame>
@@ -1568,24 +1270,26 @@ is described. The default reference system is the one shown below.
<handedness val="right"/>
</reference-frame>
-.. raw:: html
-
- </div>
This reference frame is e.g. used when a signed theta detector values
are calculated where it is needed to know which direction is defined as
up. The direction here means the direction of the beam if it was not
-modified by any mirrows etc.
+modified by any mirrors etc.
+
+.. _default-view:
+
+<default-view>
+^^^^^^^^^^^^^^
This tag is used to control how the instrument first appears in the
-`Instrument View <MantidPlot:_Instrument_View>`__. Attribute ``view``
+`Instrument View <http://www.mantidproject.org/MantidPlot:_Instrument_View>`__. Attribute ``view``
defines the type of the view that opens by default. It can have the
following values: "3D", "cylindrical\_x", "cylindrical\_y",
"cylindrical\_z", "spherical\_x", "spherical\_y", "spherical\_z". If the
attribute is omitted value "3D" is assumed. Opening the 3D view on
start-up is also conditioned on the value of the
-``MantidOptions.InstrumentView.UseOpenGL`` property in the `Properties
-File <Properties_File>`__. If set to "Off" this property prevents the
+``MantidOptions.InstrumentView.UseOpenGL`` property in the :ref:`Properties
+File <Properties File>`. If set to "Off" this property prevents the
Instrument View to start in 3D mode and "cylindrical\_y" is used
instead. The user can change to 3D later.
@@ -1594,39 +1298,29 @@ initially viewed from in 3D and can be set equal to one of "Z-", "Z+",
"X-", etc. If "Z-" were selected then the view point would be on the
z-axis on the negative of the origin looking in the +z direction.
-If
+.. _angle unit="radian":
-.. raw:: html
+<angle unit="radian">
+^^^^^^^^^^^^^^^^^^^^^
- <div style="border:1pt dashed black; background:#f9f9f9;padding: 1em 0;">
+If
.. code:: xml
<angle unit="radian"/>
-.. raw:: html
-
- </div>
-is set then all angles specified in elements and 's with names "rotx",
-"roty", "rotz", "t-position" and "p-position" are assumed to in radians.
-The default is to assume all angles are specified in degrees.
+is set then all angles specified in <location> elements and <parameter>'s with names
+"rotx", "roty", "rotz", "t-position" and "p-position" are assumed to in radians. The
+default is to assume all angles are specified in degrees.
Other defaults
^^^^^^^^^^^^^^
-.. raw:: html
-
- <div style="border:1pt dashed black; background:#f9f9f9;padding: 1em 0;">
-
.. code:: xml
<length unit="meter"/>
-.. raw:: html
-
- </div>
-
This default, for now, does not do anything, but is the default unit for
length used by Mantid. If it would be useful for you to specify user
defined units do not hesitate to `request
@@ -1640,18 +1334,17 @@ information not related to the geometry of the instrument may be put
into a separate file, whose content is automatically included into the
IDF file.
-For more information see the **`parameter file
-page <InstrumentParameterFile>`__**.
+For more information see the :ref:`parameter file
+page <InstrumentParameterFile>`.
Deprecated Features
-------------------
-=== mark-as="monitor" === The following notation to mark a detector as a
-monitor is now deprecated:
-
-.. raw:: html
+mark-as="monitor"
+^^^^^^^^^^^^^^^^^
- <div style="border:1pt dashed black; background:#f9f9f9;padding: 1em 0;">
+The following notation to mark a detector as a
+monitor is now deprecated:
.. code:: xml
@@ -1665,16 +1358,8 @@ monitor is now deprecated:
<id val="11" />
</idlist>
-.. raw:: html
-
- </div>
-
The above XML should be replaced with
-.. raw:: html
-
- <div style="border:1pt dashed black; background:#f9f9f9;padding: 1em 0;">
-
.. code:: xml
<component type="monitor" idlist="monitor">
@@ -1687,12 +1372,5 @@ The above XML should be replaced with
<id val="11" />
</idlist>
-.. raw:: html
-
- </div>
-
-
-
-.. |CombineIntoOneShapeExample.png‎| image:: CombineIntoOneShapeExample.png‎
.. categories:: Concepts
\ No newline at end of file
diff --git a/Code/Mantid/docs/source/concepts/InstrumentParameterFile.rst b/Code/Mantid/docs/source/concepts/InstrumentParameterFile.rst
new file mode 100644
index 0000000000000000000000000000000000000000..f1d4a0b8b4a3d60e5ae9fec396556b8b07fe8109
--- /dev/null
+++ b/Code/Mantid/docs/source/concepts/InstrumentParameterFile.rst
@@ -0,0 +1,65 @@
+.. _InstrumentParameterFile:
+
+Instrument Parameter File
+=========================
+
+Summary
+-------
+
+Instrument parameter files are files complimentary to :ref:`Instrument Definition Files (IDFs)<InstrumentDefinitionFile>` that are used to store information about an instrument that may change on a regular basis i.e. parameters not related to the geometry of an instrument. By storing the data outside of the :ref:`IDF<InstrumentDefinitionFile>`, it makes it easier to locate and change parameters, as well as keeping the length of the :ref:`IDF<InstrumentDefinitionFile>` to a minimum.
+
+Creating a Parameter File
+-------------------------
+
+Using a Schema
+~~~~~~~~~~~~~~
+
+To create a parameters file it is advisable to consult the parameter file schema, located in your mantid directory at mantid\code\instrument\Schema\ParameterFileSchema.xsd. Set up your editting program to validate your XML file against this schema following `these instructions <http://www.mantidproject.org/Using_XML_Schema>`__. Once set up, the schema can be used to find any errors in the structure of your parameter file and suggest auto-fill options to help write your parameter file.
+
+General Structure
+~~~~~~~~~~~~~~~~~
+
+The Instrument parameter files, like the :ref:`IDFs<InstrumentDefinitionFile>`, are written in XML. They must contain a root element <parameter-file> with an attribute 'name' equal to the name of the instrument. Within the <parameter-file> element, goes all the rest of the information. To specify a parameter for a component defined the :ref:`IDF<InstrumentDefinitionFile>`, use a <component-link> element with attribute 'name' equal to the name of the component. Within the <component-link> element, the various parameters can be defined in exactly the same way as described in the parameters section of the IDF Page.
+The below example shows some of the elements featured in IN10_silicon_111_Parameters.xml. It defines a parameter 'analysis-type' for the component IN10 i.e. the whole instrument. The component link is closed and then a new one is opened to define parameters for the component 'silicon'.
+
+
+.. code:: xml
+
+ <?xml version="1.0" encoding="UTF-8" ?>
+ <parameter-file instrument="IN10" date="2010-07-15 00:00:00">
+
+ <component-link name="IN10">
+ <parameter name="analysis-type" type="string">
+ <value val="spectroscopy" />
+ </parameter>
+ </component-link>
+
+ <component-link name="silicon">
+ <parameter name="Efixed">
+ <value val="2.082" />
+ </parameter>
+ </component-link>
+
+ </parameter-file>
+
+Naming and Using a Parameter File
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+There may be just one parameter file per instrument that is automatically included with name the form XXX_Parameters.xml, for instrument XXX in the instrument folder.
+
+One can have several parameter files for an instrument:
+
+- If the IDF is not in the instrument folder and there is another XXX_Parameters.xml in the same folder, this one in the same folder will be used instead of any parameter file in the instrument folder.
+- If you want one parameter file for your IDF file, name your IDF file XXX_Definition_Yyy.xml and the parameter file XXX_Parameters_Yyy.xml , where Yyy is any combination a characters you find appropriate. If your IDF file is not in the instrument folder, the parameter file can be in either the same folder or in the instrument folder, but it can only be in the instrument folder, if the same folder has no XXX_Parameters.xml or XXX_Parameters_Yyy.xml file.
+- If there is no XXX_Parameters_Yyy.xml file, XXX_Parameters.xml would be used.
+
+Also one can use a any parameter file by executing the :ref:`LoadParameterFile <algm-LoadParameterFile>` algorithm.
+
+Work is planned to enable a parameter file to import one other parameter file. This will then enable duplication to be avoided in the parameter files.
+
+Adding Parameters at run time
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Since version 3.2 of Mantid the algorithm :ref:`SetInstrumentParameter<algm-SetInstrumentParameter>` allows you to create or replace instrument parameters for a particular workspace at run time.
+
+.. categories:: Concepts
\ No newline at end of file
diff --git a/Code/Mantid/docs/source/concepts/Instrument_Data_Service.rst b/Code/Mantid/docs/source/concepts/Instrument_Data_Service.rst
index 8acf9cbeffeee6c6b3a5268b764d917d6bd78957..a9e37ee33d4c6e917bab3380400d25434cdc3e3b 100644
--- a/Code/Mantid/docs/source/concepts/Instrument_Data_Service.rst
+++ b/Code/Mantid/docs/source/concepts/Instrument_Data_Service.rst
@@ -1,13 +1,13 @@
.. _Instrument Data Service:
-Instrument_Data_Service
+Instrument Data Service
=======================
What is it?
-----------
-The Instrument Data Service (IDS) is a `Data Service <Data Service>`__
-that is specialized to hold all of the `instruments <Instrument>`__ that
+The Instrument Data Service (IDS) is a :ref:`Data Service <Data Service>`
+that is specialized to hold all of the :ref:`instruments <Instrument>` that
are created during a user session. Whenever an instrument definition is
loaded it is saved in the IDS and further workspaces that refer to the
same instrument share the same definition.
@@ -23,7 +23,7 @@ workspace.
``workspace->getInstrument();``
However if you really did want to access the instrument from the IDS (as
-a `Shared Pointer <Shared Pointer>`__), although this would then lack
+a :ref:`Shared Pointer <Shared Pointer>`), although this would then lack
any workspace specific alterations or properties.
``boost::shared_ptr``\ \ `` intrument = workspace->getInstrument();``
diff --git a/Code/Mantid/docs/source/concepts/LET_Sample_IDF.rst b/Code/Mantid/docs/source/concepts/LET_Sample_IDF.rst
new file mode 100644
index 0000000000000000000000000000000000000000..29f4d90f2e1b0fe9bc063f44ad70e270e58dc8b5
--- /dev/null
+++ b/Code/Mantid/docs/source/concepts/LET_Sample_IDF.rst
@@ -0,0 +1,711 @@
+.. _LET_Sample_IDF:
+
+IDF-ISIS-SANS2D-annotated
+=========================
+
+This page annotates the direct inelastic instrument LET, with the purpose of (hopefully) quickly learn the basis of creating a similar IDF.
+
+Instrument view of LET
+----------------------
+
+LET consists of doors (in the speach of LET scientists) where each door is made up of a number of tupes along the y-axis (green line in picture below), where each tube is made up of a sequence pixels (detectors).
+
+The view of the instrument below is in the 'Full 3D' mode.
+
+.. figure:: ../images/LETinFull3DInstrumentView.png
+ :alt: LETinFull3DInstrumentView.png
+
+ LETinFull3DInstrumentView.png
+
+An annotated version of the ISIS LET IDF
+----------------------------------------
+
+.. code:: xml
+
+ <!-- Specify name of instrument and date from when this IDF is valid -->
+ <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="LET"
+ valid-from ="1900-01-31 23:59:59"
+ valid-to ="2100-01-31 23:59:59"
+ last-modified="2012-03-13 00:00:00">
+
+ <!-- Specify various optional defaults -->
+ <defaults>
+ <length unit="meter"/>
+ <angle unit="degree"/>
+ <reference-frame>
+ <along-beam axis="z"/>
+ <pointing-up axis="y"/>
+ <handedness val="right"/>
+ <origin val="beam" />
+ </reference-frame>
+ <default-view view="cylindrical_y"/>
+ <!-- The option below will by default orientate the
+ z-axis of any component to point from (0,0,0) towards the component. -->
+ <components-are-facing x="0.0" y="0.0" z="0.0" />
+ </defaults>
+
+
+ <!-- Specify monitor components. Monitors collect data hence
+ the idlist="monitors", which specify the name of a list of detector/monitor IDs.
+ For ISIS data this provides the link between the data and the components
+ collecting the data. Even for data not associated with unique IDs,
+ unique ID numbers of your choice are still required, for subsequent
+ use by Mantid analysis -->
+ <component type="monitors" idlist="monitors">
+ <location/>
+ </component>
+
+ <!-- Specify what a type with name="monitors" is. This type happens to be a container/grouping
+ of the monitors of this instrument. This grouping is here entirely optional. Only difference
+ it makes is that in the Mantid instrument view tree these will be listed under one node, and
+ in Python/C++ code a user can more easy for example set a property which applies
+ to all the monitors -->
+ <type name="monitors">
+ <component type="monitor">
+ <location r="17.758" t="180.0" p="0.0" name="monitor1" />
+ <location r="17.060" t="180.0" p="0.0" name="monitor2" />
+ <location r="16.558" t="180.0" p="0.0" name="monitor3" />
+ <location r="13.164" t="180.0" p="0.0" name="monitor4" />
+ <location r="9.255" t="180.0" p="0.0" name="monitor5" />
+ <location r="1.333" t="180.0" p="0.0" name="monitor6" />
+ <location r="1.088" t="180.0" p="0.0" name="monitor7" />
+ <location r="1.088" t="180.0" p="0.0" name="monitor8" />
+ </component>
+ </type>
+
+ <!-- Define the monitor detector IDs. There are 8 of these on LET -->
+ <idlist idname="monitors">
+ <id start="11" end="81" step="10"/>
+ </idlist>
+
+ <!-- Define the type monitor, which is given a physical shape.
+ More specifically here a cylindrical shape. See http://www.mantidproject.org/HowToDefineGeometricShape
+ for all the options for defining a physical shape -->
+ <type name="monitor" is="monitor">
+ <cylinder id="some-shape">
+ <centre-of-bottom-base r="0.0" t="0.0" p="0.0" />
+ <axis x="0.0" y="0.0" z="1.0" />
+ <radius val="0.01" />
+ <height val="0.03" />
+ </cylinder>
+ <algebra val="some-shape" />
+ </type>
+
+
+ <!-- ISIS is a neutron spallation source. Therefore an important
+ piece of information is the position the source relative to
+ the sample, which is needed to calculate neutron flightpaths.
+ The source currently also serves as a point along the beam, and
+ the source-to-sample direction is used to determine the beam
+ direction in a number of parts of the Mantid code. -->
+ <component type="undulator">
+ <location z="-25.0"> <!-- Specify location of this component -->
+ <facing val="none"/> <!-- The <facing> tag here overwrites the default <components-are-facing> set above -->
+ </location>
+ </component>
+ <!-- Specify the type with name "undulator", which 'is' marked as being the Source.
+ Optionally you may define a geometric shape for the Source. In some cases done
+ with the purpose to get it to show up in the Mantid Instrument view.
+ See http://www.mantidproject.org/HowToDefineGeometricShape for more on geometric shapes -->
+ <type name="undulator" is="Source">
+ <cylinder id="some-shape">
+ <centre-of-bottom-base r="0.0" t="0.0" p="0.0" />
+ <axis x="0.0" y="0.0" z="1.0" />
+ <radius val="0.01" />
+ <height val="0.03" />
+ </cylinder>
+ <algebra val="some-shape" />
+ </type>
+
+ <!-- Specify the position of the sample and here a shape for
+ this sample also -->
+ <component type="nickel-holder">
+ <location> <facing val="none"/> </location>
+ </component>
+ <type name="nickel-holder" is="SamplePos">
+ <sphere id="some-shape">
+ <centre x="0.0" y="0.0" z="0.0" />
+ <radius val="0.03" />
+ </sphere>
+ <algebra val="some-shape" />
+ </type>
+
+ <!-- Specify the LET doors structure. Here the instrument scientist has
+ decided to define components of types: door01, ..., door12, where
+ each of these are placeholders for the same type LETdoor. The effect
+ of this is that you will have the node structure door01->LETdoor->tube1 etc.
+
+ An alternative would have been to instead of the xml code
+ <component type="door01" idlist="door01">
+ <location />
+ </component>
+ <type name="door01">
+ <component type="LETdoor">
+ <location x="-1.8805" z="2.9519"> <facing x="0" y="0" z="0"/>
+ </component>
+ </type>
+
+ have
+
+ <component type="LETdoor" idlist="door01" name="door01">
+ <location x="-1.8805" z="2.9519"> <facing x="0" y="0" z="0"/>
+ </component>
+
+ which would have given the node structure door01->tube1 etc. Both choices are
+ equally valid. -->
+ <component type="door01" idlist="door01"><location /></component>
+ <component type="door02" idlist="door02"><location /></component>
+ <component type="door03" idlist="door03"><location /></component>
+ <component type="door04" idlist="door04"><location /></component>
+ <component type="door05" idlist="door05"><location /></component>
+ <component type="door06" idlist="door06"><location /></component>
+ <component type="door07" idlist="door07"><location /></component>
+ <component type="door08" idlist="door08"><location /></component>
+ <component type="door09" idlist="door09"><location /></component>
+ <component type="door10" idlist="door10"><location /></component>
+ <component type="door11" idlist="door11"><location /></component>
+ <component type="door12" idlist="door12"><location /></component>
+
+ <type name="door01">
+ <component type="LETdoor">
+ <!-- Note here the instrument scientist has chosen to put in <facing x="0" y="0" z="0"/>
+ This element in fact here has no effect since the default
+ option set at the top <components-are-facing x="0.0" y="0.0" z="0.0" />
+ will already face any component to x="0.0" y="0.0" z="0.0" -->
+ <location x="-1.8805" z="2.9519"> <facing x="0" y="0" z="0"/> </location>
+ </component>
+ </type>
+ <type name="door02">
+ <component type="LETdoor">
+ <location x=" -1.0525 " z=" 3.3380 "> <facing x="0" y="0" z="0"/> </location>
+ </component>
+ </type>
+ <type name="door03">
+ <component type="LETdoor">
+ <location x=" -0.15267 " z=" 3.4967 "> <facing x="0" y="0" z="0"/> </location>
+ </component>
+ </type>
+ <type name="door04">
+ <component type="LETdoor">
+ <location x="0.75754 " z=" 3.4170 "> <facing x="0" y="0" z="0"/> </location>
+ </component>
+ </type>
+ <type name="door05">
+ <component type="LETdoor">
+ <location x=" 1.6161 " z=" 3.1045 "> <facing x="0" y="0" z="0"/> </location>
+ </component>
+ </type>
+ <type name="door06">
+ <component type="LETdoor">
+ <location x=" 2.3646 " z=" 2.5805 "> <facing x="0" y="0" z="0"/> </location>
+ </component>
+ </type>
+ <type name="door07">
+ <component type="LETdoor">
+ <location x=" 2.9519 " z=" 1.8805 "> <facing x="0" y="0" z="0"/> </location>
+ </component>
+ </type>
+ <type name="door08">
+ <component type="LETdoor">
+ <location x=" 3.3380 " z=" 1.0525 "> <facing x="0" y="0" z="0"/> </location>
+ </component>
+ </type>
+ <type name="door09">
+ <component type="LETdoor">
+ <location x=" 3.4967 " z=" 0.15267 "> <facing x="0" y="0" z="0"/> </location>
+ </component>
+ </type>
+ <type name="door10">
+ <component type="LETdoor">
+ <location x=" 3.4170 " z="-0.75754 "> <facing x="0" y="0" z="0"/> </location>
+ </component>
+ </type>
+ <type name="door11">
+ <component type="LETdoor">
+ <location x=" 3.1045 " z=" -1.6161 "> <facing x="0" y="0" z="0"/> </location>
+ </component>
+ </type>
+ <type name="door12">
+ <component type="LETdoor">
+ <location x=" 2.5805 " z=" -2.3646 "> <facing x="0" y="0" z="0"/> </location>
+ </component>
+ </type>
+
+ <type name="LETdoor">
+ <component type="LETtube" outline="yes">
+ <location x=" -0.393024 " z=" -0.221369E-01" name="tube1" />
+ <location x=" -0.367765 " z=" -0.193752E-01" name="tube2" />
+ <location x=" -0.342486 " z=" -0.167970E-01" name="tube3" />
+ <location x=" -0.317189 " z=" -0.144023E-01" name="tube4" />
+ <location x=" -0.291876 " z=" -0.121914E-01" name="tube5" />
+ <location x=" -0.266547 " z=" -0.101643E-01" name="tube6" />
+ <location x=" -0.241204 " z=" -0.832121E-02" name="tube7" />
+ <location x=" -0.215848 " z=" -0.666210E-02" name="tube8" />
+ <location x=" -0.190481 " z=" -0.518712E-02" name="tube9" />
+ <location x=" -0.165104 " z=" -0.389635E-02" name="tube10" />
+ <location x=" -0.139718 " z=" -0.278984E-02" name="tube11" />
+ <location x=" -0.114325 " z=" -0.186766E-02" name="tube12" />
+ <location x=" -0.889254E-01" z=" -0.112986E-02" name="tube13" />
+ <location x=" -0.635215E-01" z=" -0.576474E-03" name="tube14" />
+ <location x=" -0.381142E-01" z=" -0.207534E-03" name="tube15" />
+ <location x=" -0.127050E-01" z=" -0.230596E-04" name="tube16" />
+ <location x=" 0.127050E-01" z=" -0.230596E-04" name="tube17" />
+ <location x=" 0.381142E-01" z=" -0.207534E-03" name="tube18" />
+ <location x=" 0.635215E-01" z=" -0.576474E-03" name="tube19" />
+ <location x=" 0.889254E-01" z=" -0.112986E-02" name="tube20" />
+ <location x=" 0.114325 " z=" -0.186766E-02" name="tube21" />
+ <location x=" 0.139718 " z=" -0.278984E-02" name="tube22" />
+ <location x=" 0.165104 " z=" -0.389635E-02" name="tube23" />
+ <location x=" 0.190481 " z=" -0.518712E-02" name="tube24" />
+ <location x=" 0.215848 " z=" -0.666210E-02" name="tube25" />
+ <location x=" 0.241204 " z=" -0.832121E-02" name="tube26" />
+ <location x=" 0.266547 " z=" -0.101643E-01" name="tube27" />
+ <location x=" 0.291876 " z=" -0.121914E-01" name="tube28" />
+ <location x=" 0.317189 " z=" -0.144023E-01" name="tube29" />
+ <location x=" 0.342486 " z=" -0.167970E-01" name="tube30" />
+ <location x=" 0.367765 " z=" -0.193752E-01" name="tube31" />
+ <location x=" 0.393024 " z=" -0.221369E-01" name="tube32" />
+ </component>
+ </type>
+
+ <!-- Here the type for a tube is defined. It using the shorthand notation
+ <locations> to define 1024 pixels at positions along the y-axis.
+
+ Note also the 'outline' attribute is used. The attribute is to overcome
+ a technical difficulty when displaying and rotating a lot of
+ shapes in Mantid Instrument Viewer. For more information on this see www.mantidproject.org/IDF -->
+ <type name="LETtube" outline="yes">
+ <component type="pixel">
+ <locations y="-2.00304" y-end="2.00304" n-elements="1024" />
+ </component>
+ </type>
+
+
+ <type name="pixel" is="detector">
+ <cylinder id="cyl-approx">
+ <centre-of-bottom-base r="0.0" t="0.0" p="0.0" />
+ <axis x="0.0" y="0.2" z="0.0" />
+ <radius val=" 0.127000E-01" />
+ <height val=" 0.391602E-02" />
+ </cylinder>
+ <algebra val="cyl-approx" />
+ </type>
+
+
+ <!-- DETECTOR ID LISTS -->
+ <idlist idname="door01">
+ <id start="1110001" end="1111024" />
+ <id start="1120001" end="1121024" />
+ <id start="1130001" end="1131024" />
+ <id start="1140001" end="1141024" />
+ <id start="1150001" end="1151024" />
+ <id start="1160001" end="1161024" />
+ <id start="1170001" end="1171024" />
+ <id start="1180001" end="1181024" />
+ <id start="1210001" end="1211024" />
+ <id start="1220001" end="1221024" />
+ <id start="1230001" end="1231024" />
+ <id start="1240001" end="1241024" />
+ <id start="1250001" end="1251024" />
+ <id start="1260001" end="1261024" />
+ <id start="1270001" end="1271024" />
+ <id start="1280001" end="1281024" />
+ <id start="1310001" end="1311024" />
+ <id start="1320001" end="1321024" />
+ <id start="1330001" end="1331024" />
+ <id start="1340001" end="1341024" />
+ <id start="1350001" end="1351024" />
+ <id start="1360001" end="1361024" />
+ <id start="1370001" end="1371024" />
+ <id start="1380001" end="1381024" />
+ <id start="1410001" end="1411024" />
+ <id start="1420001" end="1421024" />
+ <id start="1430001" end="1431024" />
+ <id start="1440001" end="1441024" />
+ <id start="1450001" end="1451024" />
+ <id start="1460001" end="1461024" />
+ <id start="1470001" end="1471024" />
+ <id start="1480001" end="1481024" />
+ </idlist>
+ <idlist idname="door02">
+ <id start="2110001" end="2111024" />
+ <id start="2120001" end="2121024" />
+ <id start="2130001" end="2131024" />
+ <id start="2140001" end="2141024" />
+ <id start="2150001" end="2151024" />
+ <id start="2160001" end="2161024" />
+ <id start="2170001" end="2171024" />
+ <id start="2180001" end="2181024" />
+ <id start="2210001" end="2211024" />
+ <id start="2220001" end="2221024" />
+ <id start="2230001" end="2231024" />
+ <id start="2240001" end="2241024" />
+ <id start="2250001" end="2251024" />
+ <id start="2260001" end="2261024" />
+ <id start="2270001" end="2271024" />
+ <id start="2280001" end="2281024" />
+ <id start="2310001" end="2311024" />
+ <id start="2320001" end="2321024" />
+ <id start="2330001" end="2331024" />
+ <id start="2340001" end="2341024" />
+ <id start="2350001" end="2351024" />
+ <id start="2360001" end="2361024" />
+ <id start="2370001" end="2371024" />
+ <id start="2380001" end="2381024" />
+ <id start="2410001" end="2411024" />
+ <id start="2420001" end="2421024" />
+ <id start="2430001" end="2431024" />
+ <id start="2440001" end="2441024" />
+ <id start="2450001" end="2451024" />
+ <id start="2460001" end="2461024" />
+ <id start="2470001" end="2471024" />
+ <id start="2480001" end="2481024" />
+ </idlist>
+ <idlist idname="door03">
+ <id start="3110001" end="3111024" />
+ <id start="3120001" end="3121024" />
+ <id start="3130001" end="3131024" />
+ <id start="3140001" end="3141024" />
+ <id start="3150001" end="3151024" />
+ <id start="3160001" end="3161024" />
+ <id start="3170001" end="3171024" />
+ <id start="3180001" end="3181024" />
+ <id start="3210001" end="3211024" />
+ <id start="3220001" end="3221024" />
+ <id start="3230001" end="3231024" />
+ <id start="3240001" end="3241024" />
+ <id start="3250001" end="3251024" />
+ <id start="3260001" end="3261024" />
+ <id start="3270001" end="3271024" />
+ <id start="3280001" end="3281024" />
+ <id start="3310001" end="3311024" />
+ <id start="3320001" end="3321024" />
+ <id start="3330001" end="3331024" />
+ <id start="3340001" end="3341024" />
+ <id start="3350001" end="3351024" />
+ <id start="3360001" end="3361024" />
+ <id start="3370001" end="3371024" />
+ <id start="3380001" end="3381024" />
+ <id start="3410001" end="3411024" />
+ <id start="3420001" end="3421024" />
+ <id start="3430001" end="3431024" />
+ <id start="3440001" end="3441024" />
+ <id start="3450001" end="3451024" />
+ <id start="3460001" end="3461024" />
+ <id start="3470001" end="3471024" />
+ <id start="3480001" end="3481024" />
+ </idlist>
+ <idlist idname="door04">
+ <id start="4110001" end="4111024" />
+ <id start="4120001" end="4121024" />
+ <id start="4130001" end="4131024" />
+ <id start="4140001" end="4141024" />
+ <id start="4150001" end="4151024" />
+ <id start="4160001" end="4161024" />
+ <id start="4170001" end="4171024" />
+ <id start="4180001" end="4181024" />
+ <id start="4210001" end="4211024" />
+ <id start="4220001" end="4221024" />
+ <id start="4230001" end="4231024" />
+ <id start="4240001" end="4241024" />
+ <id start="4250001" end="4251024" />
+ <id start="4260001" end="4261024" />
+ <id start="4270001" end="4271024" />
+ <id start="4280001" end="4281024" />
+ <id start="4310001" end="4311024" />
+ <id start="4320001" end="4321024" />
+ <id start="4330001" end="4331024" />
+ <id start="4340001" end="4341024" />
+ <id start="4350001" end="4351024" />
+ <id start="4360001" end="4361024" />
+ <id start="4370001" end="4371024" />
+ <id start="4380001" end="4381024" />
+ <id start="4410001" end="4411024" />
+ <id start="4420001" end="4421024" />
+ <id start="4430001" end="4431024" />
+ <id start="4440001" end="4441024" />
+ <id start="4450001" end="4451024" />
+ <id start="4460001" end="4461024" />
+ <id start="4470001" end="4471024" />
+ <id start="4480001" end="4481024" />
+ </idlist>
+ <idlist idname="door05">
+ <id start="5110001" end="5111024" />
+ <id start="5120001" end="5121024" />
+ <id start="5130001" end="5131024" />
+ <id start="5140001" end="5141024" />
+ <id start="5150001" end="5151024" />
+ <id start="5160001" end="5161024" />
+ <id start="5170001" end="5171024" />
+ <id start="5180001" end="5181024" />
+ <id start="5210001" end="5211024" />
+ <id start="5220001" end="5221024" />
+ <id start="5230001" end="5231024" />
+ <id start="5240001" end="5241024" />
+ <id start="5250001" end="5251024" />
+ <id start="5260001" end="5261024" />
+ <id start="5270001" end="5271024" />
+ <id start="5280001" end="5281024" />
+ <id start="5310001" end="5311024" />
+ <id start="5320001" end="5321024" />
+ <id start="5330001" end="5331024" />
+ <id start="5340001" end="5341024" />
+ <id start="5350001" end="5351024" />
+ <id start="5360001" end="5361024" />
+ <id start="5370001" end="5371024" />
+ <id start="5380001" end="5381024" />
+ <id start="5410001" end="5411024" />
+ <id start="5420001" end="5421024" />
+ <id start="5430001" end="5431024" />
+ <id start="5440001" end="5441024" />
+ <id start="5450001" end="5451024" />
+ <id start="5460001" end="5461024" />
+ <id start="5470001" end="5471024" />
+ <id start="5480001" end="5481024" />
+ </idlist>
+ <idlist idname="door06">
+ <id start="6110001" end="6111024" />
+ <id start="6120001" end="6121024" />
+ <id start="6130001" end="6131024" />
+ <id start="6140001" end="6141024" />
+ <id start="6150001" end="6151024" />
+ <id start="6160001" end="6161024" />
+ <id start="6170001" end="6171024" />
+ <id start="6180001" end="6181024" />
+ <id start="6210001" end="6211024" />
+ <id start="6220001" end="6221024" />
+ <id start="6230001" end="6231024" />
+ <id start="6240001" end="6241024" />
+ <id start="6250001" end="6251024" />
+ <id start="6260001" end="6261024" />
+ <id start="6270001" end="6271024" />
+ <id start="6280001" end="6281024" />
+ <id start="6310001" end="6311024" />
+ <id start="6320001" end="6321024" />
+ <id start="6330001" end="6331024" />
+ <id start="6340001" end="6341024" />
+ <id start="6350001" end="6351024" />
+ <id start="6360001" end="6361024" />
+ <id start="6370001" end="6371024" />
+ <id start="6380001" end="6381024" />
+ <id start="6410001" end="6411024" />
+ <id start="6420001" end="6421024" />
+ <id start="6430001" end="6431024" />
+ <id start="6440001" end="6441024" />
+ <id start="6450001" end="6451024" />
+ <id start="6460001" end="6461024" />
+ <id start="6470001" end="6471024" />
+ <id start="6480001" end="6481024" />
+ </idlist>
+ <idlist idname="door07">
+ <id start="7110001" end="7111024" />
+ <id start="7120001" end="7121024" />
+ <id start="7130001" end="7131024" />
+ <id start="7140001" end="7141024" />
+ <id start="7150001" end="7151024" />
+ <id start="7160001" end="7161024" />
+ <id start="7170001" end="7171024" />
+ <id start="7180001" end="7181024" />
+ <id start="7210001" end="7211024" />
+ <id start="7220001" end="7221024" />
+ <id start="7230001" end="7231024" />
+ <id start="7240001" end="7241024" />
+ <id start="7250001" end="7251024" />
+ <id start="7260001" end="7261024" />
+ <id start="7270001" end="7271024" />
+ <id start="7280001" end="7281024" />
+ <id start="7310001" end="7311024" />
+ <id start="7320001" end="7321024" />
+ <id start="7330001" end="7331024" />
+ <id start="7340001" end="7341024" />
+ <id start="7350001" end="7351024" />
+ <id start="7360001" end="7361024" />
+ <id start="7370001" end="7371024" />
+ <id start="7380001" end="7381024" />
+ <id start="7410001" end="7411024" />
+ <id start="7420001" end="7421024" />
+ <id start="7430001" end="7431024" />
+ <id start="7440001" end="7441024" />
+ <id start="7450001" end="7451024" />
+ <id start="7460001" end="7461024" />
+ <id start="7470001" end="7471024" />
+ <id start="7480001" end="7481024" />
+ </idlist>
+ <idlist idname="door08">
+ <id start="8110001" end="8111024" />
+ <id start="8120001" end="8121024" />
+ <id start="8130001" end="8131024" />
+ <id start="8140001" end="8141024" />
+ <id start="8150001" end="8151024" />
+ <id start="8160001" end="8161024" />
+ <id start="8170001" end="8171024" />
+ <id start="8180001" end="8181024" />
+ <id start="8210001" end="8211024" />
+ <id start="8220001" end="8221024" />
+ <id start="8230001" end="8231024" />
+ <id start="8240001" end="8241024" />
+ <id start="8250001" end="8251024" />
+ <id start="8260001" end="8261024" />
+ <id start="8270001" end="8271024" />
+ <id start="8280001" end="8281024" />
+ <id start="8310001" end="8311024" />
+ <id start="8320001" end="8321024" />
+ <id start="8330001" end="8331024" />
+ <id start="8340001" end="8341024" />
+ <id start="8350001" end="8351024" />
+ <id start="8360001" end="8361024" />
+ <id start="8370001" end="8371024" />
+ <id start="8380001" end="8381024" />
+ <id start="8410001" end="8411024" />
+ <id start="8420001" end="8421024" />
+ <id start="8430001" end="8431024" />
+ <id start="8440001" end="8441024" />
+ <id start="8450001" end="8451024" />
+ <id start="8460001" end="8461024" />
+ <id start="8470001" end="8471024" />
+ <id start="8480001" end="8481024" />
+ </idlist>
+ <idlist idname="door09">
+ <id start="9110001" end="9111024" />
+ <id start="9120001" end="9121024" />
+ <id start="9130001" end="9131024" />
+ <id start="9140001" end="9141024" />
+ <id start="9150001" end="9151024" />
+ <id start="9160001" end="9161024" />
+ <id start="9170001" end="9171024" />
+ <id start="9180001" end="9181024" />
+ <id start="9210001" end="9211024" />
+ <id start="9220001" end="9221024" />
+ <id start="9230001" end="9231024" />
+ <id start="9240001" end="9241024" />
+ <id start="9250001" end="9251024" />
+ <id start="9260001" end="9261024" />
+ <id start="9270001" end="9271024" />
+ <id start="9280001" end="9281024" />
+ <id start="9310001" end="9311024" />
+ <id start="9320001" end="9321024" />
+ <id start="9330001" end="9331024" />
+ <id start="9340001" end="9341024" />
+ <id start="9350001" end="9351024" />
+ <id start="9360001" end="9361024" />
+ <id start="9370001" end="9371024" />
+ <id start="9380001" end="9381024" />
+ <id start="9410001" end="9411024" />
+ <id start="9420001" end="9421024" />
+ <id start="9430001" end="9431024" />
+ <id start="9440001" end="9441024" />
+ <id start="9450001" end="9451024" />
+ <id start="9460001" end="9461024" />
+ <id start="9470001" end="9471024" />
+ <id start="9480001" end="9481024" />
+ </idlist>
+ <idlist idname="door10">
+ <id start="10110001" end="10111024" />
+ <id start="10120001" end="10121024" />
+ <id start="10130001" end="10131024" />
+ <id start="10140001" end="10141024" />
+ <id start="10150001" end="10151024" />
+ <id start="10160001" end="10161024" />
+ <id start="10170001" end="10171024" />
+ <id start="10180001" end="10181024" />
+ <id start="10210001" end="10211024" />
+ <id start="10220001" end="10221024" />
+ <id start="10230001" end="10231024" />
+ <id start="10240001" end="10241024" />
+ <id start="10250001" end="10251024" />
+ <id start="10260001" end="10261024" />
+ <id start="10270001" end="10271024" />
+ <id start="10280001" end="10281024" />
+ <id start="10310001" end="10311024" />
+ <id start="10320001" end="10321024" />
+ <id start="10330001" end="10331024" />
+ <id start="10340001" end="10341024" />
+ <id start="10350001" end="10351024" />
+ <id start="10360001" end="10361024" />
+ <id start="10370001" end="10371024" />
+ <id start="10380001" end="10381024" />
+ <id start="10410001" end="10411024" />
+ <id start="10420001" end="10421024" />
+ <id start="10430001" end="10431024" />
+ <id start="10440001" end="10441024" />
+ <id start="10450001" end="10451024" />
+ <id start="10460001" end="10461024" />
+ <id start="10470001" end="10471024" />
+ <id start="10480001" end="10481024" />
+ </idlist>
+ <idlist idname="door11">
+ <id start="11110001" end="11111024" />
+ <id start="11120001" end="11121024" />
+ <id start="11130001" end="11131024" />
+ <id start="11140001" end="11141024" />
+ <id start="11150001" end="11151024" />
+ <id start="11160001" end="11161024" />
+ <id start="11170001" end="11171024" />
+ <id start="11180001" end="11181024" />
+ <id start="11210001" end="11211024" />
+ <id start="11220001" end="11221024" />
+ <id start="11230001" end="11231024" />
+ <id start="11240001" end="11241024" />
+ <id start="11250001" end="11251024" />
+ <id start="11260001" end="11261024" />
+ <id start="11270001" end="11271024" />
+ <id start="11280001" end="11281024" />
+ <id start="11310001" end="11311024" />
+ <id start="11320001" end="11321024" />
+ <id start="11330001" end="11331024" />
+ <id start="11340001" end="11341024" />
+ <id start="11350001" end="11351024" />
+ <id start="11360001" end="11361024" />
+ <id start="11370001" end="11371024" />
+ <id start="11380001" end="11381024" />
+ <id start="11410001" end="11411024" />
+ <id start="11420001" end="11421024" />
+ <id start="11430001" end="11431024" />
+ <id start="11440001" end="11441024" />
+ <id start="11450001" end="11451024" />
+ <id start="11460001" end="11461024" />
+ <id start="11470001" end="11471024" />
+ <id start="11480001" end="11481024" />
+ </idlist>
+ <idlist idname="door12">
+ <id start="12110001" end="12111024" />
+ <id start="12120001" end="12121024" />
+ <id start="12130001" end="12131024" />
+ <id start="12140001" end="12141024" />
+ <id start="12150001" end="12151024" />
+ <id start="12160001" end="12161024" />
+ <id start="12170001" end="12171024" />
+ <id start="12180001" end="12181024" />
+ <id start="12210001" end="12211024" />
+ <id start="12220001" end="12221024" />
+ <id start="12230001" end="12231024" />
+ <id start="12240001" end="12241024" />
+ <id start="12250001" end="12251024" />
+ <id start="12260001" end="12261024" />
+ <id start="12270001" end="12271024" />
+ <id start="12280001" end="12281024" />
+ <id start="12310001" end="12311024" />
+ <id start="12320001" end="12321024" />
+ <id start="12330001" end="12331024" />
+ <id start="12340001" end="12341024" />
+ <id start="12350001" end="12351024" />
+ <id start="12360001" end="12361024" />
+ <id start="12370001" end="12371024" />
+ <id start="12380001" end="12381024" />
+ <id start="12410001" end="12411024" />
+ <id start="12420001" end="12421024" />
+ <id start="12430001" end="12431024" />
+ <id start="12440001" end="12441024" />
+ <id start="12450001" end="12451024" />
+ <id start="12460001" end="12461024" />
+ <id start="12470001" end="12471024" />
+ <id start="12480001" end="12481024" />
+ </idlist>
+ </instrument>
+
+
+
+.. categories:: Concepts
\ No newline at end of file
diff --git a/Code/Mantid/docs/source/concepts/Lattice.rst b/Code/Mantid/docs/source/concepts/Lattice.rst
index 1d955201ca5f22ac3d0a78bf481a2167caf7903a..6abc28bfc5f3e4c2a86745562c86c5976ada22d6 100644
--- a/Code/Mantid/docs/source/concepts/Lattice.rst
+++ b/Code/Mantid/docs/source/concepts/Lattice.rst
@@ -3,10 +3,6 @@
Lattice
=======
-.. role:: math(raw)
- :format: html latex
-..
-
The purpose of this document is to explain how Mantid is using
information about unit cells and their orientation with respect to the
laboratory frame. For a detailed description, see
@@ -18,9 +14,14 @@ Theory
The physics of a system studied by neutron scattering is described by
the conservation of energy and momentum. In the laboratory frame:
-:math:`Q_l= \hbar \mathbf{k}_i^{} - \hbar \mathbf{k}_f`
+.. math::
+
+ Q_l= \hbar \mathbf{k}_i^{} - \hbar \mathbf{k}_f
+
-:math:`\Delta E_l= \frac{\hbar^2}{2m} (k_i^2 - k_f^2)`
+.. math::
+
+ \Delta E_l= \frac{\hbar^2}{2m} (k_i^2 - k_f^2)
Note that the left side in the above equations refer to what is
happening to the lattice, not to the neutron.
@@ -34,27 +35,26 @@ crystallography.
For such a lattice, the physics will be described in terms of reciprocal
lattice parameters by
-:math:`Q= 2 \pi\left(h \mathbf{a}^* + k \mathbf{b}^* +l \mathbf{c}^* \right) = \left(\begin{array}{c}
+.. math::
+
+ Q= 2 \pi\left(h \mathbf{a}^* + k \mathbf{b}^* +l \mathbf{c}^* \right) = \left(\begin{array}{c}
h \\
-
k \\
-
l
+ \end{array}\right)
- \end{array}\right)`.
The :math:`UB_{}^{}` matrix formalism relates :math:`Q_l^{}` and
:math:`Q_{}^{}` with the following equation:
-:math:`Q_l = 2 \pi R \cdot U \cdot B \left(\begin{array}{c}
- h \\
+.. math::
+ Q_l = 2 \pi R \cdot U \cdot B \left(\begin{array}{c}
+ h \\
k \\
-
l
-
- \end{array}\right)`
+ \end{array}\right)
The :math:`B_{}^{}` matrix transforms the :math:`h^{}_{}, k, l` triplet
into a Cartesian system, with the first axis along
@@ -64,10 +64,12 @@ perpendicular to this plane. In the Busing and Levi convention (W. R.
Busing and H. A. Levy, Angle calculations for 3- and 4-circle X-ray and
neutron diffractometers - Acta Cryst. (1967). 22, 457-464):
-:math:`B = \left( \begin{array}{ccc}
+.. math::
+
+ B = \left( \begin{array}{ccc}
a^* & b^*\cos(\gamma^*) & c^*\cos(\beta^*) \\
0 & b^*\sin(\gamma^*) & -c^*\sin(\beta^*)\cos(\alpha) \\
- 0 & 0 & 1/c \end{array} \right)`
+ 0 & 0 & 1/c \end{array} \right)
The :math:`U_{}^{}` matrix represents the rotation from this Cartesian
coordinate frame to the Cartesian coordinate frame attached to the
@@ -77,26 +79,30 @@ The :math:`R_{}^{}` matrix is the rotation matrix of the goniometer
Other useful equations:
-:math:`G^* = (UB)^T UB = B^T B = \left( \begin{array}{ccc}
+
+.. math::
+ G^* = (UB)^T UB = B^T B = \left( \begin{array}{ccc}
a^*a^* & a^*b^*\cos(\gamma^*) & a^*c^*\cos(\beta^*) \\
a^*b^*\cos(\gamma^*) & b^*b^* & b^*c^*\cos(\alpha^*) \\
- a^*c^*\cos(\beta^*) & b^*c^*\cos(\alpha^*) & c^*c^* \end{array} \right)`
+ a^*c^*\cos(\beta^*) & b^*c^*\cos(\alpha^*) & c^*c^* \end{array} \right)
+
-:math:`G=(G^*)^{-1}=\left( \begin{array}{ccc}
+.. math::
+ G=(G^*)^{-1}=\left( \begin{array}{ccc}
aa & ab\cos(\gamma) & ac\cos(\beta) \\
ab\cos(\gamma) & bb & bc\cos(\alpha) \\
- ac\cos(\beta) & bc\cos(\alpha) & cc \end{array} \right)`
+ ac\cos(\beta) & bc\cos(\alpha) & cc \end{array} \right)
The distance in reciprocal space to the :math:`\left(h,k,l\right)` plane
-is given by :math:`d^* =\left| B \left(\begin{array}{c}
+is given by
+.. math::
+
+ d^* =\left| B \left(\begin{array}{c}
h \\
-
k \\
-
l
-
- \end{array}\right)\right|`
+ \end{array}\right)\right|
The distance in real space to the :math:`\left(h,k,l\right)` plane is
given by :math:`d=\frac{1}{d^*}`
@@ -109,7 +115,7 @@ Unit cells
The UnitCell class provides the following functions to access direct and
reciprocal lattices. The examples can be run from the script console in
-Mantid
+Mantid
+------------------------------------------------+---------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Function | Example | Description |
@@ -229,18 +235,18 @@ defined for OrientedLattice only:
| | getUB() | | print u.getU() | |
| | | print u.getUB() | |
+-------------------------------------------------------+----------------------------------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-| | setU() | | o.OrientedLattice(2,3.5,4) | sets the :math:`U^{}_{}` and :math:`UB^{}_{}` matrices. for setUB function, it will calculate first the lattice parameters, then the :math:`B^{}_{}` matrix, and then :math:`U^{}_{}`. See `#Note about orientation <#Note_about_orientation>`__ |
+| | setU() | | o.OrientedLattice(2,3.5,4) | sets the :math:`U^{}_{}` and :math:`UB^{}_{}` matrices. for setUB function, it will calculate first the lattice parameters, then the :math:`B^{}_{}` matrix, and then :math:`U^{}_{}`. See `Note about orientation`_ |
| | setUB() | | newU=array([[0,1,0],[1,0,0],[0,0,-1]]) | |
| | | o.setU(newU) | |
| | | newUB=array([[2,1,0],[1,2,0],[2,0,-1]]) | |
| | | o.setUB(newUB) | |
+-------------------------------------------------------+----------------------------------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-| setUFromVectors(v1,v2) | | o.OrientedLattice(2,3.5,4) | recalculates and sets the :math:`U^{}_{}` matrix, such as the first vector is along the beam direction, and the second vector is in the horizontal plane. See `#Note about orientation <#Note_about_orientation>`__. In python, the v1 and v2 vectors can be of type V3D, or length 3 list, or length 3 numpy array, not necessarily the same |
+| setUFromVectors(v1,v2) | | o.OrientedLattice(2,3.5,4) | recalculates and sets the :math:`U^{}_{}` matrix, such as the first vector is along the beam direction, and the second vector is in the horizontal plane. See `Note about orientation`_. In python, the v1 and v2 vectors can be of type V3D, or length 3 list, or length 3 numpy array, not necessarily the same |
| | | o.setUFromVectors([1,0,0],[0,1,0]) | |
| | | o.setUFromVectors(array([1,0,0]),array([0,1,0])) | |
| | | o.setUFromVectors(V3D(1,0,0),V3D(0,1,0)) | |
+-------------------------------------------------------+----------------------------------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-| | getuVector() | | o.OrientedLattice(2,3.5,4) | getuVector returns a vector along beam direction, while getvVector returns a vector in the horizontal plane, perpendicular to the beam direction (see `http://horace.isis.rl.ac.uk/Getting_started <http://horace.isis.rl.ac.uk/Getting_started>`__). See `#Note about orientation <#Note_about_orientation>`__ |
+| | getuVector() | | o.OrientedLattice(2,3.5,4) | getuVector returns a vector along beam direction, while getvVector returns a vector in the horizontal plane, perpendicular to the beam direction (see `http://horace.isis.rl.ac.uk/Getting_started <http://horace.isis.rl.ac.uk/Getting_started>`__). See `Note about orientation`_ |
| | getvVector() | | o.setUFromVectors([5,5,0],[-2,1,0]) | |
| | | print o.getuVector() | |
| | | print o.getvVector() | |
@@ -255,10 +261,12 @@ direction. For an orthogonal lattice with :math:`\mathbf{a}^*` along
:math:`\mathbf{c}^*` along :math:`\mathbf{y}`, the :math:`U^{}_{}`
matrix has the form:
-:math:`U = \left( \begin{array}{ccc}
+.. math::
+
+ U = \left( \begin{array}{ccc}
0 & 1 & 0 \\
0 & 0 & 1 \\
- 1 & 0 & 0 \end{array} \right)`
+ 1 & 0 & 0 \end{array} \right)
diff --git a/Code/Mantid/docs/source/concepts/MDHistoWorkspace.rst b/Code/Mantid/docs/source/concepts/MDHistoWorkspace.rst
index 622926d68137688bfe5e2f2982a5025180909ff4..96b00dbbdf396a62650d1d7bc944cc4c63ffc5e6 100644
--- a/Code/Mantid/docs/source/concepts/MDHistoWorkspace.rst
+++ b/Code/Mantid/docs/source/concepts/MDHistoWorkspace.rst
@@ -4,14 +4,14 @@ MDHistoWorkspace
================
The MDHistoWorkspace is a simple multi-dimensional workspace. In
-contrast to the `MDEventWorkspace <MDEventWorkspace>`__, which contains
+contrast to the :ref:`MDWorkspace <MDWorkspace>`, which contains
points in space, the MDHistoWorkspace consists of a signal and error
spread around space on a regular grid.
In a way, the MDHistoWorkspace is to a
-`MDEventWorkspace <MDEventWorkspace>`__ is what the
-`Workspace2D <Workspace2D>`__ is to the
-`EventWorkspace <EventWorkspace>`__.
+:ref:`MDWorkspace <MDWorkspace>` is what the
+:ref:`Workspace2D <Workspace2D>` is to the
+:ref:`EventWorkspace <EventWorkspace>`.
Creating a MDHistoWorkspace
---------------------------
@@ -19,30 +19,30 @@ Creating a MDHistoWorkspace
MDHistoWorkspaces typically have 3 or 4 dimensions, although they can be
created in up to 9 dimensions.
-- You can bin a `MDEventWorkspace <MDEventWorkspace>`__ to a
- MDHistoWorkspace using the `BinMD <BinMD>`__ algorithm.
+- You can bin a :ref:`MDWorkspace <MDWorkspace>` to a
+ MDHistoWorkspace using the :ref:`BinMD <algm-BinMD>` algorithm.
- - You can use `CreateMDWorkspace <CreateMDWorkspace>`__ to create a
- blank MDEventWorkspace first, if you do not have data to bin.
+ - You can use :ref:`CreateMDWorkspace <algm-CreateMDWorkspace>` to create a
+ blank MDWorkspace first, if you do not have data to bin.
-- `Paraview <Paraview>`__ and the `Vates Simple
- Interface <VatesSimpleInterface>`__ will create a MDHistoWorkspace
- from a `MDWorkspace <MDWorkspace>`__ when rebinning on a regular
+- Paraview and the `Vates Simple
+ Interface <http://www.mantidproject.org/VatesSimpleInterface>`__ will create a MDHistoWorkspace
+ from a :ref:`MDWorkspace <MDWorkspace>` when rebinning on a regular
grid.
Viewing a MDHistoWorkspace
--------------------------
- MDHistoWorkspaces can be created and visualized directly within
- `Paraview <Paraview>`__ and the `Vates Simple
- Interface <VatesSimpleInterface>`__ when rebinning along a regular
+ Paraview and the `Vates Simple
+ Interface <http://www.mantidproject.org/VatesSimpleInterface>`__ when rebinning along a regular
grid.
- You can right-click on the workspace and select:
- **Plot MD**: to perform a 1D plot of the signal in the workspace
(only works on 1D MDHistoWorkspaces).
- **Show Slice Viewer**: to open the `Slice
- Viewer <MantidPlot:_SliceViewer>`__, which shows 2D slices of the
+ Viewer <http://www.mantidproject.org/MantidPlot:_SliceViewer>`__, which shows 2D slices of the
multiple-dimension workspace.
Arithmetic Operations
@@ -51,10 +51,10 @@ Arithmetic Operations
The following algorithms allow you to perform simple arithmetic on the
values:
-- `MinusMD <MinusMD>`__, `PlusMD <PlusMD>`__, `DivideMD <DivideMD>`__,
- `MultiplyMD <MultiplyMD>`__
-- `ExponentialMD <ExponentialMD>`__, `PowerMD <PowerMD>`__,
- `LogarithmMD <LogarithmMD>`__
+- :ref:`MinusMD <algm-MinusMD>`, :ref:`PlusMD <algm-PlusMD>`, :ref:`DivideMD <algm-DivideMD>`,
+ :ref:`MultiplyMD <algm-MultiplyMD>`
+- :ref:`ExponentialMD <algm-ExponentialMD>`, :ref:`PowerMD <algm-PowerMD>`,
+ :ref:`LogarithmMD <algm-LogarithmMD>`
These arithmetic operations propagate errors as described
`here <http://en.wikipedia.org/wiki/Propagation_of_uncertainty#Example_formulas>`__.
@@ -91,13 +91,13 @@ case, 0.0 is "false" and 1.0 is "true".
The following operations can create a boolean MDHistoWorkspace:
-- `LessThanMD <LessThanMD>`__, `GreaterThanMD <GreaterThanMD>`__,
- `EqualToMD <EqualToMD>`__
+- :ref:`LessThanMD <algm-LessThanMD>`, :ref:`GreaterThanMD <algm-GreaterThanMD>`,
+ :ref:`EqualToMD <algm-EqualToMD>`
These operations can combine/modify boolean MDHistoWorkspaces:
-- `NotMD <NotMD>`__, `AndMD <AndMD>`__, `OrMD <OrMD>`__,
- `XorMD <XorMD>`__
+- :ref:`NotMD <algm-NotMD>`, :ref:`AndMD <algm-AndMD>`, :ref:`OrMD <algm-OrMD>`,
+ :ref:`XorMD <algm-XorMD>`
These boolean operators are available from python. Make sure you use the
bitwise operators: & \| ^ ~ , not the "word" operators (and, or, not).
@@ -121,9 +121,9 @@ For example:
Using Boolean Masks
^^^^^^^^^^^^^^^^^^^
-The `SetMDUsingMask <SetMDUsingMask>`__ algorithm allows you to modify
+The :ref:`SetMDUsingMask <algm-SetMDUsingMask>` algorithm allows you to modify
the values in a MDHistoWorkspace using a mask created using the boolean
-operations above. See the `algorithm wiki page <SetMDUsingMask>`__ for
+operations above. See the `algorithm wiki page <algm-SetMDUsingMask>`__ for
more details.
diff --git a/Code/Mantid/docs/source/concepts/MDWorkspace.rst b/Code/Mantid/docs/source/concepts/MDWorkspace.rst
index 804a8434a6d692bad267e8a152f93eeece67a3d5..c480781baf8c212d0f1776739810b0ff5ea808ee 100644
--- a/Code/Mantid/docs/source/concepts/MDWorkspace.rst
+++ b/Code/Mantid/docs/source/concepts/MDWorkspace.rst
@@ -6,7 +6,7 @@ MDWorkspace
The MDWorkspace (short for "Multi-Dimensional" Workspace) is a generic
data structure holdings points (MDEvents) that are defined by their
position in several dimensions. See also
-`MDHistoWorkspace <MDHistoWorkspace>`__.
+:ref:`MDHistoWorkspace <MDHistoWorkspace>`.
Description of MDWorkspace
--------------------------
@@ -39,12 +39,12 @@ the boxes are organized into a recursive boxing structure (adaptive mesh
refinement). During MDWorkspace construction, if a MDBox is found to
contain too many events, it will be split into smaller boxes.
-.. figure:: MDWorkspace_structure.png
+.. figure:: ../images/MDWorkspace_structure.png
:alt: MDWorkspace_structure.png
MDWorkspace\_structure.png
The threshold for splitting is defined in
-`CreateMDWorkspace <CreateMDWorkspace>`__ as the SplitThreshold
+:ref:`CreateMDWorkspace <algm-CreateMDWorkspace>` as the SplitThreshold
parameter. Each parent box will get split into N sub-boxes in each
dimension. For example, in a 2D workspace, you might split a parent box
into 4x4 sub-boxes, creating 16 MDBoxes under the parent box (which
@@ -56,17 +56,17 @@ Creating a MDWorkspace
There are several algorithms that will create a MDWorkspace:
-- `CreateMDWorkspace <CreateMDWorkspace>`__ creates a blank MDWorkspace
+- :ref:`CreateMDWorkspace <algm-CreateMDWorkspace>` creates a blank MDWorkspace
with any arbitrary set of dimensions.
-- `ConvertToDiffractionMDWorkspace <ConvertToDiffractionMDWorkspace>`__
- converts an `EventWorkspace <EventWorkspace>`__ or
- `Workspace2D <Workspace2D>`__ from detector space to reciprocal
+- :ref:`ConvertToDiffractionMDWorkspace <algm-ConvertToDiffractionMDWorkspace>`
+ converts an :ref:`EventWorkspace <EventWorkspace>` or
+ :ref:`Workspace2D <Workspace2D>` from detector space to reciprocal
space, for elastic single-crystal or powder diffraction experiments.
-- `ConvertToMDEvents <ConvertToMDEvents>`__ converts workspaces for
+- :ref:`ConvertToMD <algm-ConvertToMD>` converts workspaces for
inelastic experiments.
-- `SliceMD <SliceMD>`__ takes a slice out of a MDWorkspace to create a
+- :ref:`SliceMD <algm-SliceMD>` takes a slice out of a MDWorkspace to create a
new one.
-- `LoadSQW <LoadSQW>`__ converts from the SQW format.
+- :ref:`LoadSQW <algm-LoadSQW>` converts from the SQW format.
File-Backed MDWorkspaces
------------------------
@@ -75,9 +75,9 @@ For workspaces with a large number of events that would not fit in
memory, it is possible to use a NXS file back-end as a data store. The
box structure will always remain in memory, but the underlying events
will be stored in a file and retrieved only when required. This can be
-set at creation (`CreateMDWorkspace <CreateMDWorkspace>`__) or when
+set at creation (:ref:`CreateMDWorkspace <algm-CreateMDWorkspace>`) or when
loading from a file, or an in-memory MDWorkspace can be converted to
-file-backed with the `SaveMD <SaveMD>`__ algorithm.
+file-backed with the :ref:`SaveMD <algm-SaveMD>` algorithm.
Because of disk IO, file-backed MDWorkspaces are slower to process for
some operations (e.g. binning or slicing). Some types of visualization
@@ -90,15 +90,15 @@ Viewing MDWorkspaces
- Right-click on a MDWorkspace and select:
- **Show Vates Simple Interface**: to open a `simplified 3D
- view <VatesSimpleInterface>`__ based on `Paraview <Paraview>`__.
+ view <http://www.mantidproject.org/VatesSimpleInterface>`__ based on Paraview.
- **Show Slice Viewer**: to open the `Slice
- Viewer <MantidPlot:_SliceViewer>`__, which shows 2D slices of the
+ Viewer <http://www.mantidproject.org/MantidPlot:_SliceViewer>`__, which shows 2D slices of the
multiple-dimensional workspace.
- You can also `use Python script to open the
- SliceViewer <SliceViewer Python Interface>`__.
+ SliceViewer <http://www.mantidproject.org/SliceViewer_Python_Interface>`__.
-Or, you can load a MDWorkspace .nxs file in `Paraview <Paraview>`__ if
+Or, you can load a MDWorkspace .nxs file in Paraview if
the proper plugin is installed.
diff --git a/Code/Mantid/docs/source/concepts/MatrixWorkspace.rst b/Code/Mantid/docs/source/concepts/MatrixWorkspace.rst
index 95e58ef449f5775a5b45f09cc4e7be0340798b75..ff20b14741e329dc0b0cfedad1f1887584aaeb3e 100644
--- a/Code/Mantid/docs/source/concepts/MatrixWorkspace.rst
+++ b/Code/Mantid/docs/source/concepts/MatrixWorkspace.rst
@@ -12,11 +12,11 @@ Mandatory:
Optionally:
-- `Axes <Interacting_with_Workspaces#Axes>`__ with
- `Units <Unit Factory>`__
+- `Axes <http://www.mantidproject.org/Interacting_with_Workspaces#Axes>`__ with
+ :ref:`Units <Unit Factory>`
- Sample and sample environment data
- Run logs
-- A full `instrument <instrument>`__ geometric definition, along with
+- A full :ref:`instrument <instrument>` geometric definition, along with
an instrument parameter map
- A spectra - detector map
- A distribution flag
@@ -28,13 +28,13 @@ Concrete Matrix Workspaces
- WorkspaceSingleValue - Holds a single number (and X & error value, if
desired). Mainly used for workspace algebra, e.g. to divide all bins
in a 2D workspace by a single value.
-- `Workspace2D <Workspace2D>`__ - A workspace for holding two
+- :ref:`Workspace2D <Workspace2D>` - A workspace for holding two
dimensional data in memory. This is the most commonly used workspace.
-- `EventWorkspace <EventWorkspace>`__ - A workspace that retains the
+- :ref:`EventWorkspace <EventWorkspace>` - A workspace that retains the
individual neutron event data.
More information on working with them: `Interacting with Matrix
-Workspaces <Interacting with Matrix Workspaces>`__.
+Workspaces <http://www.mantidproject.org/Interacting_with_Workspaces>`__.
diff --git a/Code/Mantid/docs/source/concepts/Nexus_file.rst b/Code/Mantid/docs/source/concepts/Nexus_file.rst
index 6b233d12d9ab427b67ffde74719670abad84c13c..8c22396d56d76ffa003b01df862a56f9744b461e 100644
--- a/Code/Mantid/docs/source/concepts/Nexus_file.rst
+++ b/Code/Mantid/docs/source/concepts/Nexus_file.rst
@@ -8,8 +8,8 @@ and by MantidPlot. The format appears to be like an XML file plus some
unprintable characters.
ManditPlot is capable of saving certain types of
-`workspace <workspace>`__ as a Nexus file. It can also save a
-`project <project>`__ as a mantid file plus Nexus files.
+:ref:`workspace <workspace>` as a Nexus file. It can also save a
+:ref:`project <project>` as a mantid file plus Nexus files.
Structure
---------
@@ -19,7 +19,7 @@ To be completed.
See also
--------
-`RAW File <RAW File>`__ an older data file format.
+:ref:`RAW File <RAW File>` an older data file format.
diff --git a/Code/Mantid/docs/source/concepts/Plugin.rst b/Code/Mantid/docs/source/concepts/Plugin.rst
index 8184f95fabdf5077f473f71fa6cf860cedd6308c..c726e639f87944548d8ccf3c6dc20ea623d577e3 100644
--- a/Code/Mantid/docs/source/concepts/Plugin.rst
+++ b/Code/Mantid/docs/source/concepts/Plugin.rst
@@ -22,13 +22,13 @@ functionality that you need. Within the outputs of the Mantid project
Several of the libraries we deliver are created as plugins. Examples
are:
-- MantidAlgorithms - Contains the general `algorithms <Algorithm>`__
+- MantidAlgorithms - Contains the general :ref:`algorithms <Algorithm>`
- MantidDataHandling - Contains the basic data loading and saving
- `algorithms <Algorithm>`__
-- MantidNexus - Contains the `algorithms <Algorithm>`__ for handling
+ :ref:`algorithms <Algorithm>`
+- MantidNexus - Contains the :ref:`algorithms <Algorithm>` for handling
nexus files
- MantidDataObjects - Contains the definitions of the standard
- `workspaces <Workspace>`__
+ :ref:`workspaces <Workspace>`
How can you extend Mantid?
--------------------------
@@ -37,9 +37,9 @@ The following areas have been designed to be easily extensible through
using plugins. Each one contains more details in case you wish to create
one of your own.
-- `Algorithm <Algorithm>`__
-- `Workspace <Workspace>`__
-- `Unit <Unit>`__
+- :ref:`Algorithm <Algorithm>`
+- :ref:`Workspace <Workspace>`
+- Unit
How do you create a plugin?
---------------------------
@@ -60,8 +60,8 @@ user (or other code) does not need to know what the algorithm actually
is, just that it is an algorithm.
In addition each of the extensible units has a macro that adds some code
-that automatically registers the class with the appropriate `dynamic
-factory <Dynamic_Factory>`__. This code executes immediately when the
+that automatically registers the class with the appropriate :ref:`dynamic
+factory <Dynamic Factory>`. This code executes immediately when the
library is loaded and is what makes you new objects available for use.
All of these macros start DECLARE and, for example, the one for
algorithms is:
diff --git a/Code/Mantid/docs/source/concepts/Project.rst b/Code/Mantid/docs/source/concepts/Project.rst
index 3972edb7c759bba6fa1f0f873445f21abfc66f52..20f273f1e967a6767e5479e9c773091585036784 100644
--- a/Code/Mantid/docs/source/concepts/Project.rst
+++ b/Code/Mantid/docs/source/concepts/Project.rst
@@ -10,8 +10,8 @@ project.
What a Project Consists of
--------------------------
-A project consists of a .mantid file and a collection of `Nexus
-files <Nexus file>`__ it refers to. For this reason, a project is put
+A project consists of a .mantid file and a collection of :ref:`Nexus
+files <Nexus file>` it refers to. For this reason, a project is put
into its own folder when saved.
See Also
diff --git a/Code/Mantid/docs/source/concepts/Properties.rst b/Code/Mantid/docs/source/concepts/Properties.rst
index ca99e0d6fa34050c8ce95dd3ccba3a6f98180df0..333a2841af283ee9538b47183f5b9eee875f2c63 100644
--- a/Code/Mantid/docs/source/concepts/Properties.rst
+++ b/Code/Mantid/docs/source/concepts/Properties.rst
@@ -4,7 +4,7 @@ Properties
==========
Properties in Mantid are the mechanism by which we pass parameters into
-`algorithms <algorithm>`__. There are a number of different types of
+:ref:`algorithms <algorithm>`. There are a number of different types of
properties, and these are described below.
Types of Properties
@@ -16,16 +16,14 @@ Single Value Properties
This is the simplest type of property, which is essentially a name-value
pair. Currently, single value properties of type integer (``int``),
floating point (``double``), string (``std::string``) and boolean
-(``bool``) are supported. The C++ class which implements this kind of
-property is called
-`PropertyWithValue <http://doxygen.mantidproject.org/classMantid_1_1Kernel_1_1PropertyWithValue.html>`__.
+(``bool``) are supported. .
Array Properties
~~~~~~~~~~~~~~~~
Sometimes, a multi-element parameter may be required (a list of spectra
to process, for example). This is achieved using an
-`ArrayProperty <http://doxygen.mantidproject.org/classMantid_1_1Kernel_1_1ArrayProperty.html>`__
+ArrayProperty
(which is actually a PropertyWithValue - see above - of type
std::vector). It can be created in a number of ways:
@@ -51,7 +49,7 @@ File Properties
These properties are for capturing and holding the path and filename to
an external file. File properties have a FileAction property that
-controls it's purpose and behavior.
+controls it's purpose and behaviour.
Save :to specify a file to write to, the file may or may not exist
OptionalSave :to specify a file to write to but an empty string is
@@ -66,13 +64,12 @@ search for matching files in this order:
#. The current directory
#. The entries in order from the datasearch.directories entry in the
- `Properties File <Properties File#Directory_Properties>`__
+ :ref:`Properties File <Properties File>`
If the file property is has a FileAction of Save as is given a relative
path (such as "input.txt" or "\\data\\input.txt" as its value it will
-assume that path starts from the location definied in the
-defaultsave.directory entry in the `Properties
-File <Properties File#Directory_Properties>`__.
+assume that path starts from the location defined in the
+defaultsave.directory entry in the :ref:`Properties File <Properties File>`.
A FileProperty can be declared in a algorithm as follows:
@@ -88,22 +85,21 @@ or for saving a file providing a suggested extension
Workspace Properties
~~~~~~~~~~~~~~~~~~~~
-Properties for holding `workspaces <workspace>`__ are more complicated,
+Properties for holding :ref:`workspaces <workspace>` are more complicated,
in that they need to hold links both to the workspace name (in the
-`Analysis Data Service <Analysis Data Service>`__) and the workspace
+:ref:`Analysis Data Service <Analysis Data Service>`) and the workspace
itself. When setting or retrieving the value as a string (i.e. using the
``setValue`` or ``value`` methods) you are interacting with the
-workspace's name; other methods interact with a `shared
-pointer <Shared Pointer>`__ to the workspace.
+workspace's name; other methods interact with a :ref:`shared
+pointer <Shared Pointer>` to the workspace.
-The syntax to declare a
-`WorkspaceProperty <http://doxygen.mantidproject.org/classMantid_1_1API_1_1WorkspaceProperty.html>`__
+The syntax to declare a WorkspaceProperty
in an algorithm is:
``declareProperty(new WorkspaceProperty("PropertyName","WorkspaceName",direction));``
In this case, the direction (see below) must be explicitly declared. An
-optional `validator <Properties#Validators>`__ may also be appended to
+optional :ref:`validator <Properties#Validators>` may also be appended to
the above declaration.
Other 'Property Properties'
diff --git a/Code/Mantid/docs/source/concepts/Properties_File.rst b/Code/Mantid/docs/source/concepts/Properties_File.rst
index 8be3575067c123553bf6b9f3549ff183e9d47c9e..e0b27bbc087869f68bc1d5a96af6a26d76efb80d 100644
--- a/Code/Mantid/docs/source/concepts/Properties_File.rst
+++ b/Code/Mantid/docs/source/concepts/Properties_File.rst
@@ -1,7 +1,165 @@
.. _Properties File:
-Properties_File
+Properties File
===============
+The two .Properties Files
+-------------------------
+
+The Mantid framework is configured using two simple text .properties files that are read an interpreted every time the framework is started. These properties are not the same as the properties of algorithms.
+
+Mantid.Properties
+*****************
+
+This file defines the default configuration that the development team suggest as sensible defaults. This file should not be altered by users as it will be replaced with every new install or upgrade of Mantid.
+
+Mantid.User.Properties
+**********************
+
+This is where users may override any property setting in Mantid. Any Property setting in this file will override anything set in the Mantid.Properties file. Simply either enter the property you wish to override in this file together with it's new value. The change will take effect the next time Mantid is started. Subsequent installs or upgrades of Mantid will never alter this file.
+
+The Properties
+--------------
+
+Note: Use forward slash (/) or double up on the number of backslash (\) characters for all paths
+
+General properties
+******************
+
++------------------------------+---------------------------------------------------+-------------+
+|Property |Description |Example value|
++==============================+===================================================+=============+
+|algorithms.retained |The Number of algorithms properties to retain in | 50 |
+| |memory for refence in scripts. | |
++------------------------------+---------------------------------------------------+-------------+
+|algorithms.categories.hidden |A comma separated list of any categories of | Mouns, Test |
+| |algorithms that should be hidden in Mantid. | Category |
++------------------------------+---------------------------------------------------+-------------+
+|AlgorithmChaining.SwitchedOn |Algorithm chain re-running will replay any | 0 or 1 |
+| |subsequent algorithms whenever a workspace is | |
+| |replaced. | |
+| | | |
+| |This was an early implementation and its use is | |
+| |no longer advised as it could cause race conditions| |
+| |when combined with scripts. | |
++------------------------------+---------------------------------------------------+-------------+
+|MultiThreaded.MaxCores |Sets the maximum number of cores available to be | 0 |
+| |used for threads for OpenMP. If zero it will use | |
+| |one thread per logical core available. | |
++------------------------------+---------------------------------------------------+-------------+
+
+Facility and instrument properties
+**********************************
+
++------------------------------+---------------------------------------------------+-------------+
+|Property |Description |Example value|
++==============================+===================================================+=============+
+|default.facility |The name of the default facility. The facility must| ISIS |
+| |be defined within the facilites.xml file to be | |
+| |considered valid. The file is described here. | |
+| |:ref:`here <Facilities file>`. | |
++------------------------------+---------------------------------------------------+-------------+
+|default.instrument |The name of the default instrument. The instrument | WISH |
+| |must be defined within the facilities.xml file to | |
+| |be valid. The file is described | |
+| |:ref:`here <Facilities file>`. | |
++------------------------------+---------------------------------------------------+-------------+
+
+Directory Properties
+********************
+
++--------------------------------+---------------------------------------------------+-----------------------+
+|Property |Description |Example value |
++================================+===================================================+=======================+
+|datasearch.directories |A semi-colon(;) separated list of directories to |../data; |
+| |use to search for data. |\\\\isis\\isis$\\ndxgem|
++--------------------------------+---------------------------------------------------+-----------------------+
+|defaultsave.directory |A default directory to use for saving files. |../data |
+| |the data archive | |
++--------------------------------+---------------------------------------------------+-----------------------+
+|instrumentDefinition.directory |Where to load instrument definition files from |../Test/Instrument |
++--------------------------------+---------------------------------------------------+-----------------------+
+|parameterDefinition.directory |Where to load parameter definition files from |../Test/Instrument |
++--------------------------------+---------------------------------------------------+-----------------------+
+|pythonscripts.directories |Python will also search the listed directories when|../scripts; |
+| |importing modules. |C:/MyScripts |
++--------------------------------+---------------------------------------------------+-----------------------+
+|pythonscripts.directory |DEPRECATED: Use pythonscripts.directories |../scripts |
+| |A single location for the Python scripts directory | |
++--------------------------------+---------------------------------------------------+-----------------------+
+|requiredpythonscript.directories|A list of directories containing Python scripts |../scripts/SANS; |
+| |that Mantid requires to function correctly. |../scripts/Excitations |
+| |WARNING: Do not alter the default value. | |
++--------------------------------+---------------------------------------------------+-----------------------+
+|plugins.directory |The path to the directory that contains the Mantid |../Plugins |
+| |plugin libraries | |
++--------------------------------+---------------------------------------------------+-----------------------+
+|requiredpythonscript.directories|A list of directories containing Python scripts |../scripts/SANS; |
+| |that Mantid requires to function correctly. |../scripts/Excitations |
+| |WARNING: Do not alter the default value. | |
++--------------------------------+---------------------------------------------------+-----------------------+
+
+
+
+Logging Properties
+******************
+
+The details of configuring the logging functionality within Mantid will not be explained here. For those who want more details look into the POCO logging classes and the Log4J logging module that it closely emulates. There are several comments in the properties file itself that explain the configuration we provide by default.However there are some obvious areas that you may want to alter and those properties are detailed below.
+
++----------------------------------------+---------------------------------------------------+-----------------------+
+|Property |Description |Example value |
++========================================+===================================================+=======================+
+|logging.loggers.root.level |Defines the lowest level of messages to be output |debug, informtion, |
+| |by the system. The default is information, but this|notice, warning, |
+| |can be lowered to debug for more detailed feedback.|error, critical |
+| | |or fatal |
++----------------------------------------+---------------------------------------------------+-----------------------+
+|logging.channels.fileFilterChannel.level|The lowest level messages to output to the log |debug, informtion, |
+| |file. The default is warning, but this can be |notice, warning, |
+| |lowered to debug for more detailed feedback. The |error, critical |
+| |higher level of this and logging.loggers.root.level|or fatal |
+| |will apply. | |
++----------------------------------------+---------------------------------------------------+-----------------------+
+|logging.channels.fileChannel.path | The Path to the log file. |../logs/mantid.log |
++----------------------------------------+---------------------------------------------------+-----------------------+
+
+MantidPlot Properties
+*********************
+
++--------------------------------------+---------------------------------------------------+-----------------------+
+|Property |Description |Example value |
++======================================+===================================================+=======================+
+|MantidOptions.InvisibleWorkspaces |Do not show 'invisible' workspaces |0, 1 |
++--------------------------------------+---------------------------------------------------+-----------------------+
+|MantidOptions.InstrumentView.UseOpenGL|Controls the use of OpenGL in rendering the |On, Off |
+| |"unwrapped" (flat) instrument views. | |
++--------------------------------------+---------------------------------------------------+-----------------------+
+
+ScriptRepository Properties
+***************************
+
++-----------------------+-----------------------------------------------+----------------------------------------------------------------+
+|Property |Description |Example value |
++=======================+===============================================+================================================================+
+|ScriptLocalRepository |Directory where ScriptRepository is Installed. |c:\MantidInstall\MyScriptRepository |
++-----------------------+-----------------------------------------------+----------------------------------------------------------------+
+|ScriptRepository |URL for the remote script repository. |http://download.mantidproject.org/scriptrepository/ |
++-----------------------+-----------------------------------------------+----------------------------------------------------------------+
+|UploaderWebServer |URL for uploading scripts. |http://upload.mantidproject.org/scriptrepository/payload/publish|
++-----------------------+-----------------------------------------------+----------------------------------------------------------------+
+|ScriptRepositoryIgnore |CSV patterns for paths that should not be |*pyc; |
+| |listed at ScriptRepository. | |
++-----------------------+-----------------------------------------------+----------------------------------------------------------------+
+
+
+Getting access to Mantid properties
+***********************************
+
+To get access to, e.g. data saving path property from a C++ program one has to issue the following command:
+
+
+.. testcode:: properties
+
+ path = ConfigService.getString("defaultsave.directory")
.. categories:: Concepts
\ No newline at end of file
diff --git a/Code/Mantid/docs/source/concepts/RAW_File.rst b/Code/Mantid/docs/source/concepts/RAW_File.rst
index 4816964d89afdbd4738b3ccf4b0504ddeb603652..1b917b56ab569d1b2059e9157abd3e1df3babe6c 100644
--- a/Code/Mantid/docs/source/concepts/RAW_File.rst
+++ b/Code/Mantid/docs/source/concepts/RAW_File.rst
@@ -78,7 +78,7 @@ More information about Alternate Data Streams
See also
~~~~~~~~
-`Nexus file <Nexus file>`__ a newer type of data file
+:ref:`Nexus file <Nexus file>` a newer type of data file
diff --git a/Code/Mantid/docs/source/concepts/Run.rst b/Code/Mantid/docs/source/concepts/Run.rst
index 53df6475223985e8cb27309e824841423ed815e0..0241d53047a51ef59f77432236db01cf6197f76b 100644
--- a/Code/Mantid/docs/source/concepts/Run.rst
+++ b/Code/Mantid/docs/source/concepts/Run.rst
@@ -11,7 +11,7 @@ good proton charge, total frames etc. It also holds all of the sample
log files as sets of time-series data. Currently used properties within
Mantid includes *run\_start*, which specified the date the data were
collected. Where an instrument has been modified over time, and multiple
-`instrument definition files <InstrumentDefinitionFile>`__ have been
+:ref:`instrument definition files <InstrumentDefinitionFile>` have been
defined for it, this property is used to loads the IDF valid when the
data were collected.
diff --git a/Code/Mantid/docs/source/concepts/SANS2D_Sample_IDF.rst b/Code/Mantid/docs/source/concepts/SANS2D_Sample_IDF.rst
new file mode 100644
index 0000000000000000000000000000000000000000..a4cfb9685ace080687a02cf4b573ee2914dcec4f
--- /dev/null
+++ b/Code/Mantid/docs/source/concepts/SANS2D_Sample_IDF.rst
@@ -0,0 +1,174 @@
+.. _SANS2D_Sample_IDF:
+
+IDF-ISIS-SANS2D-annotated
+=========================
+
+This page annotates the small angle scattering SANS2D IDF, with the purpose of (hopefully) quickly learn the basis of creating a similar IDF.
+
+Instrument view of SANS2D
+-------------------------
+
+SANS2D consists of two square detector banks and some monitors. Below is shown data from run 14515 (using the Load button on MantidPlot and then selecting instrument view) and for this run zero counts where recorded for the front-detector bank (the SANS2D front-detector was taken off for a period of time, although zero count data were still recorded for this bank, and as of this writing the SANS2D scientists have chosen to stick with the same IDF regardless of weather the front-detector bank is on the instrument or not).
+
+The view of the instrument is generated using the 'Pick' mode. This mode is, for example, useful to check how detector IDs have been assigned. Try this out yourself. In pick mode simply hover the mouse over the banks and you will in the left hand panel above 'Plotting detector spectra' see information about the individual detectors.
+
+.. figure:: ../images/Sans2d-instrument-view.PNG
+ :alt: Sans2d-instrument-view.png
+
+ Sans2d-instrument-view.png
+
+
+A schematic annotation of parts of the ISIS SANS2D IDF
+
+.. figure:: ../images/Sans2d_IDF_annotated.png
+ :alt: Sans2d IDF annotated.png
+
+ Sans2d IDF annotated.png
+
+A detailed annotated version of the full ISIS SANS2D IDF
+
+.. code:: xml
+
+ <!-- Specify name of instrument and date from when this IDF is valid -->
+ <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="SANS2D"
+ valid-from="1900-01-31 23:59:59">
+
+ <!-- Specify various optional defaults -->
+ <defaults>
+ <length unit="meter"/>
+ <angle unit="degree"/>
+ <reference-frame>
+ <along-beam axis="z"/>
+ <pointing-up axis="y"/>
+ <handedness val="right"/>
+ </reference-frame>
+ <default-view axis-view="z-"/>
+ </defaults>
+
+
+ <!-- ISIS is a neutron spallation source. Therefore an important
+ piece of information is the position the source relative to
+ the sample, which is needed to calculate neutron flightpaths.
+ The source currently also serves as a point along the beam, and
+ the source-to-sample direction is used to determine the beam
+ direction in a number of parts of the Mantid code. -->
+ <component type="source">
+ <location /> <!-- Specify location of this component. Specifying nothing means use defaults are (x=0,y=0,z=0) -->
+ </component>
+ <type name="source" is="Source" /> <!-- Specify the type with name "source", which also 'is' marked as the Source -->
+
+ <!-- Specify position of the sample. SANS2D scientists here
+ chose to specify this at (x=0,y=0,z=19.281) in their preferred coordinates
+ system. Another common choice is setting the SamplePos at (0,0,0) -->
+ <component type="some-sample-holder">
+ <location z="19.281"/>
+ </component>
+ <type name="some-sample-holder" is="SamplePos" />
+
+ <!-- Specify monitor components. Monitors collect data hence
+ the idlist="monitors", which specify the name of a list of detector/monitor IDs.
+ For ISIS data this provides the link between the data and the components
+ collecting the data. Even for data not associated with unique IDs,
+ unique ID numbers of your choice are still required, for subsequent
+ use by Mantid analysis -->
+ <component type="monitors" idlist="monitors">
+ <location />
+ </component>
+
+ <!-- Define the monitor detector IDs. There are 8 of these on SANS2D -->
+ <idlist idname="monitors">
+ <id start="1" end="8" />
+ </idlist>
+
+ <!-- Specify what a type with name="monitors" is. This type happens to be a container/grouping
+ of the monitors of this instrument. This grouping is here entirely optional. Only difference
+ it makes is that in the Mantid instrument view tree these will be listed under one node, and
+ in Python/C++ code a user can more easy for example set a property which applies
+ to all the monitors -->
+ <type name="monitors">
+ <component type="monitor-tbd">
+ <location z="7.217" name="monitor1"/>
+ <location z="17.937" name="monitor2"/>
+ </component>
+ <component type="Moderator-Monitor3">
+ <location z="19.497" name="monitor3"/>
+ </component>
+ <component type="monitor-tbd">
+ <location z="30.0" name="monitor4"/>
+ </component>
+ <!-- These monitors are defined in the data, but in fact do not exist on
+ the instrument at present. So these are just located at dummy locations -->
+ <component type="no shape monitor">
+ <location z="0" name="placeholder monitor"/>
+ <location z="0" name="placeholder monitor"/>
+ <location z="0" name="placeholder monitor"/>
+ <location z="0" name="placeholder monitor"/>
+ </component>
+ </type>
+
+ <!-- Define one of the monitor types. This monitor is given a physical shape.
+ More specifically here a cylindrical shape. See http://www.mantidproject.org/HowToDefineGeometricShape
+ for all the options for defining a physical shape -->
+ <type name="monitor-tbd" is="monitor">
+ <cylinder id="some-shape">
+ <centre-of-bottom-base r="0.0" t="0.0" p="0.0" />
+ <axis x="0.0" y="0.0" z="1.0" />
+ <radius val="0.01" />
+ <height val="0.03" />
+ </cylinder>
+ </type>
+
+ <!-- Another monitor type -->
+ <type name="Moderator-Monitor3" is="monitor">
+ <percent-transparency val="99.9" />
+ <cuboid id="shape">
+ <left-front-bottom-point x="0.0125" y="-0.0125" z="0.0" />
+ <left-front-top-point x="0.0125" y="-0.0125" z="0.005" />
+ <left-back-bottom-point x="-0.0125" y="-0.0125" z="0.0" />
+ <right-front-bottom-point x="0.0125" y="0.0125" z="0.0" />
+ </cuboid>
+ <algebra val="shape" />
+ </type>
+
+ <!-- Define a no shape monitor type -->
+ <type name="no shape monitor" is="monitor" />
+
+
+ <!-- Specify the SANS2D front detector bank, which is a square detector bank of 192 x 192 pixels
+ Because this detector bank is described using an optional shortcut notation then an 'idlist' is
+ not used to specify the detector IDs. Instead the tags idstart, idfillbyfirst, idstep and idstepbyrow
+ which in this particular case means the ID are assigned as shown in the instrument view picture on this page -->
+ <component type="detector-bank" idstart="2000000" idfillbyfirst="y" idstep="1000" idstepbyrow="1">
+ <location x="1.1" z="23.281" name="front-detector"/>
+ </component>
+
+ <!-- Specify the SANS2D rear detector, which is of the same type as the front detector bank -->
+ <component type="detector-bank" idstart="1000000" idfillbyfirst="y" idstep="1000" idstepbyrow="1">
+ <location z="23.281" name="rear-detector"/>
+ </component>
+
+ <!-- Specify what a detector bank type is, which is a square array of 192 x 192 pixels, and here
+ a shortcut notation is used do define such a bank using is="RectangularDetector" -->
+ <type name="detector-bank" is="RectangularDetector" type="pixel"
+ xpixels="192" xstart="-0.48705" xstep="+0.0051"
+ ypixels="192" ystart="-0.48705" ystep="+0.0051" >
+ </type>
+
+ <!-- Specify a pixel type -->
+ <type name="pixel" is="detector">
+ <cuboid id="shape">
+ <left-front-bottom-point x="0.005104167" y="-0.005104167" z="0.0" />
+ <left-front-top-point x="0.005104167" y="-0.005104167" z="0.000005" />
+ <left-back-bottom-point x="-0.005104167" y="-0.005104167" z="0.0" />
+ <right-front-bottom-point x="0.005104167" y="0.005104167" z="0.0" />
+ </cuboid>
+ <algebra val="shape" />
+ </type>
+
+ </instrument>
+
+
+.. categories:: Concepts
\ No newline at end of file
diff --git a/Code/Mantid/docs/source/concepts/Shared_Pointer.rst b/Code/Mantid/docs/source/concepts/Shared_Pointer.rst
index f6454bb03fc79c962e6145cb405af700ba48af17..3ff33b7e98bdde0db771c10c16646bc7285adfd9 100644
--- a/Code/Mantid/docs/source/concepts/Shared_Pointer.rst
+++ b/Code/Mantid/docs/source/concepts/Shared_Pointer.rst
@@ -1,6 +1,6 @@
.. _Shared Pointer:
-Shared_Pointer
+Shared Pointer
==============
What are they?
diff --git a/Code/Mantid/docs/source/concepts/Table_Workspaces.rst b/Code/Mantid/docs/source/concepts/Table_Workspaces.rst
index e43ec07a44235244b343d1809c43c4a9c8f1176b..73c30efa06ef589e8dd257c487775588d9765c14 100644
--- a/Code/Mantid/docs/source/concepts/Table_Workspaces.rst
+++ b/Code/Mantid/docs/source/concepts/Table_Workspaces.rst
@@ -1,11 +1,11 @@
.. _Table Workspaces:
-Table_Workspaces
+Table Workspaces
================
-- *This page focusses on dealing with Table Workspaces in C++, and is
+- This page focusses on dealing with Table Workspaces in C++, and is
aimed at developers. For details on interacting with Table Workspaces
- in Python, please see `this page <Python_ITableWorkspace>`__.*
+ in Python, please see :py:obj:`this page <mantid.api.ITableWorkspace>`.
Overview
--------
@@ -56,8 +56,8 @@ the data. To get access to the vector use getVector(name). To get the
column object use getColumn(name).
Only columns of type int, double and str can currently be saved to Nexus
-by `SaveNexus <SaveNexus>`__ or
-`SaveNexusProcessed <SaveNexusProcessed>`__. Columns of other types will
+by :ref:`SaveNexus <algm-SaveNexus>` or
+:ref:`SaveNexusProcessed <algm-SaveNexusProcessed>`. Columns of other types will
simply be ommitted from the Nexus file without any error message.
Table rows
diff --git a/Code/Mantid/docs/source/concepts/Unit_Factory.rst b/Code/Mantid/docs/source/concepts/Unit_Factory.rst
index 0b063750a9c249112fb6c475c43e3e28ae20183e..0dae6818787fe3b98874849562a59218a5a43c4d 100644
--- a/Code/Mantid/docs/source/concepts/Unit_Factory.rst
+++ b/Code/Mantid/docs/source/concepts/Unit_Factory.rst
@@ -3,14 +3,10 @@
Unit_Factory
============
-.. role:: math(raw)
- :format: html latex
-..
-
What is it?
-----------
-The Unit Factory is a `Dynamic Factory <Dynamic Factory>`__ that creates
+The Unit Factory is a :ref:`Dynamic Factory <Dynamic Factory>` that creates
and hands out instances of Mantid Unit objects.
Available units
diff --git a/Code/Mantid/docs/source/concepts/UserAlgorithms.rst b/Code/Mantid/docs/source/concepts/UserAlgorithms.rst
new file mode 100644
index 0000000000000000000000000000000000000000..183221e1c2e79dbd2979313e918bb98749abbc3d
--- /dev/null
+++ b/Code/Mantid/docs/source/concepts/UserAlgorithms.rst
@@ -0,0 +1,8 @@
+.. _UserAlgorithms:
+
+User Algorithms
+===============
+The code for a number of example algorithms is provided in the UserAlgorithms directory of a Mantid installation, and can also be viewed by following the links that follow.
+
+
+.. categories:: Concepts
\ No newline at end of file
diff --git a/Code/Mantid/docs/source/concepts/Workflow_Algorithm.rst b/Code/Mantid/docs/source/concepts/Workflow_Algorithm.rst
index 2ea111cef71a77401a338dcceb9e69483778e5f2..0fdc680fa1f7eafeb29cb3987293806524b8260f 100644
--- a/Code/Mantid/docs/source/concepts/Workflow_Algorithm.rst
+++ b/Code/Mantid/docs/source/concepts/Workflow_Algorithm.rst
@@ -14,10 +14,11 @@ child algorithms to do so.
Special Functions
~~~~~~~~~~~~~~~~~
-.. figure:: NestedHistory.png
+.. figure:: ../images/NestedHistory.png
:alt: NestedHistory.png
NestedHistory.png
+
Nested History
^^^^^^^^^^^^^^
@@ -39,8 +40,8 @@ flow diagram of it's operations.
Examples
''''''''
-- `DGSReduction <http://docs.mantidproject.org/algorithms/DgsReduction.html>`__
-- `MuonLoad <http://docs.mantidproject.org/algorithms/MuonLoad.html>`__
+- :ref:`DGSReduction <algm-DgsReduction>`
+- :ref:`MuonLoad <algm-MuonLoad>`
diff --git a/Code/Mantid/docs/source/concepts/Workspace.rst b/Code/Mantid/docs/source/concepts/Workspace.rst
index 010cc4c0fc3f5d482a5b8a0bb9972b4624f58d4c..a6a452f2ff8045db1c9f34616fbc411e40fd950c 100644
--- a/Code/Mantid/docs/source/concepts/Workspace.rst
+++ b/Code/Mantid/docs/source/concepts/Workspace.rst
@@ -6,21 +6,21 @@ Workspace
What are they?
--------------
-Workspaces are the nouns of Mantid (while `algorithms <algorithm>`__ are
+Workspaces are the nouns of Mantid (while :ref:`algorithms <algorithm>` are
the verbs). Workspaces hold the data in Mantid.
They come in several forms, but the most common by far is the
-`MatrixWorkspace <MatrixWorkspace>`__ which contains measured or derived
+:ref:`MatrixWorkspace <MatrixWorkspace>` which contains measured or derived
data with associated errors. Matrix Workspaces are typically created
initially by executing one of Mantid's 'Load' algorithms, for example
-`LoadRaw <http://docs.mantidproject.org/nightly/algorithms/LoadRaw.html>`__
+:ref:`LoadRaw <algm-LoadRaw>`
or
-`LoadNexus <http://docs.mantidproject.org/nightly/algorithms/LoadNexus.html>`__,
+:ref:`LoadNexus <algm-LoadNexus>`,
or they are the output of algorithms which took a matrix workspace as
-input. In `MantidPlot <MantidPlot:_Help>`__ the data from the workspace
+input. In `MantidPlot <http://www.mantidproject.org/MantidPlot:_Help>`__ the data from the workspace
can viewed as a table, and graphed in many ways.
-Another form of workspace is the `TableWorkspace <Table Workspaces>`__.
+Another form of workspace is the :ref:`TableWorkspace <Table Workspaces>`.
This stores data of (somewhat) arbitrary type in rows and columns, much
like a spreadsheet. These typically are created as the output of certain
specialized algorithms (e.g. curve fitting).
@@ -33,24 +33,24 @@ In software engineering terms, the 'abstract' concept of a workspace is
an 'interface', in that it defines common properties that are
implemented by various 'concrete' workspaces. Interaction with
workspaces is typically through an interface. The concrete workspaces
-themselves are loaded in via Mantid's `plugin <plugin>`__ mechanism and
-are created using the `Workspace Factory <Workspace Factory>`__.
+themselves are loaded in via Mantid's :ref:`plugin <plugin>` mechanism and
+are created using the Workspace Factory.
Example Workspaces
------------------
-- `MatrixWorkspace <MatrixWorkspace>`__ - A base class that contains
+- :ref:`MatrixWorkspace <MatrixWorkspace>` - A base class that contains
among others:
- - `Workspace2D <Workspace2D>`__ - A workspace for holding two
+ - :ref:`Workspace2D <Workspace2D>` - A workspace for holding two
dimensional data in memory, this is the most commonly used
workspace.
- - `EventWorkspace <EventWorkspace>`__ - A workspace that retains the
+ - :ref:`EventWorkspace <EventWorkspace>` - A workspace that retains the
individual neutron event data.
-- `TableWorkspace <Table Workspaces>`__ - A workspace holding data in
+- :ref:`TableWorkspace <Table Workspaces>` - A workspace holding data in
rows of columns having a particular type (e.g. text, integer, ...).
-- `WorkspaceGroup <WorkspaceGroup>`__ - A container for a collection of
+- :ref:`WorkspaceGroup <WorkspaceGroup>` - A container for a collection of
workspaces. Algorithms given a group as input run sequentially on
each member of the group.
@@ -83,21 +83,21 @@ createWorkspace if you are writing C++ or Python algorithms.
+-------------------------------+-------------------------------------------+
| "CompressedWorkspace2D" | CompressedWorkspace2D |
+-------------------------------+-------------------------------------------+
-| "EventWorkspace" | `EventWorkspace <EventWorkspace>`__ |
+| "EventWorkspace" | :ref:`EventWorkspace <EventWorkspace>` |
+-------------------------------+-------------------------------------------+
| "ManagedWorkspace2D" | ManagedWorkspace2D |
+-------------------------------+-------------------------------------------+
| "TableWorkspace" | TableWorkspace |
+-------------------------------+-------------------------------------------+
-| "Workspace2D" | `Workspace2D <Workspace2D>`__ |
+| "Workspace2D" | :ref:`Workspace2D <Workspace2D>` |
+-------------------------------+-------------------------------------------+
| "WorkspaceSingleValue" | WorkspaceSingleValue |
+-------------------------------+-------------------------------------------+
| "ManagedRawFileWorkspace2D" | ManagedRawFileWorkspace2D |
+-------------------------------+-------------------------------------------+
-| "MDEventWorkspace" | `MDEventWorkspace <MDEventWorkspace>`__ |
+| "MDWorkspace" | :ref:`MDWorkspace <MDWorkspace>` |
+-------------------------------+-------------------------------------------+
-| "MDHistoWorkspace" | `MDHistoWorkspace <MDHistoWorkspace>`__ |
+| "MDHistoWorkspace" | :ref:`MDHistoWorkspace <MDHistoWorkspace>`|
+-------------------------------+-------------------------------------------+
diff --git a/Code/Mantid/docs/source/concepts/Workspace2D.rst b/Code/Mantid/docs/source/concepts/Workspace2D.rst
index 76bd44da45bbaee0203ed5519fb7451ed11af28b..6a7e2c28970dddde83d6b23a044a4a57d7a6e2dc 100644
--- a/Code/Mantid/docs/source/concepts/Workspace2D.rst
+++ b/Code/Mantid/docs/source/concepts/Workspace2D.rst
@@ -4,15 +4,15 @@ Workspace2D
===========
The Workspace2D is a Mantid data type for a
-`MatrixWorkspace <MatrixWorkspace>`__.
+:ref:`MatrixWorkspace <MatrixWorkspace>`.
It consists of a workspace with 1 or more spectra. Typically, each
spectrum will be a histogram. For example, you might have 10 bins, and
so have 11 X-value, 10 Y-values and 10 E-values in a workspace.
-In contrast to an `EventWorkspace <EventWorkspace>`__, a Workspace2D
+In contrast to an :ref:`EventWorkspace <EventWorkspace>`, a Workspace2D
only contains bin information and does not contain the underlying event
-data. The `EventWorkspace <EventWorkspace>`__ presents itself as a
+data. The :ref:`EventWorkspace <EventWorkspace>` presents itself as a
histogram (with X,Y,E values) but preserves the underlying event data.
diff --git a/Code/Mantid/docs/source/concepts/WorkspaceGroup.rst b/Code/Mantid/docs/source/concepts/WorkspaceGroup.rst
index 9544412892c2c60f0e99a26cebef0d1a40cd7d06..7c095bcf14566161f0b99060cc49efdb233e96a3 100644
--- a/Code/Mantid/docs/source/concepts/WorkspaceGroup.rst
+++ b/Code/Mantid/docs/source/concepts/WorkspaceGroup.rst
@@ -13,13 +13,13 @@ Creating a Workspace Group
- Select a few workspaces in MantidPlot and click the "Group" button
above the list of workspaces.
-- Use the `GroupWorkspaces <GroupWorkspaces>`__ algorithm.
+- Use the :ref:`GroupWorkspaces <algm-GroupWorkspaces>` algorithm.
Un-grouping Workspaces
~~~~~~~~~~~~~~~~~~~~~~
- Select the WorkspaceGroup and click "Ungroup".
-- Use the `UnGroupWorkspace <UnGroupWorkspace>`__ algorithm.
+- Use the :ref:`UnGroupWorkspace <algm-UnGroupWorkspace>` algorithm.
diff --git a/Code/Mantid/docs/source/images/CombineIntoOneShapeExample.png b/Code/Mantid/docs/source/images/CombineIntoOneShapeExample.png
new file mode 100644
index 0000000000000000000000000000000000000000..cd5640c97596b486e22f1f3b035a6906826de149
Binary files /dev/null and b/Code/Mantid/docs/source/images/CombineIntoOneShapeExample.png differ
diff --git a/Code/Mantid/docs/source/images/LETinFull3DInstrumentView.png b/Code/Mantid/docs/source/images/LETinFull3DInstrumentView.png
new file mode 100644
index 0000000000000000000000000000000000000000..eb860cf384a1726739d68f115973593e8c9aab36
Binary files /dev/null and b/Code/Mantid/docs/source/images/LETinFull3DInstrumentView.png differ
diff --git a/Code/Mantid/docs/source/images/Location-element-transformation.png b/Code/Mantid/docs/source/images/Location-element-transformation.png
new file mode 100644
index 0000000000000000000000000000000000000000..d0a7a60d9e9129584b865b52141e52696c1d46a5
Binary files /dev/null and b/Code/Mantid/docs/source/images/Location-element-transformation.png differ
diff --git a/Code/Mantid/docs/source/images/Sans2d-instrument-view.PNG b/Code/Mantid/docs/source/images/Sans2d-instrument-view.PNG
new file mode 100644
index 0000000000000000000000000000000000000000..73c8d59e12603b64d931a6098d135800a5bdfc02
Binary files /dev/null and b/Code/Mantid/docs/source/images/Sans2d-instrument-view.PNG differ
diff --git a/Code/Mantid/docs/source/images/Sans2d_IDF_annotated.png b/Code/Mantid/docs/source/images/Sans2d_IDF_annotated.png
new file mode 100644
index 0000000000000000000000000000000000000000..3f4d65b3ec8b74164a424354b18dc40b58e7f293
Binary files /dev/null and b/Code/Mantid/docs/source/images/Sans2d_IDF_annotated.png differ
diff --git a/Code/Mantid/docs/source/images/SimpleInstrumentTree.png b/Code/Mantid/docs/source/images/SimpleInstrumentTree.png
new file mode 100644
index 0000000000000000000000000000000000000000..629370b498860d7a75253e73bfafb89d368cf90c
Binary files /dev/null and b/Code/Mantid/docs/source/images/SimpleInstrumentTree.png differ
diff --git a/Code/Tools/scripts/ConvertBadAlgmLinks.py b/Code/Tools/scripts/ConvertBadAlgmLinks.py
new file mode 100644
index 0000000000000000000000000000000000000000..b598ef44f6b7713229b8229a0bfd156a1de312e5
--- /dev/null
+++ b/Code/Tools/scripts/ConvertBadAlgmLinks.py
@@ -0,0 +1,42 @@
+import re, glob, os
+
+def grep(patt,lines):
+ """ finds patt in file - patt is a compiled regex
+ returns all lines that match patt """
+ matchlines = []
+ for line in lines:
+ match = patt.search(line)
+ if match:
+ matchline = match.group()
+ matchlines.append(matchline)
+ results = '\n '.join(matchlines)
+ if results:
+ return results
+ else:
+ return None
+
+#get alg names
+algs = AlgorithmFactory.getRegisteredAlgorithms(True)
+#algs = ['Abragam','BackToBackExponential','BivariateNormal','BSpline','Chebyshev','ChudleyElliot','CompositeFunction','Convolution','CubicSpline','DiffRotDiscreteCircle','DiffSphere','DSFInterp1DFit','ExpDecay','ExpDecayMuon','ExpDecayOsc','FickDiffusion','FlatBackground','GausDecay','GausOsc','Gaussian','HallRoss','IkedaCarpenterPV','LatticeErrors','LinearBackground','LogNormal','Lorentzian','MuonFInteraction','NeutronBk2BkExpConvPVoigt','PeakHKLErrors','ProductFunction','ProductLinearExp','ProductQuadraticExp','Quadratic','SCDPanelErrors','StaticKuboToyabe','StaticKuboToyabeTimesExpDecay','StaticKuboToyabeTimesGausDecay','StretchedExpFT','StretchExp','StretchExpMuon','TeixeiraWater','ThermalNeutronBk2BkExpConvPVoigt','UserFunction','Voigt']
+regexs= {}
+for alg in algs:
+ regexs[alg] = re.compile(r'`%s\s+<[\w\:\/\.]+\/%s>`_' % (alg,alg))
+
+
+# Example use
+dir = r"C:\Mantid\Code\Mantid\docs\source\algorithms"
+files = glob.glob(os.path.join(dir, '*.rst'))
+for filename in files:
+
+ #print os.path.basename(filename)[:-4]
+ with open(filename) as file:
+ lines = file.readlines()
+ for alg in algs:
+ expr = regexs[alg]
+ results = grep(expr, lines)
+ if results:
+ print filename
+ print results
+
+
+