diff --git a/.settings/org.eclipse.core.resources.prefs b/.settings/org.eclipse.core.resources.prefs index 0b02a456f..46230f4b0 100644 --- a/.settings/org.eclipse.core.resources.prefs +++ b/.settings/org.eclipse.core.resources.prefs @@ -1,3 +1,3 @@ eclipse.preferences.version=1 -encoding//_sphinx/db2rst.py=utf-8 +encoding//impatient-guide/conf.py=utf-8 encoding//manual/source/conf.py=utf-8 diff --git a/README.md b/README.md index d1f3f0eb3..a81c9b1b5 100644 --- a/README.md +++ b/README.md @@ -14,6 +14,7 @@ README.make.txt | how to build the documentation applications/ | NXDL files for applications and instrument defs base_classes/ | NXDL files for components contributed_definitions/ | NXDL files from the community +impatient-guide/ | *NeXus for the Impatient* jenkins_build | configuration for Jenkins continuous integration service manual/ | Sphinx source files for the NeXus documentation nxdl.xsd | XML Schema for NXDL files @@ -22,7 +23,5 @@ package/ | directory for packaging this content utils/ | various tools used in the definitions tree www/ | launch (home) page of NeXus WWW site xslt/ | various XML stylesheet transformations -_cmake_include_obsolete | (obsolete) configuration for cmake builds -_sphinx/ | (obsolete) remnant Sphinx source files for the manual (pre-release development) See README.make.txt for how to build the documentation diff --git a/_sphinx/Makefile_old b/_sphinx/Makefile_old deleted file mode 100755 index 52be671cb..000000000 --- a/_sphinx/Makefile_old +++ /dev/null @@ -1,137 +0,0 @@ -# Makefile for Sphinx documentation -# - -# You can set these variables from the command line. -SPHINXOPTS = -SPHINXBUILD = sphinx-build -PAPER = -BUILDDIR = build - -# Internal variables. -PAPEROPT_a4 = -D latex_paper_size=a4 -PAPEROPT_letter = -D latex_paper_size=letter -ALLSPHINXOPTS = -d $(BUILDDIR)/doctrees $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) source - -.PHONY: help clean html dirhtml singlehtml pickle json htmlhelp qthelp devhelp epub latex latexpdf text man changes linkcheck doctest - -help: - @echo "Please use \`make ' where is one of" - @echo " html to make standalone HTML files" - @echo " dirhtml to make HTML files named index.html in directories" - @echo " singlehtml to make a single large HTML file" - @echo " pickle to make pickle files" - @echo " json to make JSON files" - @echo " htmlhelp to make HTML files and a HTML help project" - @echo " qthelp to make HTML files and a qthelp project" - @echo " devhelp to make HTML files and a Devhelp project" - @echo " epub to make an epub" - @echo " latex to make LaTeX files, you can set PAPER=a4 or PAPER=letter" - @echo " latexpdf to make LaTeX files and run them through pdflatex" - @echo " text to make text files" - @echo " man to make manual pages" - @echo " changes to make an overview of all changed/added/deprecated items" - @echo " linkcheck to check all external links for integrity" - @echo " doctest to run all doctests embedded in the documentation (if enabled)" - -clean: - -rm -rf $(BUILDDIR)/doctrees $(BUILDDIR)/latex $(BUILDDIR)/epub - -realclean: - -rm -rf $(BUILDDIR)/* - -complete: html latexpdf - -cp -f $(BUILDDIR)/latex/*.pdf $(BUILDDIR)/html - @echo - @echo "Build finished. The HTML and PDF pages are in $(BUILDDIR)/html." - -html: - $(SPHINXBUILD) -b html $(ALLSPHINXOPTS) $(BUILDDIR)/html - @echo - @echo "Build finished. The HTML pages are in $(BUILDDIR)/html." - -dirhtml: - $(SPHINXBUILD) -b dirhtml $(ALLSPHINXOPTS) $(BUILDDIR)/dirhtml - @echo - @echo "Build finished. The HTML pages are in $(BUILDDIR)/dirhtml." - -singlehtml: - $(SPHINXBUILD) -b singlehtml $(ALLSPHINXOPTS) $(BUILDDIR)/singlehtml - @echo - @echo "Build finished. The HTML page is in $(BUILDDIR)/singlehtml." - -pickle: - $(SPHINXBUILD) -b pickle $(ALLSPHINXOPTS) $(BUILDDIR)/pickle - @echo - @echo "Build finished; now you can process the pickle files." - -json: - $(SPHINXBUILD) -b json $(ALLSPHINXOPTS) $(BUILDDIR)/json - @echo - @echo "Build finished; now you can process the JSON files." - -htmlhelp: - $(SPHINXBUILD) -b htmlhelp $(ALLSPHINXOPTS) $(BUILDDIR)/htmlhelp - @echo - @echo "Build finished; now you can run HTML Help Workshop with the" \ - ".hhp project file in $(BUILDDIR)/htmlhelp." - -qthelp: - $(SPHINXBUILD) -b qthelp $(ALLSPHINXOPTS) $(BUILDDIR)/qthelp - @echo - @echo "Build finished; now you can run "qcollectiongenerator" with the" \ - ".qhcp project file in $(BUILDDIR)/qthelp, like this:" - @echo "# qcollectiongenerator $(BUILDDIR)/qthelp/NeXusacommondataformatforneutronx-rayandmuonscience.qhcp" - @echo "To view the help file:" - @echo "# assistant -collectionFile $(BUILDDIR)/qthelp/NeXusacommondataformatforneutronx-rayandmuonscience.qhc" - -devhelp: - $(SPHINXBUILD) -b devhelp $(ALLSPHINXOPTS) $(BUILDDIR)/devhelp - @echo - @echo "Build finished." - @echo "To view the help file:" - @echo "# mkdir -p $$HOME/.local/share/devhelp/NeXusacommondataformatforneutronx-rayandmuonscience" - @echo "# ln -s $(BUILDDIR)/devhelp $$HOME/.local/share/devhelp/NeXusacommondataformatforneutronx-rayandmuonscience" - @echo "# devhelp" - -epub: - $(SPHINXBUILD) -b epub $(ALLSPHINXOPTS) $(BUILDDIR)/epub - @echo - @echo "Build finished. The epub file is in $(BUILDDIR)/epub." - -latex: - $(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex - @echo - @echo "Build finished; the LaTeX files are in $(BUILDDIR)/latex." - @echo "Run \`make' in that directory to run these through (pdf)latex" \ - "(use \`make latexpdf' here to do that automatically)." - -latexpdf: latex - @echo "Running LaTeX files through pdflatex..." - make -C $(BUILDDIR)/latex all-pdf - @echo "pdflatex finished; the PDF files are in $(BUILDDIR)/latex." - -text: - $(SPHINXBUILD) -b text $(ALLSPHINXOPTS) $(BUILDDIR)/text - @echo - @echo "Build finished. The text files are in $(BUILDDIR)/text." - -man: - $(SPHINXBUILD) -b man $(ALLSPHINXOPTS) $(BUILDDIR)/man - @echo - @echo "Build finished. The manual pages are in $(BUILDDIR)/man." - -changes: - $(SPHINXBUILD) -b changes $(ALLSPHINXOPTS) $(BUILDDIR)/changes - @echo - @echo "The overview file is in $(BUILDDIR)/changes." - -linkcheck: - $(SPHINXBUILD) -b linkcheck $(ALLSPHINXOPTS) $(BUILDDIR)/linkcheck - @echo - @echo "Link check complete; look for any errors in the above output " \ - "or in $(BUILDDIR)/linkcheck/output.txt." - -doctest: - $(SPHINXBUILD) -b doctest $(ALLSPHINXOPTS) $(BUILDDIR)/doctest - @echo "Testing of doctests in the sources finished, look at the " \ - "results in $(BUILDDIR)/doctest/output.txt." diff --git a/_sphinx/README b/_sphinx/README deleted file mode 100755 index 74d58f567..000000000 --- a/_sphinx/README +++ /dev/null @@ -1,34 +0,0 @@ -$Id: README 841 2011-05-18 20:35:30Z Pete Jemian $ - -This directory contains the source for an alternative rendering of the NeXus documentation. -The tool used here is sphinx. It relies on source code files coded in reST. -See the sphinx WWW site for how this works: http://sphinx.pocoo.org/ - -Typical Builds ----------------- - -These commands are useful on Linux -(from the /trunk/sphinx directory): - - make clean - make html - make latexpdf - firefox build/html/index.html & - evince build/latex/nexus.pdf & - - -Development -------------- - -When building the new sphinx documentation, -commands similar to these might be useful when -sifting through the output:: - - cp /dev/null makelog.txt - logmake clean html - grep introduction makelog.txt \ - | grep -v include \ - | grep -v undefined \ - | grep -v "not readable" \ - | grep -v "not found" \ - | grep -v Duplicate diff --git a/_sphinx/db2rst.py b/_sphinx/db2rst.py deleted file mode 100644 index 78b832fe8..000000000 --- a/_sphinx/db2rst.py +++ /dev/null @@ -1,1159 +0,0 @@ -#!/usr/bin/env python -# -*- coding: utf-8 -*- -""" - DocBook to ReST converter - ========================= - This script may not work out of the box, but is easy to extend. - If you extend it, please send me a patch: wojdyr at gmail. - - Docbook has >400 elements, most of them are not supported (yet). - ``pydoc db2rst`` shows the list of supported elements. - - In ReST, inline markup can not be nested (major deficiency of ReST). - Since it is not clear what to do with, say, - x - the script outputs incorrect (nested) ReST (:sub:`*x*`) - and it is up to user to decide how to change it. - - Usage: - db2rst.py file.xml > file.rst - db2rst.py file.xml output_directory/ - - :copyright: 2009 by Marcin Wojdyr. - :license: BSD. - :URL: https://raw.github.com/kurtmckee/db2rst/master/db2rst.py -""" - -import os.path -import sys -import re -import lxml.etree -import logging -import itertools - -__contributors__ = ('Kurt McKee ', - 'Anthony Scopatz ', - 'Pete Jemian ', - ) -INDENT = ' '*4 - - -def write_footnotes(footnotes): - if len(footnotes) == 0: - return None - s = ".. rubric:: Footnote" - if len(footnotes) > 1: - s += "s" - s += '\n\n' - for note in footnotes: - s += '.. [#] ' - if len(note.split('\n')) == 1: - s += note + '\n' - else: - s += '\n' - for line in note.split("\n"): - s += INDENT + line + '\n' - return s - - -class Db2Rst: - ''' - handle conversion of DocBook source code files - into ReST: Restructured Text source code documents - ''' - - def __init__(self): - self.remove_comments = False - self.write_unused_labels = False - self._linked_ids = set() # which id/labels are really needed - self.id_attrib = "id" # can modify if namespace is present - self.linkend = "linkend" # can modify if namespace is present - self.output_dir = None # if converting a set of docbook files - self.namespacePrefix = None # as used in the DocBook file - self.ns = "" - - def process(self, dbfile, converter=None): - ''' - process one DocBook XML file - - :param str dbfile: name of DocBook source code file - :param obj converter: optional subclass override of Convert - :return: None or string buffer with converted ReST source - ''' - logging.info('parsing %s with converter %s' % (dbfile, str(converter))) - parser = lxml.etree.XMLParser(remove_comments=self.remove_comments) - logging.info('created the parser') - tree = lxml.etree.parse(dbfile, parser=parser) - logging.info('parsed XML file') - root = tree.getroot() - if self.namespacePrefix in root.nsmap: - self.ns = "{%s}" % root.nsmap[self.namespacePrefix] - self._linked_ids = self._get_linked_ids(tree) - if converter is None: - obj = Convert(root, self) - else: - obj = converter(root, self) - if self.output_dir: - self.writeToDir(obj) - return None - else: - return str(obj).strip() + "\n" - - def _get_linked_ids(self, tree): - ''' - discover all the ids referenced in the file - - :param tree: name of DocBook source code file - :type tree: lxml document tree - :return [str]: list of strings containing all the ids - ''' - ids = set() - for elem in tree.getiterator(): - if elem.tag in (self.ns + "xref", self.ns + "link"): - for nskey, nsstr in elem.nsmap.items(): - ns = "{%s}" % nsstr - for term in ('linkend', 'href'): - text = elem.get(ns + term) - if text is not None: - ids.add(text.lstrip('#')) - return ids - - def writeToDir(self, obj): - ''' - Write the ReST files to the named directory. - Generate an ``index.rst`` file as directed. - - :param obj: db2rst.Convert object - ''' - if self.output_dir is None: - return - output = str(obj).strip() - for fname in obj.files: - f = open(os.path.join(self.output_dir, fname + '.rst'), 'wb') - f.write(obj.files[fname].encode('utf-8').strip()) - f.close() - # write the index if it doesn't exist already - if 'index' not in obj.files: - f = open(os.path.join(self.output_dir, 'index.rst'), 'wb') - f.write(output) - f.write('\n\n.. toctree::\n :maxdepth: 1\n\n') - for fname in sorted(obj.files): - f.write(' %s\n' % (fname,)) - f.close() - # write a simple conf.py - c = open(os.path.join(self.output_dir, 'conf.py'), 'wb') - c.write("extensions = []\n") - c.write("master_doc = 'index'\n") - c.write("project = u'projname'\n") - c.write("#copyright = u'2012, authname'\n") - c.write("exclude_patterns = ['_build']\n") - c.close() - - def removeComments(self, remove): - ''' - Either remove comments from source stream (True) - or convert them to ReST-format comments. - - :param bool remove: if True, XML comment will be discarded - - This DocBook (XML) comment:: - - - - becomes this ReST code:: - - .. COMMENT: This is a comment - with two lines. - - .. note:: Note that ReST doesn't support inline comments. XML comments - are converted to ReST comment blocks, which may break paragraphs. - ''' - self.remove_comments = remove - - def writeUnusedLabels(self, write): - ''' - Any ``id`` attributes of DocBook elements are translated to ReST labels. - - :param bool write: if False, only labels that are used in links are generated. - ''' - self.write_unused_labels = write - - - -class Convert(object): - ''' converts DocBook tree into reST ''' - - def __init__(self, el, parent=None, namespace=None): - self.el = el - self.files = {} - if parent is None: - parent = Db2Rst() # looks inverted, provides basic constants - if namespace is not None: - parent.ns = "{%s}" % namespace - self.parent = parent # object that called the converter - self._not_handled_tags = set() # to avoid duplicate error reports - self._substitutions = set() # to avoid duplicate substitutions - - # _buffer is flushed after the end of paragraph - # used for ReST substitutions - self._buffer = "" - self.footnotes = [] - - def __str__(self): - output = self._conv(self.el) - - notes = write_footnotes(self.footnotes) - if notes is not None: - output += '\n' + notes - - # remove trailing whitespace - output = re.sub(r"[ \t]+\n", "\n", output) - # leave only one blank line - output = re.sub(r"\n{3,}", "\n\n", output) - return output.encode('utf-8') - - def _conv(self, el, do_assert=True): - ''' - Element to string conversion. - Looks for a defined function e_tag() and calls it, - where tag is the element name. - The function e_tag() has one argument, - the DocBook element node to process. - ''' - tag = str(el.tag) - if tag == "": - logging.info("_conv(): line %d in %s" % (el.sourceline, - str(el.base))) - logging.info("ignoring ProcessingInstruction for now") - return "" - if tag == "": - #logging.info("_conv(): line %d in %s" % (el.sourceline, - # str(el.base))) - #logging.info("ignoring Comment for now") - return self.Comment(el) - if tag.find(self.parent.ns) == 0: - # strip off the default namespace - tag = tag[len(self.parent.ns):] - if tag.startswith("{"): - # identify other namespaces by prefix used in XML file - ns, rawTag = tag[1:].split("}") - if ns in el.nsmap.values(): - # find the namespace prefix, given its full value - prefix = [k for k, v in el.nsmap.iteritems() if v == ns][0] - if prefix is not None: - tag = "_".join([prefix, rawTag]) - # - #if len(self.footnotes): - # print len(self.footnotes), self._what(el) - # - method_name = 'e_' + tag - if hasattr(self, method_name): - return getattr(self, method_name)(el) # call the e_tag(el) method - elif isinstance(el, lxml.etree._Comment): - if el.text.strip(): - return self.Comment(el) - else: - return u'' - else: - if el.tag not in self._not_handled_tags: - logging.info("line %d in %s" % (el.sourceline, str(el.base))) - self._warn("Don't know how to handle <%s>" % el.tag) - self._not_handled_tags.add(el.tag) - return self._concat(el) - - def _warn(self, s): - logging.warning(s) - - def _supports_only(self, el, tags): - "print warning if there are unexpected children" - for i in el.getchildren(): - if i.tag not in tags: - self._warn("%s/%s skipped." % (el.tag, i.tag)) - - def _what(self, el): - "returns string describing the element, such as or Comment" - if isinstance(el.tag, basestring): - return "<%s>" % el.tag - elif isinstance(el, lxml.etree._Comment): - return "Comment" - else: - return str(el) - - def _has_only_text(self, el): - "print warning if there are any children" - if el.getchildren(): - self._warn("children of %s are skipped: %s" % (self._get_path(el), - ", ".join(self._what(i) for i in el.getchildren()))) - - def _has_no_text(self, el): - "print warning if there is any non-blank text" - if el.text is not None and not el.text.isspace(): - self._warn("skipping text of <%s>: %s" % (self._get_path(el), - el.text)) - for i in el.getchildren(): - if i.tail is not None and not i.tail.isspace(): - self._warn("skipping tail of <%s>: %s" % (self._get_path(i), - i.tail)) - - def _no_special_markup(self, el): - return self._concat(el) - - def _remove_indent_and_escape(self, s): - """ - remove indentation from the string s - escape some of the special chars - """ - s = "\n".join(i.lstrip().replace("\\", "\\\\") for i in s.splitlines()) - # escape inline mark-up start-string characters (even if there is no - # end-string, docutils show warning if the start-string is not escaped) - # TODO: handle also Unicode: � � � � � � as preceding chars - s = re.sub(r"([\s'\"([{ element in a - s += self._conv(i) - if i.tail is not None: - if len(s) > 0 and not s[-1].isspace() and i.tail[0] in " \t": - s += i.tail[0] - s += self._remove_indent_and_escape(i.tail) - return s - - def _original_xml(self, el): - return lxml.etree.tostring(el, with_tail=False) - - def _no_markup(self, el): - s = lxml.etree.tostring(el, with_tail=False) - s = re.sub(r"<.+?>", " ", s) # remove tags - s = re.sub(r"\s+", " ", s) # replace all blanks with single space - return s - - def _get_level(self, el): - "return number of ancestors" - return sum(1 for _ in el.iterancestors()) - - def _get_path(self, el): - t = [el] + list(el.iterancestors()) - return "/".join(str(i.tag) for i in reversed(t)) - - def _make_title(self, t, level): - ''' - :param str t: title - :param int level: [1...] indicating priority of section level - ''' - if level == 1: - return "\n\n" + "=" * len(t) + "\n" + t + "\n" + "=" * len(t) - char = ["#", "=", "-", "~", "^", ".", "*", "+", "_", ",", ":", "'", - "!", "?", '"', '$', '%', '&', ';', '(', ')', '/', '<', '>', - "@", "[", "]", "`", "{", "}", "|", "\\", ] - return "\n\n" + t + "\n" + char[level - 2] * len(t) - - def _join_children(self, el, sep): - self._has_no_text(el) - return sep.join(self._conv(i) for i in el.getchildren()) - - def _block_separated_with_blank_line(self, el): - pi = [i for i in el.iterchildren() if isinstance(i, - lxml.etree._ProcessingInstruction)] - if pi and 'filename=' in pi[0].text: - fname = pi[0].text.split('=')[1][1:-1].split('.')[0] - #import pdb; pdb.set_trace() - el.remove(pi[0]) - self.files[fname] = self._conv(el) - return "\n" - else: - s = "\n\n" + self._concat(el) - if self._buffer: - s += "\n\n" + self._buffer - self._buffer = "" - return s - - def _indent(self, el, indent, first_line=None): - "returns indented block with exactly one blank line at the beginning" - lines = [" "*indent + i for i in self._concat(el).splitlines() - if i and not i.isspace()] - if first_line is not None: - # replace indentation of the first line with prefix `first_line' - lines[0] = first_line + lines[0][indent:] - return "\n\n" + "\n".join(lines) - - def _normalize_whitespace(self, s): - return " ".join(s.split()) - - ################### DocBook elements ##################### - - # special "elements" - - def _directive(self, el, name): - ''' - Creates a reST directive:: - - .. name: ``el.text`` provides the content. - Indentation is sized automatically like this. - - Some directives have two colons: - - .. note:: This is an advisory note. - - Some might only have one colon. - If you need two, supply it in the caller. - - :param XML_node el: node of the lxml document tree - :param str name: text to be written after the two dots - ''' - prefix = ".. %s: " % name - indentation = len(prefix) - return self._indent(el, indentation, prefix) - - def _docbook_source(self, el, name): - s = "\n\n.. rubric:: %s\n\n::\n\n" % name - s += INDENT + self._original_xml(el) - s += "\n\n" - return s - - def _include_source(self, el): - s = "literalinclude:: %s\n" - s += INDENT + ":language: %s\n" - s += INDENT + ":linenos:\n" - s += INDENT + ":tab-width: %s\n" - s += "\n" + INDENT - return self._directive(el, s) - - def _literal_source(self, el): - #return "\n::\n" + self._indent(el, 4) + "\n" - #s = "\n\n.. code-block:: guess" - return self._directive(el, 'code-block: guess\n :linenos:\n\n ') - - def Comment(self, el): - return self._indent(el, 4, ".. ") - - def ProcessingInstruction(self, el): - # TODO: How/where to call this? - return self._docbook_source(el, "ProcessingInstruction") - - def e_figure(self, el): - return self._docbook_source(el, 'FIGURE') - - def e_example(self, el): - return self._docbook_source(el, 'EXAMPLE') - - def e_informalexample(self, el): - return self._docbook_source(el, 'INFORMALEXAMPLE') - - def e_calloutlist(self, el): - return self._docbook_source(el, 'CALLOUTLIST') - - def e_include(self, el): - ''' - process "include" directives - as triggered by a statement such as this:: - - - - This produces the ReST result:: - - .. include:: preface.xml - ''' - logging.info("line %d in %s" % (el.sourceline, str(el.base))) - href = el.get('href', None) - if href is not None: - return "\n\n.. include:: %s\n\n" % href - return "\n\n.. UNHANDLED LINE %d in %s" % (el.sourceline, str(el.base)) - - # general inline elements - - def e_emphasis(self, el): - return "*%s*" % self._concat(el).strip() - e_phrase = e_emphasis - e_citetitle = e_emphasis - e_replaceable = e_emphasis - - def e_literal(self, el): - return "``%s``" % self._concat(el).strip() - e_code = e_literal - - def e_firstterm(self, el): - self._has_only_text(el) - return ":dfn:`%s`" % el.text - - def e_acronym(self, el): - if el.attrib.get('condition'): - return u":abbr:`%s (%s)`" % (el.text, el.attrib['condition']) - else: - return u":abbr:`%s`" % (el.text,) - - #def e_userinput(self, el): - # return u":kbd:`%s`" % (el.text,) - - def e_quote(self, el): - q = " ".join(el.text.split("\n")) - return u'"%s"' % (q,) - - # links - - def e_ulink(self, el): - url = el.get("url") - text = self._concat(el).strip() - if text.startswith(".. image::"): - return "%s\n :target: %s\n\n" % (text, url) - elif url == text: - return text - elif text.strip(): - return "`%s <%s>`_" % (text, url) - else: - return "`%s <%s>`_" % (url, url) - - # TODO: - # put labels where referenced ids are - # e.g. -> .. _license:\n - # if the label is not before title, we need to give explicit title: - # :ref:`Link title ` - # (in DocBook was: the section called �Variables�) - - def e_xref(self, el): - return ":ref:`%s`" % el.get("linkend") - - def e_link(self, el): - # some text - # - # regular expression example - text = self._concat(el).strip().strip("`") - # TODO: handle properly - link = el.get(self.parent.linkend) - if link is None: - return ":ref:`%s`" % text - else: - if text is None or len(text) == 0 or text.strip("`") == link: - return ":ref:`%s`" % link.lstrip('#') - else: - return ":ref:`%s <%s>`" % (text, link.lstrip('#')) - - - # math and media - # the DocBook syntax to embed equations is sick. - # Usually, (inline)equation is - # a (inline)mediaobject, which is imageobject + textobject - - def e_inlineequation(self, el): - self._supports_only(el, (self.parent.ns + "inlinemediaobject",)) - return self._concat(el).strip() - - def e_informalequation(self, el): - self._supports_only(el, (self.parent.ns + "mediaobject",)) - return self._concat(el) - - def e_equation(self, el): - self._supports_only(el, (self.parent.ns + "title", - self.parent.ns + "mediaobject")) - title = el.find(self.parent.ns + "title") - if title is not None: - s = "\n\n**%s:**" % self._concat(title).strip() - else: - s = "" - for mo in el.findall(self.parent.ns + "mediaobject"): - s += "\n" + self._conv(mo) - return s - - def e_mediaobject(self, el, substitute=False): - self._supports_only(el, (self.parent.ns + "imageobject", - self.parent.ns + "textobject")) - # assume the most common case is one imageobject and one (or none) - alt = "" - for txto in el.findall(self.parent.ns + "textobject"): - self._supports_only(txto, (self.parent.ns + "phrase",)) - if alt: - alt += "; " - alt += self._normalize_whitespace( - self._concat(txto.find(self.parent.ns + "phrase"))) - symbols = [] - img = "" - for imgo in el.findall(self.parent.ns + "imageobject"): - self._supports_only(imgo, (self.parent.ns + "imagedata",)) - fileref = imgo.find(self.parent.ns + "imagedata").get("fileref") - s = "\n\n.. image:: %s" % fileref - if (alt): - s += "\n :alt: %s" % alt - if substitute: - if fileref not in self._substitutions: - img += s[:4] + " |%s|" % fileref + s[4:] # insert |symbol| - self._substitutions.add(fileref) - symbols.append(fileref) - else: - img += s - img += "\n\n" - if substitute: - return img, symbols - else: - return img - - def e_inlinemediaobject(self, el): - subst, symbols = self.mediaobject(el, substitute=True) - self._buffer += subst - return "".join("|%s|" % i for i in symbols) - - def e_subscript(self, el): - return "\ :sub:`%s`" % self._concat(el).strip() - - def e_superscript(self, el): - return "\ :sup:`%s`" % self._concat(el).strip() - - - # GUI elements - - def e_menuchoice(self, el): - if all(i.tag in ("guimenu", "guimenuitem") for i in el.getchildren()): - self._has_no_text(el) - return ":menuselection:`%s`" % \ - " --> ".join(i.text for i in el.getchildren()) - else: - return self._concat(el) - - def e_guilabel(self, el): - self._has_only_text(el) - return ":guilabel:`%s`" % el.text.strip() - e_guiicon = e_guilabel - e_guimenu = e_guilabel - e_guimenuitem = e_guilabel - e_mousebutton = _no_special_markup - - e_uri = _no_special_markup - - # system elements - - def e_keycap(self, el): - self._has_only_text(el) - return ":kbd:`%s`" % el.text - - def e_application(self, el): - self._has_only_text(el) - return ":program:`%s`" % el.text.strip() - - def e_userinput(self, el): - return "``%s``" % self._concat(el).strip() - - e_systemitem = e_userinput - e_prompt = e_userinput - - def e_filename(self, el): - self._has_only_text(el) - return ":file:`%s`" % el.text - - def e_command(self, el): - return ":command:`%s`" % self._concat(el).strip() - - def e_parameter(self, el): - if el.get("class"): # this hack is specific for fityk manual - return ":option:`%s`" % self._concat(el).strip() - return self.e_emphasis(el) - - def e_cmdsynopsis(self, el): - # just remove all markup and remember to change it manually later - return "\n\nCMDSYN: %s\n" % self._no_markup(el) - - # programming elements - - def e_function(self, el): - return "``%s``" % self._concat(el).strip() - - def e_constant(self, el): - self._has_only_text(el) - return "``%s``" % ( - (el.text or '') + - ''.join(map(self._conv, el.getchildren()))) - - e_varname = e_constant - - # popular block elements - - def e_title(self, el): - # Titles in some elements may be handled from the title's parent. - t = self._concat(el).strip() - level = self._get_level(el) - #parent = el.getparent().tag - ## title in elements other than the following will trigger assertion - #? parent in ("book", "chapter", "section", "variablelist", "appendix") - return self._make_title(t, level) - e_screen = _literal_source - e_literallayout = _literal_source - e_programlisting = _include_source - - def e_blockquote(self, el): - return self._indent(el, 4) - - e_set = _no_special_markup - e_volume = _no_special_markup - e_book = _no_special_markup - e_article = _no_special_markup - e_para = _block_separated_with_blank_line - e_section = _block_separated_with_blank_line - e_appendix = _block_separated_with_blank_line - e_chapter = _block_separated_with_blank_line - e_preface = _block_separated_with_blank_line - e_simplesect = _block_separated_with_blank_line - e_revhistory = _block_separated_with_blank_line - e_info = _block_separated_with_blank_line - - def e_revhistory(self, el): - # TODO: only make a title here if no title has been defined - s = self._make_title("Revision History", 1) - s += self._block_separated_with_blank_line(el) - return s - - def e_entry(self, el): - # TODO: FIXME: directive automatically handled by sphinx ''' - return '' - - def e_indexterm(self, el): - # http://www.docbook.org/tdg/en/html/indexterm.html - ''' - The resulting .rst document will contain some entries such as:: - - :index:`EDIT_ME ` - - Since the EDIT_ME text will appear in the final, formatted document, - it is necessary to replace EDIT_ME with appropriate text from the local context - and weave this index entry into the local context. - - * Use the index role (requires sphinx v.1.1+) for all DocBook elements - * use the (implied) single option as default - * avoid the triple option, it looks bad due to the commas - * options for 'see' (and 'seealso' treated synonymously) should be entered as additional index roles - ''' - logging.info("line %d in %s" % (el.sourceline, str(el.base))) - preferred_significance = el.get("significance", "normal") == 'preferred' - nodes = [el.find(self.parent.ns+t) for t in ('primary', 'secondary', 'tertiary')] - s = "" - if len([c for c in nodes if c is not None]) > 0: - terms = [self._concat(node).strip() for node in nodes if node is not None] - items = "; ".join(terms) - if preferred_significance: - items = "!" + items - s += ":index:`EDIT_ME <%s>` " % items # EDIT_ME will appear in the formatted text, fix it in the editor - - # are there any "see" or "seealso" elements? - related_nodes = [el.find(self.parent.ns+t) for t in ('see', 'seealso')] - if len([c for c in related_nodes if c is not None]) > 0: - seealso_terms = [self._concat(node).strip() for node in related_nodes if node is not None] - items = "; ".join(list(itertools.chain(*[seealso_terms, [terms[0]]]))) - s += ":index:`EDIT_ME ` " % items - return s - - def e_footnote(self, el): - ''' - Collect the content of footnotes in a queue. - Return a generic reference ([#]_) for now. - Write out the queue contents later. - "Later" could be when the file is done processing, - before writing, or earlier. - ''' - logging.info("line %d in %s" % (el.sourceline, str(el.base))) - s = self._concat(el).strip() - self.footnotes.append(s) - return ' [#]_' - - # admonition directives - - def e_note(self, el): - return self._directive(el, 'note:') - def e_caution(self, el): - return self._directive(el, 'caution:') - def e_important(self, el): - return self._directive(el, 'important:') - def e_tip(self, el): - return self._directive(el, 'tip:') - def e_warning(self, el): - return self._directive(el, 'warning:') - - # bibliography - - def e_author(self, el): - # could be in or . - # Hope these conditionals help it apply to both. - self._supports_only(el, (self.parent.ns + "personname", - self.parent.ns + "address", - self.parent.ns + "affiliation", - self.parent.ns + "email",)) - s = "\n\n" - s += self._conv(el.find(self.parent.ns + "personname")).strip() - node = el.find(self.parent.ns + "email") - if node is not None: - s += " ``<%s>``" % self._conv(node).strip() - node = el.find(self.parent.ns + "affiliation") - if node is not None: - s += ", " + self._conv(node).strip() - node = el.find(self.parent.ns + "address") - if node is not None: - s += ", " + self._join_children(node, ", ").strip() - return s - - def e_personname(self, el): - return self._join_children(el, " ").strip() - - e_editor = e_author - e_firstname = _no_special_markup # _has_only_text - e_surname = _no_special_markup - e_othername = _no_special_markup - e_affiliation = _no_special_markup - e_orgname = _no_special_markup - e_city = _no_special_markup - e_state = _no_special_markup - e_country = _no_special_markup - - def e_email(self, el): - self._has_only_text(el) - return self._concat(el).strip() - - def e_authorgroup(self, el): - # TODO: only make a title here if no title has been defined - s = self._make_title("Authorgroup", 1) - s += self._join_children(el, ", ") - return s - - def e_biblioentry(self, el): - self._supports_only(el, (self.parent.ns + "abbrev", - self.parent.ns + "authorgroup", - self.parent.ns + "author", - self.parent.ns + "editor", - self.parent.ns + "title", - self.parent.ns + "publishername", - self.parent.ns + "pubdate", - self.parent.ns + "address")) - s = "\n" - - abbrev = el.find(self.parent.ns + "abbrev") - if abbrev is not None: - self._has_only_text(abbrev) - s += "[%s] " % abbrev.text - - auth = el.find(self.parent.ns + "authorgroup") - if auth is None: - auth = el.find(self.parent.ns + "author") - if auth is not None: - s += "%s. " % self._conv(auth) - - editor = el.find(self.parent.ns + "editor") - if editor is not None: - s += "%s. " % self._conv(editor) - - title = el.find(self.parent.ns + "title") - if title is not None: - self._has_only_text(title) - s += "*%s*. " % title.text.strip() - - address = el.find(self.parent.ns + "address") - if address is not None: - self._supports_only(address, (self.parent.ns + "otheraddr",)) - s += "%s " % address.findtext(self.parent.ns + "otheraddr") - - publishername = el.find(self.parent.ns + "publishername") - if publishername is not None: - self._has_only_text(publishername) - s += "%s. " % publishername.text - - pubdate = el.find(self.parent.ns + "pubdate") - if pubdate is not None: - self._has_only_text(pubdate) - s += "%s. " % pubdate.text - return s - - def e_bibliography(self, el): - self._supports_only(el, (self.parent.ns + "biblioentry",)) - s = self._make_title("Bibliography", 2) + "\n" - s += self._join_children(el, "\n") - return s - - def e_revision(self, el): - self._supports_only(el, (self.parent.ns + "date", - self.parent.ns + "authorinitials", - self.parent.ns + "revnumber", - self.parent.ns + "revdescription",)) - t = [] - for k, v in {"date": "*%s*", - "revnumber": "**%s**", - "authorinitials": "*%s*"}.items(): - node = el.find(self.parent.ns + k) - if node is not None: - self._has_only_text(node) - t.append(v % node.text) - s = "\n\n" - s += self._indent(el.find(self.parent.ns + "revdescription"), - 4, ", ".join(t) + "\n ") - return s - - def e_table(self, el): - # Probably fails for these cases at least: - # * (empty DocBook elements) - # * 0: - for line_num in range( max(map(len, [_.split("\n") for _ in row])) ): - item = [self._pick_line(r.split("\n"), line_num) for r in row] - text += indentation + fmt % tuple(item) - return text - - def find_widths(self): - ''' - measure the maximum width of each column, - considering possible line breaks in each cell - ''' - width = [] - if len(self.labels) > 0: - width = [max(map(len, _.split("\n"))) for _ in self.labels] - for row in self.rows: - row_width = [max(map(len, _.split("\n"))) for _ in row] - if len(width) == 0: - width = row_width - width = map( max, zip(width, row_width) ) - return width - - def _pick_line(self, text, lineNum): - ''' - Pick the specific line of text or supply an empty string. - Convenience routine when analyzing tables. - ''' - if lineNum < len(text): - s = text[lineNum] - else: - s = "" - return s - - -def original_main(args): - if len(args) < 2 or len(args) > 3 or args[1] == '-h' or args[1] == '--help': - sys.stderr.write(__doc__) - sys.exit() - input_file = args[1] - if len(args) == 3: - output_dir = args[2] - else: - output_dir = None - sys.stderr.write("Parsing XML file `%s'...\n" % input_file) - - converter = Db2Rst() - if output_dir is not None: - converter.output_dir = output_dir - result = converter.process(input_file) - if result is not None: - return str(result) - - -if __name__ == '__main__': - #result = original_main(sys.argv) - docbook_file = 'docbook.xml' - if len(sys.argv) == 2 and os.path.exists(sys.argv[1]): - docbook_file = sys.argv[1] - result = original_main([sys.argv[0], docbook_file]) - if result is not None: - print result - diff --git a/_sphinx/docbook.xml b/_sphinx/docbook.xml deleted file mode 100644 index f551deea0..000000000 --- a/_sphinx/docbook.xml +++ /dev/null @@ -1,14 +0,0 @@ - - - - - - - -Hello, world - -This is my first DocBook file. - - - diff --git a/_sphinx/nxdb2rst.py b/_sphinx/nxdb2rst.py deleted file mode 100755 index 00661cf14..000000000 --- a/_sphinx/nxdb2rst.py +++ /dev/null @@ -1,371 +0,0 @@ -#!/usr/bin/env python - -########### SVN repository information ################### -# $Date: 2011-11-10 00:33:02 -0600 (Thu, 10 Nov 2011) $ -# $Author: Pete Jemian $ -# $Revision: 1009 $ -# $URL: https://svn.nexusformat.org/definitions/trunk/sphinx/runner.py $ -# $Id: runner.py 1009 2011-11-10 06:33:02Z Pete Jemian $ -########### SVN repository information ################### - -''' -Overrides certain handler routines for -translating DocBook elements into restructured -text (reST) documents. -''' - - -import os -import db2rst -import lxml.etree -import logging -import argparse - -NEXUS_DIR = "../docbook" -NEXUS_DIR = os.path.abspath(NEXUS_DIR) -INDENT = ' '*4 -__description__ = "Translate NeXus Docbook source files into ReST source files" -__version__ = "$Id: runner.py 1009 2011-11-10 06:33:02Z Pete Jemian $" - - -class Convert(db2rst.Convert): - ''' - NeXus overrides of the db2rst Convert class for these DocBook elements: - + table - + figure - + informalexample - + example - + programlisting - + programlistingco - + subtitle - + info - + revdescription - + legalnotice - + revhistory - + areaspec - + calloutlist - + callout - + xi:include where xmlns:xi="http://www.w3.org/2001/XInclude" - ''' - - def e_table(self, el): - s = "\n\n" - id = el.get(self.parent.id_attrib, "") - if len(id) > 0: - s += ".. _%s:\n\n" % id - - s += ".. rubric:: Table: " - title = self.childNodeText(el, 'title') - if title is not None: - s += title - s += "\n\n" - - t = db2rst.Table() - tgroup_node = el.find(self.parent.ns+'tgroup') - thead = tgroup_node.find(self.parent.ns+'thead') - if thead is not None: - row = thead.find(self.parent.ns+'row') - t.labels = self.get_entry_text_list( row ) - - tbody = tgroup_node.find(self.parent.ns+'tbody') - rows = tbody.findall(self.parent.ns+'row') - t.rows = map(self.get_entry_text_list, rows) - - s = t.reST(fmt='simple') - return s - - def get_entry_text_list(self, parent_node): - ''' - Return a list with the text of the child entry nodes. - The members of the list are strings with optional line breaks. - ''' - nodes = parent_node.findall(self.parent.ns+'entry') - rowText = [self._conv(item).split("\n") for item in nodes] - return map( "\n".join, rowText) - - def pick_line(self, text, lineNum): - ''' - pick the specific line of text or supply an empty string - ''' - if lineNum < len(text): - s = text[lineNum] - else: - s = "" - return s - - def e_figure(self, el): - ''' - may contain a programlisting or a mediaobject - - .. figure:: nexuslogo.png - :width: 200px - :align: center - :height: 100px - :alt: alternate text - :figclass: align-center - ''' - id = el.get(self.parent.id_attrib, "") - title = self.childNodeText(el, "title") - - content = self._concat(el).strip() - - logging.info("line %d in %s" % (el.sourceline, str(el.base))) - pl_node = el.find(self.parent.ns+"programlisting") - if pl_node is not None: - # contains a programlisting - s = "\n\n.. compound::\n\n" - s += INDENT + ".. rubric:: Figure: %s\n\n" % title - for line in content.split('\n'): - s += line + '\n' - s += '\n' + INDENT - return s - - mo_node = el.find(self.parent.ns+"mediaobject") - if mo_node is None: - return content + " --> e_figure" - # contains a mediaobject - - io_node = mo_node.find(self.parent.ns+"imageobject") - if io_node is None: - return content + " --> e_figure" - # contains an imageobject - - image_node = io_node.find(self.parent.ns+"imagedata") - if image_node is None: - return content + " --> e_figure" - # contains imagedata - - # - # .. figure:: picture.png - # :scale: 50 % - # :alt: map to buried treasure - name = image_node.get('fileref') - width = image_node.get('width', None) - height = image_node.get('height', None) - scalefit = image_node.get('scalefit', None) - # TODO: Need to handle width - # TODO: Need to handle scalefit - # TODO: Is height used at all? Might remove it. - s = "\n\n.. compound::\n\n" - s += INDENT + ".. _%s:\n\n" % id - s += INDENT + ".. rubric:: Figure: %s\n\n" % title - s += "\n\n" + ".. figure:: %s\n" % name - s += INDENT + ":alt: %s\n" % id - s += "\n" - for line in str(title).split('\n'): - s += INDENT + line + '\n' - return s - - def e_informalexample(self, el): - logging.info("line %d in %s" % (el.sourceline, str(el.base))) - return self._concat(el) - - def e_example(self, el): - logging.info("line %d in %s" % (el.sourceline, str(el.base))) - id = el.get(self.parent.id_attrib, "") - title = self.childNodeText(el, "title") - pl_node = el.find(self.parent.ns+"programlisting") - plco_node = el.find(self.parent.ns+"programlistingco") - if (pl_node is not None) or (plco_node is not None): - # contains a programlisting - node = pl_node - if node is None: - node = plco_node - s = "\n\n.. compound::\n\n" - s += INDENT + ".. rubric:: Figure: %s\n\n" % title - for line in self._concat(node).strip().split('\n'): - s += line + '\n' - s += '\n' + INDENT - return s - return self._concat(el).strip() + " --> e_example" - - def e_programlisting(self, el): - logging.info("line %d in %s" % (el.sourceline, str(el.base))) - language = el.get("language", "guess") - linenumbering = 'numbered' in el.get("linenumbering", '') - s = self._concat(el).strip() - lmatch = '.. include::' - if s.startswith(lmatch): # include a program - s = "\n.. literalinclude:: %s\n" % s[len(lmatch):].strip() - s += INDENT + ':tab-width: 4\n' - if linenumbering: - s += INDENT + ':linenos:\n' - s += INDENT + ':language: %s\n' % language - s += '\n' + INDENT - return s - - # inline content - t = '\n\n.. code-block:: %s\n' % language - if linenumbering: - t += INDENT + ':linenos:\n' - t += '\n' - for line in s.split('\n'): - t += INDENT + line + '\n' - return t - - def e_programlistingco(self, el): - pl_node = el.find(self.parent.ns+"programlisting") - if pl_node is not None: # ignore the callout and just process the listing - return self._concat(pl_node).strip() - logging.info("line %d in %s" % (el.sourceline, str(el.base))) - return self._concat(el).strip() + " --> e_programlistingco" - - def e_subtitle(self, el): - ''' - figure with a caption:: - - .. _fig.data-pre-nexus: - - .. figure:: data-pre-nexus.jpg - :width: 200 pt - :alt: example NeXus data file hierarchy - - *N* separate file formats - ''' - t = self._concat(el).strip() - return "\n\n" + t + "\n" + "@" * len(t) - - def e_info(self, el): - ''' - NeXus-style - - This produces the ReST result:: - - .. include:: preface.xml - ''' - logging.info("line %d in %s" % (el.sourceline, str(el.base))) - href = el.get('href', None) - if href is not None: - return "\n\n.. include:: %s\n\n" % href - return "\n\n.. UNHANDLED LINE %d in %s" % (el.sourceline, str(el.base)) - - def e_areaspec(self, el): - # related to e_calloutlist - # idea: when the XML file is first open, - # parse all the \programlistingco\areaspec\\area elements - # and build a dictionary with the coords v. xml:id - # Then, use that dictionary when processing each callout element - ''' - - - - - - - - - - - - - - - - - - [line 6] - Open the file NXfile.nxs with - create - access (implying write access). - NAPI - returns a file identifier of type NXhandle. - - - ''' - return "" - - def e_calloutlist(self, el): - # FIXME: - logging.info("line %d in %s" % (el.sourceline, str(el.base))) - s = "\n\n.. compound::\n\n" - s += INDENT + ".. _%s:\n\n" % id - s += INDENT + ".. rubric:: Callout List\n\n" - for node in el.findall(self.parent.ns+'callout'): - t = self._concat(node).strip() - s += INDENT + "#. callout item:\n" - for line in t.split('\n'): - s += INDENT + INDENT + line + '\n' - return s - - def e_callout(self, el): - # FIXME: - logging.info("line %d in %s" % (el.sourceline, str(el.base))) - return self._concat(el).strip() - - -if __name__ == '__main__': - parser = argparse.ArgumentParser(description=__description__) - parser.add_argument('docbook_file', action='store', help="DocBook file name (input)") - parser.add_argument('-v', '--version', action='version', version=__version__) - args = parser.parse_args() - dbfile = args.docbook_file.strip() - if not os.path.exists(dbfile): - print "%s does not exist" % dbfile - exit(1) - converter = db2rst.Db2Rst() - result = converter.process( dbfile, Convert ) - if result is not None: - print result - diff --git a/_sphinx/nxdl2rst.py b/_sphinx/nxdl2rst.py deleted file mode 100755 index f0e21adf9..000000000 --- a/_sphinx/nxdl2rst.py +++ /dev/null @@ -1,262 +0,0 @@ -#!/usr/bin/env python - -########### SVN repository information ################### -# $Date$ -# $Author$ -# $Revision$ -# $URL$ -# $Id$ -########### SVN repository information ################### - -''' -Extracts documentation from NXDL files and builds the NeXus manual page. - -For an example of what the DocBook page provides, see -http://download.nexusformat.org/doc/html/ClassDefinitions-Base.html#NXentry -''' - - -import sys, os -import lxml.etree -import db2rst -import nxdb2rst -from argparse import ArgumentError - - -class Describe: - - def __init__(self): - self.nxdlFile = None - self.nxdlType = None - self.nxdlName = None - self.fileSuffix = '.rst' - self.ns = {'nx': 'http://definition.nexusformat.org/nxdl/3.1'} - - def parse(self, nxdlFile): - self.nxdlFile = os.path.normpath( nxdlFile ) - - stem, self.nxdlName = os.path.split(nxdlFile[:nxdlFile.find('.nxdl.xml')]) - self.nxdlType = os.path.split(stem)[1] - self.tree = lxml.etree.parse(nxdlFile) - - def report(self, outputDir = '.'): - rstFile = os.path.join(outputDir, self.nxdlType , self.nxdlName+ self.fileSuffix) - path, _ = os.path.split(self.nxdlFile) - - root = self.tree.getroot() - - rest = self.make_heading(self.nxdlName, 1, self.nxdlName, True) - - rest += ".. index:: ! . NXDL %s; %s\n\n" % (self.nxdlType, self.nxdlName) - - URL = "http://svn.nexusformat.org/definitions/trunk/%s/%s.nxdl.xml" % (self.nxdlType, self.nxdlName) - extends = root.get('extends', 'none') - if extends != "none": - extends = ":ref:`%s`" % extends - - rest += self.get_doc(root, "No documentation provided.") + "\n\n" - - t = db2rst.Table() - t.labels = ('item', 'Description', ) - t.rows.append( ['category', self.nxdlType, ] ) - t.rows.append( ['NXDL class', "*%s*" % self.nxdlName, ] ) - t.rows.append( ['URL', "%s" % URL, ] ) - t.rows.append( ['version', root.get('version', 'unknown'), ] ) - t.rows.append( ['extends class', extends, ] ) - t.rows.append( ['included classes', self.groups_list(root), ] ) - rest += t.reST(fmt='simple') - - rest += "\n" - rest += ".. rubric:: Basic Structure of **%s**\n\n" % self.nxdlName - # make the XSLT transformation, see: http://lxml.de/xpathxslt.html#xslt - self.xsltFile = "nxdlformat.xsl" # could learn from the XML file? - xsltFile = os.path.join(path, self.xsltFile) - xslt = lxml.etree.XSLT( lxml.etree.parse(xsltFile) ) # prepare the transform - text = ":linenos:\n\n" - text += str( xslt( self.tree ) ) # make the transform - rest += ".. code-block:: text\n" + self.indented_lines(4, text) - - rest += self.symbols_table(root) + "\n\n" - - rest += self.top_attributes_table(root) + "\n\n" - - t = db2rst.Table() - t.labels = ('Name and Attributes', - 'Type', - 'Units', - 'Description (and Occurrences)', ) - for node in root.findall('*'): - try: - tag = node.tag.split('}')[-1] - except: - continue - if tag in ('group', 'field'): - name = node.get('name', {'group': '', 'field': 'unknown'}[tag]) - type = node.get('type', {'group': 'unknown', 'field': 'NX_CHAR'}[tag]) - units = '' - description = '' - if name == '': - name = '..' - t.rows.append( [name, type, units, description, ] ) - - rest += "\n.. rubric:: Comprehensive Structure of **%s**\n\n" % self.nxdlName - rest += t.reST() - - return rstFile, rest - - def make_heading(self, title, level, ref = None, upperBar = False): - '''Return a formatted ReST heading - - :param str title: the text of the title - :param int level: level number (1, 2, 3, 4, ...) - :param str ref: (optional) text of the reference label - :param bool upperBar: (optional) add an upper bar to the heading - ''' - s = "" - if ref is not None: - s += ".. _%s:\n\n" % ref - - symbols = "# = - ~ ^ . * + _".split() - if level < 1 or level > len(symbols): - raise ArgumentError, "level must be between 1 and %d, received %d" % (len(symbols), level) - - bar = symbols[level-1]*len(title) + "\n" - if upperBar: - s += bar - s += title + "\n" + bar + "\n" - - return s - - def make_definition(self, term, definition): - '''Return a string-formatted ReST definition - - :param str term: the thing to be defined - :param str definition: the words to describe the term - ''' - s = term + "\n" - s += self.indented_lines(4, definition) - s += "\n" - return s - - def indented_lines(self, numSpaces, lines): - '''Return a string of indented lines from text with line breaks - - :param int numSpaces: number of spaces to indent - :param str lines: text with embedded line breaks (assumes UNIX EOL - might be a problem) - ''' - s = "" - indent = " "*numSpaces - for line in lines.split("\n"): - s += "%s%s\n" % (indent, line) - return s - - def groups_list(self, root): - '''Return a string of reST references to the groups used - in this NXDL, sorted alphabetically - - :param root: root of XML tree - ''' - groups = lxml.etree.ETXPath( './/{%s}group' % self.ns['nx'] )(root) - if len(groups) > 0: - L = [] - for G in groups: - N = ":ref:`%s`" % G.get('type') - if N not in L: - L.append( N ) - groups = ",\n".join(sorted( L )) - else: - groups = "none" - return groups - - def symbols_table(self, root): - '''Return a table of ReST references to the symbols defined in this NXDL - - :param root: root of XML tree - ''' - rest = "\n.. rubric:: Symbols used in definition of **%s**\n\n" % self.nxdlName - symbols = "none" - node = root.find( '{%s}symbols' % self.ns['nx'] ) - if node is None: - rest += 'No symbols are defined in this NXDL file\n' - else: - table = db2rst.Table() - table.labels = ('Symbol', 'Description', ) - title = self.get_doc(node, None) - if title is not None: - rest += title + "\n" - for SN in lxml.etree.ETXPath( './/{%s}symbol' % self.ns['nx'] )(node): - symbol = "``%s``" % SN.get('name') - desc = "%s" % self.get_doc(SN).strip('\n') - table.rows.append( [symbol, desc] ) - rest += table.reST() - return rest - - def get_doc(self, node, undefined = ""): - DN = node.find( '{%s}doc' % self.ns['nx'] ) - if DN is None: - doc = undefined - else: - # TODO: this could be much, much better - ns = self.ns['nx'] - obj = Convert(DN, namespace=ns) - doc = str(obj).strip() + "\n" - #doc = DN.text - return doc - - def top_attributes_table(self, root): - '''Return a table of ReST references to the attributes defined - in the root element of this NXDL. - - :param root: root of XML tree - ''' - rest = "" - nodelist = root.findall( '{%s}attribute' % self.ns['nx'] ) - if len(nodelist) > 0: - fmt = "\n.. rubric:: Attributes of ``definition`` element in **%s**\n\n" - rest = fmt % self.nxdlName - table = db2rst.Table() - table.labels = ('Attributes', 'Type', 'Units', 'Description (and Occurrences) ', ) - for node in nodelist: - name = '@' + node.get('name') - type = node.get('type', 'NX_CHAR') - # FIXME: this has not been finished - units = node.get('type', '..') - # start db2rst parsing from this node - # put result into description - description = '..' - table.rows.append( [name, type, units, description] ) - rest += table.reST() - return rest - - -class Convert(nxdb2rst.Convert): - ''' - Treat our NXDL doc element like a DocBook para element - ''' - e_doc = db2rst.Convert.e_para - - -if __name__ == '__main__': - NXDL_DIRS = ['../base_classes', - '../applications', - '../contributed_definitions', ] - OUTPUT_DIR = os.path.join(*list('./source/volume2/NXDL'.split('/'))) - nxdl_file_list = [] - for dir in NXDL_DIRS: - fulldir = os.path.abspath(dir) - for _, dirs, files in os.walk(dir): - if '.svn' in dirs: - dirs.remove('.svn') - for file in sorted(files): - if file.endswith('.nxdl.xml'): - nxdlFile = os.path.join(fulldir, file) - nxdl_file_list.append(nxdlFile) - obj = Describe() - obj.parse(nxdlFile) - rstFile, restText = obj.report(OUTPUT_DIR) - print rstFile - print restText - f = open (rstFile, 'w') - f.write(restText + "\n") - f.close() - print len(nxdl_file_list), ' NXDL files discovered' diff --git a/_sphinx/runner.py b/_sphinx/runner.py deleted file mode 100755 index 315a274d7..000000000 --- a/_sphinx/runner.py +++ /dev/null @@ -1,119 +0,0 @@ -#!/usr/bin/env python - -########### SVN repository information ################### -# $Date$ -# $Author$ -# $Revision$ -# $URL$ -# $Id$ -########### SVN repository information ################### - -''' -Runs the ``db2rst`` program on a specific DocBook XML file. -This code was written to test the db2rst code as it is being -extended to convert the NeXus documentation into sphinx: - - converter = Db2Rst() - result = converter.process( input_file ) - if result is not None: - return str(obj) - -''' - - -import sys, os -import nxdb2rst, db2rst -import logging - -NEXUS_DIR = "../docbook" -NEXUS_DIR = os.path.abspath(NEXUS_DIR) - -DocBook_FILE_LIST = [] - - -def buildList(item): - path = os.path.join(NEXUS_DIR, item) - if os.path.exists(path): - DocBook_FILE_LIST.append(path) - - -buildList("applying-nexus.xml") -buildList("authorgroup.xml") -buildList("ClassDefinitions.xml") # problems with in
-buildList("community.xml") -buildList("datarules.xml") -buildList("design.xml") -buildList("examples.xml") -buildList("ex_code_napi.xml") -buildList("ex_code_native.xml") -buildList("faq.xml") -buildList("fileformat.xml") -buildList("h5py-example.xml") -#buildList("hierarchy.xml") # not used in the manual now -buildList("history.xml") -#buildList("impatient.xml") # not used in the manual now -buildList("installation.xml") -buildList("introduction.xml") -buildList("issues.xml") -buildList("license.xml") -buildList("mailinglist.xml") -buildList("motivations.xml") -buildList("napi-java.xml") -#buildList("NAPI.xml") # !!! problem here !!! ` with the index. - -.. index:: - single: item3, item4 - -You can even combine separate index entries under one directive. - -.. index:: - pair: item6; item7 - pair: item8; item9 - single: item1; item5 - see: item11; item12 - seealso: item13; item14 - see: item8; item6 - see: item4; item8; item6 - -Emphasize an **item** in the index with a preceding bang (!). - -.. index:: !item0 - -There are index entries that appear on a :index:`single ` line. -Sometimes, they have some :index:`hierarchy `. -It is possible to :index:`coordinate ` entries, -even with some complexity. - -What about the :index:`tertiary, inline Docbook index ` entry? -This is not the way to handle the *seealso* :index:`element `. -Instead, use :index:`two ` :index:`separate ` index roles. diff --git a/_sphinx/source/authors.rst b/_sphinx/source/authors.rst deleted file mode 100755 index 5cd2959ab..000000000 --- a/_sphinx/source/authors.rst +++ /dev/null @@ -1,17 +0,0 @@ -.. $Id$ - -Documentation Authors -======================================================================== - -.. index:: authors - -These people have made substantial contributions to the NeXus manual: - -* Ray Osborn, Argonne National Laboratory, ```` -* Mark Koennecke, Paul Scherrer Institut, ```` -* Przemek Klosowski, U. of Maryland and NIST, ```` -* Frederick Akeroyd, Rutherford Appleton Laboratory, ```` -* Peter F. Peterson, Spallation Neutron Source, ```` -* Pete R. Jemian, Advanced Photon Source, ```` -* Stuart I. Campbell, Oak Ridge National Laboratory, ```` -* Tobias Richter, Diamond Light Source Ltd., ```` diff --git a/_sphinx/source/cheatsheet.rst b/_sphinx/source/cheatsheet.rst deleted file mode 100755 index 898f810cf..000000000 --- a/_sphinx/source/cheatsheet.rst +++ /dev/null @@ -1,214 +0,0 @@ -.. $Id$ - -################# -Sphinx Cheatsheet -################# - -This is a sphinx cheat sheet and will be removed later. - -Section headings automatically get labels assigned. -For example, see this: `Demo list-table`_ - -====== ================================================= -symbol description -====== ================================================= -`#` with overline, for parts -`*` with overline, for chapters -`=` for sections -`-` for subsections -`^` for subsubsections -`"` for paragraphs -====== ================================================= - - -Typesetting Math and Equations -++++++++++++++++++++++++++++++ - -Enjoy inline math such as: :math:`E=mc^2` -using LaTeX markup. You will need the ``matplotlib`` -package in your Python. There is also separate math. - -.. sidebar:: TODO: - :subtitle: adjust `conf.py`? - - Sphinx has some inconsistency with this expression:: - - .. ! this is a candidate for conditional compilation - make html needs two backslashes while - make latexpdf needs one backslash - - .. math:: - - \tilde I(Q) = {2 \over l_o} \ \int_0^\infty I(\sqrt{(q^2+l^2)}) \ dl - - .. tip:: Perhaps some modification of `conf.py` would help? - - The Sphinx HTML renderer handles simple math this way but - not all LaTeX markup. The HTML renderer needs two backslashes - while the LaTeX renderer only needs one. - -This was possible with this definition -in `conf.py`:: - - extensions = ['sphinx.ext.pngmath', 'sphinx.ext.ifconfig'] - extensions.append( 'matplotlib.sphinxext.mathmpl' ) - -Other Links -+++++++++++ - -Here are some links to more help about reStructuredText formatting. - -reST home page - http://docutils.sourceforge.net/rst.html - -Docutils - http://docutils.sourceforge.net/ - -**Very useful!** - http://docutils.sourceforge.net/docs/ref/rst/directives.html - -Independent Overview - http://www.siafoo.net/help/reST - -Wikipedia - http://en.wikipedia.org/wiki/ReStructuredText - -reST Quick Reference - http://docutils.sourceforge.net/docs/user/rst/quickref.html - -Comparison: text v. reST v. DocBook - http://www.ibm.com/developerworks/library/x-matters24/ - -Curious - http://rst2a.com/ - - -Demo list-table -+++++++++++++++ - -Does this work? - -It was found on this page - http://docutils.sourceforge.net/docs/ref/rst/directives.html - -.. list-table:: Frozen Delights! - :widths: 15 10 30 - :header-rows: 1 - - * - Treat - - Quantity - - Description - * - Albatross - - 2.99 - - On a stick! - * - Crunchy Frog - - 1.49 - - If we took the bones out, it wouldn't be - crunchy, now would it? - * - Gannet Ripple - - 1.99 - - On a stick! - -.. Yes, it _does_ work. - Use it for the tables in the NXDL description. - -Numbered Lists -++++++++++++++ - -What about automatically numbering a list? - - #. How will the numbering look? - #. Will it look great? - - #. Even more great? - What about more than one line of text in the source code? - - 8. Made a jump in the numbering. - But that started a new list and produced a compile error. - What about more than one line of text in the source code? - Cannot use multiple paragraphs in a list, it seems. - Maybe there is a way. - #. And another ... - - F. Perhaps we can switch to lettering? - Only if we start a new list. - But we needed a blank line at the switch. - #. Another lettered item. - -.. Yup, that works. - - -About Linking -+++++++++++++ - -What about a link to :ref:`indirect hyperlinks` on another page? - -The reSt documentation says that links can be written as:: - - `NeXus: User Manual`_ - -This works for sphinx, as long as the link target -is in the same ``.rst`` document. -**But**, when the link is in -a different document, sphinx requires the citation to use:: - - :ref:`NeXus User Manual` - -and the target must be a section with an explicit -hyperlink definition, such as on the top page of these docs:: - - .. _NeXus User Manual: - - ###################### - NeXus: User Manual - ###################### - -This is the correct link: :ref:`NeXus User Manual`. - -Missing Links -+++++++++++++ - -These sections show up as missing links. - -Can you find the `history`_ link below? -What about the history_ link below? -This works: :ref:`History` (or :ref:`history`). - -.. _History: - -history (not converted yet) -^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -.. _Utilities: - -utilities (not converted yet) -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -.. _nxdl_tutorial-creatingnxdlspec: - -nxdl_tutorial-creatingnxdlspec (not converted yet) -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -.. _nxdata-structure: - -nxdata-structure (not converted yet) - -.. _NIAC-link: - -NIAC description -^^^^^^^^^^^^^^^^ - -.. _example.data-linking: - -example.data-linking (not converted yet) -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -.. _cross-reference example: - -Section to cross-reference --------------------------- - -This is the text of the section. - -It refers to the section itself, see :ref:`cross-reference example`. -What about a section on another page, such as :ref:`footnote references`? diff --git a/_sphinx/source/conf.py.in b/_sphinx/source/conf.py.in deleted file mode 100755 index d1ee85c24..000000000 --- a/_sphinx/source/conf.py.in +++ /dev/null @@ -1,277 +0,0 @@ -# -*- coding: utf-8 -*- -# -# $Id$ -# -# NeXus: User Guide and Reference Documentation build configuration file, created by -# sphinx-quickstart on Wed May 18 12:57:35 2011. -# -# This file is execfile()d with the current directory set to its containing dir. -# -# Note that not all possible configuration values are present in this -# autogenerated file. -# -# All configuration values have a default; values that are commented out -# serve to show the default. - -# This file is processed by CMake to generate conf.py with @MACRO@ values replaced - -import sys, os - -# If extensions (or modules to document with autodoc) are in another directory, -# add these directories to sys.path here. If the directory is relative to the -# documentation root, use os.path.abspath to make it absolute, like shown here. -#sys.path.insert(0, os.path.abspath('.')) - -# -- General configuration ----------------------------------------------------- - -# If your documentation needs a minimal Sphinx version, state it here. -needs_sphinx = '1.1' # the :index: role debuted in v1.1 - -# Add any Sphinx extension module names here, as strings. They can be extensions -# coming with Sphinx (named 'sphinx.ext.*') or your custom ones. -extensions = [] -extensions.append( 'sphinx.ext.pngmath' ) -extensions.append( 'sphinx.ext.ifconfig' ) -extensions.append( 'matplotlib.sphinxext.mathmpl' ) -extensions.append( 'sphinx.ext.todo' ) -extensions.append( 'sphinx.ext.ifconfig' ) -extensions.append( 'sphinx.ext.viewcode' ) - -# Add any paths that contain templates here, relative to this directory. -templates_path = ['@SOURCEDIR@/_templates'] - -# The suffix of source filenames. -source_suffix = '.rst' - -# The encoding of source files. -#source_encoding = 'utf-8-sig' - -# The master toctree document. -master_doc = 'index' - -# General information about the project. -project = u'NeXus: Manual' -copyright = u'2014, http://nexusformat.org' - -# The version info for the project you're documenting, acts as replacement for -# |version| and |release|, also used in various other places throughout the -# built documents. -# -# The short X.Y version. -version = '2012' -# The full version, including alpha/beta/rc tags. -release = '2012-05' - -nxdl_version = "@NXDL_RELEASE@" # from nxdl_release.cmake -if nxdl_version is not None: - version = nxdl_version.split('.')[0] - release = nxdl_version - -# The language for content autogenerated by Sphinx. Refer to documentation -# for a list of supported languages. -#language = None - -# There are two options for replacing |today|: either, you set today to some -# non-false value, then it is used: -#today = '' -# Else, today_fmt is used as the format for a strftime call. -#today_fmt = '%B %d, %Y' - -# List of patterns, relative to source directory, that match files and -# directories to ignore when looking for source files. -exclude_patterns = [] - -# The reST default role (used for this markup: `text`) to use for all documents. -#default_role = None - -# If true, '()' will be appended to :func: etc. cross-reference text. -#add_function_parentheses = True - -# If true, the current module name will be prepended to all description -# unit titles (such as .. function::). -#add_module_names = True - -# If true, sectionauthor and moduleauthor directives will be shown in the -# output. They are ignored by default. -#show_authors = False - -# The name of the Pygments (syntax highlighting) style to use. -pygments_style = 'sphinx' - -# A list of ignored prefixes for module index sorting. -#modindex_common_prefix = [] - - -# -- Options for HTML output --------------------------------------------------- - -# The theme to use for HTML and HTML Help pages. See the documentation for -# a list of builtin themes. -#html_theme = 'default' -html_theme = 'sphinxdoc' -html_theme = 'agogo' - -# Theme options are theme-specific and customize the look and feel of a theme -# further. For a list of options available for each theme, see the -# documentation. -#html_theme_options = {} - -# Add any paths that contain custom themes here, relative to this directory. -#html_theme_path = [] - -# The name for this set of Sphinx documents. If None, it defaults to -# " v documentation". -#html_title = None - -# A shorter title for the navigation bar. Default is the same as html_title. -#html_short_title = None - -# The name of an image file (relative to this directory) to place at the top -# of the sidebar. -#html_logo = None -html_logo = "@SOURCEDIR@/nexuslogo.png" - -# The name of an image file (within the static path) to use as favicon of the -# docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32 -# pixels large. -#html_favicon = None - -# Add any paths that contain custom static files (such as style sheets) here, -# relative to this directory. They are copied after the builtin static files, -# so a file named "default.css" will overwrite the builtin "default.css". -html_static_path = ['@SOURCEDIR@/_static'] - -# If not '', a 'Last updated on:' timestamp is inserted at every page bottom, -# using the given strftime format. -html_last_updated_fmt = '%b %d, %Y' - -# If true, SmartyPants will be used to convert quotes and dashes to -# typographically correct entities. -#html_use_smartypants = True - -# Custom sidebar templates, maps document names to template names. -#html_sidebars = {} - -# Additional templates that should be rendered to pages, maps page names to -# template names. -#html_additional_pages = {} - -# If false, no module index is generated. -#html_domain_indices = True - -# If false, no index is generated. -#html_use_index = True - -# If true, the index is split into individual pages for each letter. -#html_split_index = False - -# If true, links to the reST sources are added to the pages. -#html_show_sourcelink = True - -# If true, "Created using Sphinx" is shown in the HTML footer. Default is True. -#html_show_sphinx = True - -# If true, "(C) Copyright ..." is shown in the HTML footer. Default is True. -#html_show_copyright = True - -# If true, an OpenSearch description file will be output, and all pages will -# contain a tag referring to it. The value of this option must be the -# base URL from which the finished HTML is served. -#html_use_opensearch = '' - -# This is the file name suffix for HTML files (e.g. ".xhtml"). -#html_file_suffix = None - -# Output file base name for HTML help builder. -htmlhelp_basename = 'nexus' - - -# -- Options for LaTeX output -------------------------------------------------- - -# The paper size ('letter' or 'a4'). -#latex_paper_size = 'letter' - -# The font size ('10pt', '11pt' or '12pt'). -latex_font_size = '11pt' - -# Grouping the document tree into LaTeX files. List of tuples -# (source start file, target name, title, author, documentclass [howto/manual]). -latex_documents = [ - ('index', 'nexus.tex', u'NeXus: a common data format for neutron, x-ray, and muon science', - u'http://nexusformat.org', 'manual'), -] - -# The name of an image file (relative to this directory) to place at the top of -# the title page. -#latex_logo = None -latex_logo = "@SOURCEDIR@/nexuslogo.png" - -# For "manual" documents, if this is true, then toplevel headings are parts, -# not chapters. -#latex_use_parts = False -latex_use_parts = True - -# If true, show page references after internal links. -#latex_show_pagerefs = False -latex_show_pagerefs = True - -# If true, show URL addresses after external links. -#latex_show_urls = False - -# Additional stuff for the LaTeX preamble. -#latex_preamble = '' - -# Documents to append as an appendix to all manuals. -#latex_appendices = [] - -# If false, no module index is generated. -#latex_domain_indices = True - - -# -- Options for manual page output -------------------------------------------- - -# One entry per manual page. List of tuples -# (source start file, name, description, authors, manual section). -man_pages = [ - ('index', 'nexus', u'NeXus: User Guide and Reference Documentation', - [u'http://nexusformat.org'], 1) -] - - -# -- Options for Epub output --------------------------------------------------- - -# Bibliographic Dublin Core info. -epub_title = u'NeXus: User Guide and Reference Documentation' -epub_author = u'http://nexusformat.org' -epub_publisher = u'http://nexusformat.org' -epub_copyright = u'2012, http://nexusformat.org' - -# The language of the text. It defaults to the language option -# or en if the language is not set. -#epub_language = '' - -# The scheme of the identifier. Typical schemes are ISBN or URL. -#epub_scheme = '' - -# The unique identifier of the text. This can be a ISBN number -# or the project homepage. -#epub_identifier = '' - -# A unique identification for the text. -#epub_uid = '' - -# HTML files that should be inserted before the pages created by sphinx. -# The format is a list of tuples containing the path and title. -#epub_pre_files = [] - -# HTML files shat should be inserted after the pages created by sphinx. -# The format is a list of tuples containing the path and title. -#epub_post_files = [] - -# A list of files that should not be packed into the epub file. -#epub_exclude_files = [] - -# The depth of the table of contents in toc.ncx. -#epub_tocdepth = 3 - -# Allow duplicate toc entries. -#epub_tocdup = True diff --git a/_sphinx/source/contents.rst b/_sphinx/source/contents.rst deleted file mode 100755 index 1c6cdd1b3..000000000 --- a/_sphinx/source/contents.rst +++ /dev/null @@ -1,19 +0,0 @@ -.. $Id$ - - -This manual is also available in `a PDF version. `_ - -Contents -======== - -.. toctree:: - :maxdepth: 2 - - preface - volume1/index - volume2/index - authors - TODO - -* :ref:`genindex` -* :ref:`search` diff --git a/_sphinx/source/frontmatter.rst b/_sphinx/source/frontmatter.rst deleted file mode 100755 index a90010d9b..000000000 --- a/_sphinx/source/frontmatter.rst +++ /dev/null @@ -1,37 +0,0 @@ -.. $Id$ - -.. _frontmatter: - -front matter -==================================== - -copyright -++++++++++++++++++ - -publication date: |today| - -Copyright (C) 1996-2012, -NeXus International Advisory Committee - -http://www.nexusformat.org - - The NeXus manual is licensed under the terms of the - GNU Free Documentation License version 1.3. See the FDL license - file included with the source of this manual or refer to - http://www.gnu.org/licenses/fdl-1.3.txt for more details. - - The examples in the NeXus manual are licensed under the terms of the - GNU Lesser General Public License version 3. See the LGPL license - file included with the source of this manual or refer to - http://www.gnu.org/licenses/lgpl-3.0.txt for more details. - -other -++++++++++++++++++ - -.. toctree:: - :maxdepth: 1 - :glob: - - cheatsheet - revhistory - markup-spec diff --git a/_sphinx/source/index.rst b/_sphinx/source/index.rst deleted file mode 100755 index b83968a8c..000000000 --- a/_sphinx/source/index.rst +++ /dev/null @@ -1,28 +0,0 @@ -.. NeXus: a common data format for neutron, x-ray, and muon science documentation master file, created by - $Id$ - -.. :title-reference:`NeXus Documentation: User Manual and Reference Documentation` - -################################################################ -NeXus: a common data format for neutron, X-ray, and muon science -################################################################ - -NeXus is a common data format for neutron, -X-ray, and muon science. It is developed as an -international standard by scientists and programmers -representing major scientific facilities in Europe, Asia, -Australia, and North America in order to facilitate -greater cooperation in the analysis and visualization -of neutron, X-ray, and muon data. - -NeXus home: -http://nexusformat.org - -.. toctree:: - :maxdepth: 1 - :glob: - - contents - frontmatter - -This manual built |today| diff --git a/_sphinx/source/markup-spec.rst b/_sphinx/source/markup-spec.rst deleted file mode 100755 index 46f619b41..000000000 --- a/_sphinx/source/markup-spec.rst +++ /dev/null @@ -1,1021 +0,0 @@ -.. $Id$ - -======================================= - reStructuredText Markup Specification -======================================= -Author: David Goodger -Contact: dgoodger@bigfoot.com -Version: 0.2 -Date: 2001-05-29 - -.. sidebar:: Help for reST authors - - This - `document `_, - while old, presents information useful - to authors of reST documents, such as this manual. - - This will be removed in the released - version of the NeXus documentation. - -reStructuredText_ is plain text that uses simple and intuitive constructs -to indicate the structure of a document. These constructs are equally easy -to read in raw and processed forms. This document is itself an example of -reStructuredText (raw, if you are reading the text file, or processed, if -you are reading an HTML document, for example). reStructuredText is a -candidate markup syntax for the `Python Docstring Processing System`_. - -Simple, implicit markup is used to indicate special constructs, such as -section headings, bullet lists, and emphasis. The markup used is as minimal -and unobtrusive as possible. Less often-used constructs and extensions to -the basic reStructuredText syntax may have more elaborate or explicit -markup. - -The first section gives a quick overview of the syntax of the -reStructuredText markup by example. More details are given in the `Syntax -Details`_ section. - -`Literal blocks`_ are used for examples throughout this document. - ------------------------ - Quick Syntax Overview ------------------------ - -A reStructuredText document is made up of body elements, and may be -structured into sections. `Section Structure`_ is indicated through title -style (underlines & optional overlines). Sections contain body elements -and/or subsections. - -Here are examples of body elements: - -- Paragraphs_ (and `inline markup`_):: - - Paragraphs contain text and may contain inline markup: *emphasis*, - **strong emphasis**, `interpreted text`, ``inline literals``, - standalone hyperlinks (http://www.python.org), indirect hyperlinks - (Python_), internal cross-references (example_), footnote references - ([1]_). - - Paragraphs are separated by blank lines and are flush left. - -- Three types of lists: - - 1. `Bullet lists`_:: - - - This is a bullet list. - - - Bullets can be '-', '*', or '+'. - - 2. `Enumerated lists`_:: - - 1. This is an enumerated list. - - 2. Enumerators may be arabic numbers, letters, or roman numerals. - - 3. `Definition lists`_:: - - what - Definition lists associate a term with a definition. - - how - The term is a one-line phrase, and the definition is one or - more paragraphs or body elements, indented relative to the - term. - -- `Literal blocks`_:: - - Literal blocks are indented, and indicated with a double-colon ('::') - at the end of the preceeding paragraph:: - - if literal_block: - text = 'is left as-is' - spaces_and_linebreaks = 'are preserved' - markup_processing = None - -- `Block quotes`_:: - - Block quotes consist of indented body elements: - - This theory, that is mine, is mine. - - Anne Elk (Miss) - -- Tables_:: - - +------------------------+------------+----------+ - | Header row, column 1 | Header 2 | Header 3 | - +========================+============+==========+ - | body row 1, column 1 | column 2 | column 3 | - +------------------------+------------+----------+ - | body row 2 | Cells may span | - +------------------------+------------+----------+ - -- Comments_:: - - .. Comments begin with two dots and a space. Anything may follow, - except for the syntax of directives, footnotes, and hyperlink - targets, described below. - -- Directives_:: - - .. graphic:: mylogo.png - -- Footnotes_:: - - .. _[1] A footnote contains indented body elements. - - It is a form of hyperlink target. - -- `Hyperlink targets`_:: - - .. _Python: http://www.python.org - - .. _example: - - The '_example' target above points to this paragraph. - -.. _syntax details: - ----------------- - Syntax Details ----------------- - -Below is a diagram of the hierarchy of element types in reStructuredText. -Elements may contain other elements below them. Element types in -parentheses indicate recursive or one-to-many relationships: sections may -contain (sub)sections, tables contain further body elements, etc. :: - - +------------------------------------------------------------------+ - | document | - | +--------------------------------------+ - | [root element] | +-------+ | - | | sections [begin with one | title |] | - | | +-------+ | - |---------------------------+-------------------------+------------| - | [body elements:] | (sections) | - | | | - lists | | - comments +------------+ - | | | - tables | | - directives | - | para- | literal | - block | foot- | - hyperlink | - | graphs | blocks | quotes | notes | targets | - +---------+---------+----------+-------+--------------+ - | [text]+ | [text] | (body elements) | [text] | - | (inline +---------+------------------+--------------+ - | markup) | - +---------+ - -For definitive element hierarchy details, see the "Generic Plaintext -Document Interface DTD" XML document type definition, gpdi.dtd_. -Descriptions below list 'DTD elements' (XML 'generic identifiers') -corresponding to syntax constructs. - -.. _whitespace: - -Whitespace -========== -Blank lines are used to separate paragraphs and other elements. Blank lines -may be omitted when the markup makes element separation unambiguous. - -Indentation is used to indicate, and is only significant in indicating: - -- multiple body elements within a list item (including nested lists), -- the definition part of a definition list item, -- block quotes, and -- the extent of literal blocks. - -Although spaces are recommended for indentation, tabs may also be used. -Tabs will be converted to spaces. Tab stops are at every 8th column. - -.. _escaping mechanism: - -Escaping Mechanism -================== -The character set available in plain text documents, 7-bit ASCII, is -limited. No matter what characters are used for markup, they will already -have multiple meanings in written text. Therefore markup characters *will* -sometimes appear in text **without being intended as markup**. - -Any serious markup system requires an escaping mechanism to override the -default meaning of the characters used for the markup. In reStructuredText -we use the backslash, commonly used as an escaping character in other -domains. - -A backslash followed by any character escapes the character. The escaped -character represents the character itself, and is prevented from playing a -role in any markup interpretation. The backslash is removed from the -output. A literal backslash is represented by two backslashes in a row. - -There are two contexts in which backslashes have no special meaning: -literal blocks and inline literals. In these contexts, a single backslash -represents a literal backslash. - -.. _section structure: - -Section Structure -================= -DTD elements: section, title. - -Sections are identified through their titles, which are marked up with -'underlines' below the title text (and, in some cases, 'overlines' above -the title). An underline/overline is a line of non-alphanumeric characters -that begins in column 1 and extends at least as far as the right edge of -the title text. When there an overline is used, the length and character -used must match the underline. There may be any number of levels of section -titles. - -Rather than imposing a fixed number and order of section title styles, the -order enforced will be the order as encountered. The first style -encountered will be an outermost title (like HTML H1), the second style -will be a subtitle, the third will be a subsubtitle, and so on. - -Below are examples of section title styles:: - - =============== - Section Title - =============== - - --------------- - Section Title - --------------- - - Section Title - ============= - - Section Title - ------------- - - Section Title - ............. - - Section Title - ~~~~~~~~~~~~~ - - Section Title - ************* - - Section Title - +++++++++++++ - - Section Title - ^^^^^^^^^^^^^ - -When a title has both an underline and an overline, the title text may be -inset, as in the first two examples above. This is merely aesthetic and not -significant. Underline-only title text may not be inset. - -A blank line after a title is optional. All text blocks up to the next -title of the same or higher level are included in a section (or subsection, -etc.). - -All section title styles need not be used, nor must any specific section -title style be used. However, a document must be consistent in its use of -section titles: once a hierarchy of title styles is established, sections -must use that hierarchy. - -.. _body elements: - -Body Elements -============= - -.. _paragraphs: - -Paragraphs ----------- -DTD element: paragraph. - -Paragraphs consist of blocks of left-aligned text with no markup indicating -any other body element. Blank lines separate paragraphs from each other and -from other body elements. Paragraphs may contain `inline markup`_. - -Syntax diagram:: - - +------------------------------+ - | paragraph | - | | - +------------------------------+ - +------------------------------+ - | paragraph | - | | - +------------------------------+ - -.. _bullet lists: - -Bullet Lists ------------- -DTD elements: bullet_list, list_item. - -A text block which begins with a '-', '*', or '+', followed by whitespace, -is a bullet list item (a.k.a. 'unordered' list item). For example:: - - - This is the first bullet list item. The blank line above the first - list item is required; blank lines between list items (such as below - this paragraph) are optional. Text blocks must be left-aligned, - indented relative to the bullet. - - - This is the first paragraph in the second item in the list. - - This is the second paragraph in the second item in the list. The - blank line above this paragraph is required. The left edge of this - paragraph lines up with the paragraph above, both indented relative - to the bullet. - - - This is a sublist. The bullet lines up with the left edge of the - text blocks above. A sublist is a new list so requires a blank line - above and below. - - - This is the third item of the main list. - - This paragraph is not part of the list. - -Here are examples of **incorrectly** formatted bullet lists:: - - - This first line is fine. - A blank line is required between list items and paragraphs. (Warning) - - - The following line appears to be a new sublist, but it is not: - - This is a paragraph contination, not a sublist (no blank line). - - Warnings may be issued by the implementation. - -Syntax diagram:: - - +------+-----------------------+ - | '- ' | list item | - +------| (body elements)+ | - +-----------------------+ - -.. _enumerated lists: - -Enumerated Lists ----------------- -DTD elements: enumerated_list, list_item. - -Enumerated lists (a.k.a. 'ordered' lists) are similar to bullet lists, but -use enumerators instead of bullets. An enumerator consists of an -enumeration sequence member and formatting, followed by whitespace. The -following enumeration sequences are recognized: - -- arabic numerals: 1, 2, 3, ... (no upper limit). -- uppercase alphabet characters: A, B, C, ..., Z. -- lower-case alphabet characters: a, b, c, ..., z. -- uppercase Roman numerals: I, II, III, IV, ... (no upper limit). -- lowercase Roman numerals: i, ii, iii, iv, ... (no upper limit). - -The following formatting types are recognized: - -- suffixed with a period: '1.', 'A.', 'a.', 'I.', 'i.'. -- surrounded by parentheses: '(1)', '(A)', '(a)', '(I)', '(i)'. -- suffixed with a right-parenthesis: '1)', 'A)', 'a)', 'I)', 'i)'. - -For an enumerated list to be recognized, the following must hold true: - -1. The list must consist of multiple adjacent list items (2 or more). -2. The enumerators must all have the same format and sequence type. -3. The enumerators must be in sequence (i.e., '1.', '3.' is not allowed). - -It is recommended that the enumerator of the first list item be ordinal-1 -('1', 'A', 'a', 'I', or 'i'). Although other start-values will be -recognized, they may not be supported by the output format. - -Nested enumerated lists must be created with indentation. For example:: - - 1. Item 1. - - a) item 1a. - b) Item 1b. - -.. _definition lists: - -Definition Lists ------------------ -DTD elements: definition_list, definition_list_item, term, definition. - -Each definition list item contains a term and a definition. A term is a -simple one-line paragraph. A definition is a block indented relative to the -term, and may contain multiple paragraphs and other body elements. Blank -lines are required before the term and after the definition, but there may -be no blank line between a term and a definition (this distinguishes -definition lists from `block quotes`_). :: - - term 1 - Definition 1. - - term 2 - Definition 2, paragraph 1. - - Definition 2, paragraph 2. - -Syntax diagram:: - - +------+ - | term | - +--+---+-----------------------+ - | defninition | - | (body elements)+ | - +---------------------------+ - -.. _field lists: - -Field Lists ------------ -DTD elements: field_list, field, field_name, field_argument, field_body. - -.. XXX Syntax under construction. Comments and suggestions welcome. - -Field lists are mappings from field names to field bodies, modeled on -RFC822_ headers. A field name is made up of one or more letters, numbers, -and punctuation, except colons (':') and whitespace. A single colon and -whitespace follows the field name, and this is followed by the field body. -The field body may contain multiple body elements. - -Applications of reStructuredText may recognize field names and transform -fields or field bodies in certain contexts. Field names are -case-insensitive. Any untransformed fields remain in the field list as the -document's first body element. - -The syntax for field lists has not been finalized. Syntax alternatives: - -1. Unadorned RFC822_ everywhere:: - - Author: Me - Version: 1 - - Advantages: clean, precedent. Disadvantage: ambiguous (these paragraphs - are a prime example). - - Conclusion: rejected. - -2. Special case: use unadorned RFC822_ for the very first or very last text - block of a docstring:: - - """ - Author: Me - Version: 1 - - The rest of the docstring... - """ - - Advantages: clean, precedent. Disadvantages: special case, flat - (unnested) field lists only. - - Conclusion: accepted, see below. - -3. Use a directive:: - - .. fields:: - - Author: Me - Version: 1 - - Advantages: explicit and unambiguous. Disadvantage: cumbersome. - -4. Use Javadoc-style:: - - @Author: Me - @Version: 1 - @param a: integer - - Advantages: unambiguous, precedent, flexible. Disadvantages: - non-intuitive, ugly. - -One special context is defined for field lists. A field list as the very -first non-comment block, or the second non-comment block immediately after -a title, is interpreted as document bibliographic data. No special syntax -is required, just unadorned RFC822_. The first block ends with a blank -line, therefore field bodies must be single paragraphs only and there may -be no blank lines between fields. The following field names are recognized -and transformed to the corresponding DTD elements listed, child elements of -the 'document' element. No ordering is imposed on these fields: - -- Title: title -- Subtitle: subtitle -- Author/Authors: author -- Organization: organization -- Contact: contact -- Version: version -- Status: status -- Date: date -- Copyright: copyright - -This field-name-to-element mapping can be extended, or replaced for other -languages. See the implementation documentation for details. - -.. _literal blocks: - -Literal Blocks --------------- -DTD element: literal_block. - -Two colons ('::') at the end of a paragraph signifies that all following -**indented** text blocks comprise a literal block. No markup processing is -done within a literal block. It is left as-is, and is typically rendered in -a monospaced typeface:: - - This is a typical paragraph. A literal block follows:: - - for a in [5,4,3,2,1]: # this is program code, formatted as-is - print a - print "it's..." - # a literal block continues until the indentation ends - - This text has returned to the indentation of the first paragraph, is - outside of the literal block, and therefore treated as an ordinary - paragraph. - -When '::' is immediately preceeded by whitespace, both colons will be -removed from the output. When text immediately preceeds the '::', *one* -colon will be removed from the output, leaving only one (i.e., '::' will be -replaced by ':'). When '::' is alone on a line, it will be completely -removed from the output; no empty paragraph will remain. - -In other words, these are all equivalent: - -1. Minimized:: - - Paragraph:: - - Literal block - -2. Partly expanded:: - - Paragraph: :: - - Literal block - -3. Fully expanded:: - - Paragraph: - - :: - - Literal block - -The minimum leading whitespace will be removed from each line of the -literal block. Other than that, all whitespace (including line breaks) is -preserved. Blank lines are required before and after a literal block, but -these blank lines are not included as part of the literal block. - -Syntax diagram:: - - +------------------------------+ - | paragraph | - | (ends with '::') | - +------------------------------+ - +---------------------------+ - | literal block | - +---------------------------+ - -.. _block quotes: - -Block Quotes ------------- -DTD element: block_quote. - -A text block that is indented relative to the preceeding text, without -markup indicating it to be a literal block, is a block quote. All markup -processing (for body elements and inline markup) continues within the block -quote:: - - This is an ordinary paragraph, introducing a block quote: - - "It is my business to know things. That is my trade." - - --Sherlock Holmes - -Blank lines are required before and after a block quote, but these blank -lines are not included as part of the block quote. - -Syntax diagram:: - - +------------------------------+ - | (current level of | - | indentation) | - +------------------------------+ - +---------------------------+ - | block quote | - | (body elements)+ | - +---------------------------+ - -.. _tables: - -Tables ------- -DTD elements: table, tgroup, colspec, thead, tbody, row, entry. - -Tables are described with a visual outline made up of the characters '-', -'=', '|', and '+'. The hyphen ('-') is used for horizontal lines (row -separators). The equals sign ('=') may be used to separate optional header -rows from the table body. The vertical bar ('|') is used for vertical lines -(column separators). The plus sign ('+') is used for intersections of -horizontal and vertical lines. - -Each cell contains zero or more body elements. Example:: - - +------------------------+------------+----------+----------+ - | Header row, column 1 | Header 2 | Header 3 | Header 4 | - | (header rows optional) | | | | - +========================+============+==========+==========+ - | body row 1, column 1 | column 2 | column 3 | column 4 | - +------------------------+------------+----------+----------+ - | body row 2 | Cells may span columns. | - +------------------------+------------+---------------------+ - | body row 3 | Cells may | - Table cells | - +------------------------+ span rows. | - contain | - | body row 4 | | - body elements. | - +------------------------+------------+---------------------+ - -As with other body elements, blank lines are required before and after -tables. Tables' left edges should align with the left edge of preceeding -text blocks; otherwise, the table is considered to be part of a block -quote. - -Comment Blocks --------------- -A comment block is a text block: - -- whose first line begins with '.. ' (the 'comment start'), -- whose second and subsequent lines are indented relative to the first, and -- which ends with an unindented line. - -Comments are analogous to bullet lists, with '..' as the bullet. Blank -lines are required between comment blocks and other elements, but are -optional between comment blocks where unambiguous. - -The comment block syntax is used for comments, directives, footnotes, and -hyperlink targets. - -.. _comments: - -Comments -........ -DTD element: comment. - -Arbitrary text may follow the comment start and will be processed as a -comment element, possibly being removed from the processed output. The only -restriction on comments is that they not use the same syntax as directives, -footnotes, or hyperlink targets. - -Syntax diagram:: - - +-------+----------------------+ - | '.. ' | comment block | - +--+----+ | - | | - +---------------------------+ - -.. _directives: - -Directives -.......... -DTD element: directive. - -Directives are indicated by a comment start followed by a single word (the -directive type, regular expression '`[a-zA-Z][a-zA-Z0-9_-]*`'), two colons, -and whitespace. Two colons are used for these reasons: - -- To avoid clashes with common comment text like:: - - .. Danger: modify at your own risk! - -- If an implementation of reStructuredText does not recognize a directive - (i.e., the directive-handler is not installed), the entire directive - block (including the directive itself) will be treated as a literal - block, and a warning generated. Thus '::' is a natural choice. - -Directive names are case-insensitive. Actions taken in response to -directives and the interpretation of data in the directive block or -subsequent text block(s) are directive-dependent. - -No directives have been defined by the core reStructuredText specification. -The following are only examples of *possible uses* of directives. - -Directives can be used as an extension mechanism for reStructuredText. For -example, here's how a graphic could be placed:: - - .. graphic:: mylogo.png - -A figure (a graphic with a caption) could be placed like this:: - - .. figure:: larch.png - - The larch. - -Directives can also be used as pragmas, to modify the behavior of the -parser, such as to experiment with alternate syntax. - -Syntax diagram:: - - +-----------------+------------+ - | '.. ' type '::' | directive | - +--+--------------+ block | - | | - +---------------------------+ - -.. _hyperlink targets: - -Hyperlink Targets -................. -DTD element: target. - -Hyperlink targets consist of a comment start ('.. '), an underscore, the -hyperlink name (no trailing underscore), a colon, whitespace, and a link -block. Hyperlink targets go together with `indirect hyperlinks`_ and -`internal hyperlinks`_. Internal hyperlink targets have empty link blocks; -they point to the next element. Indirect hyperlink targerts have an -absolute or relative URI in their link blocks. - -If a hyperlink name contains colons, either: - -- the phrase must be enclosed in backquotes:: - - .. _`FAQTS: Computers: Programming: Languages: Python`: - http://python.faqts.com/ - -- or the colon(s) must be backslash-escaped in the link target:: - - .. _Chapter One\: 'Tadpole Days': - - It's not easy being green... - -Whitespace is normalized within hyperlink names, which are -case-insensitive. - -Syntax diagram:: - - +-----------------+------------+ - | '.. _' name ':' | link | - +--+--------------+ block | - | | - +---------------------------+ - -.. _footnotes: - -Footnotes -......... -DTD elements: footnote, label. - -Footnotes are similar to hyperlink targets: a comment start, an underscore, -open square bracket, footnote label, close square bracket, and whitespace. -To differentiate footnotes from hyperlink targets: - -- the square brackets are used, -- the footnote label may not contain whitespace, -- no colon appears after the close bracket. - -Footnotes may occur anywhere in the document, not necessarily at the end. -Where or how they appear in the processed output depends on the output -formatter. Here is a footnote, referred to in `Footnote References`_:: - - .. _[GVR2001] Python Documentation, van Rossum, Drake, et al., - http://www.python.org/doc/ - -Syntax diagram:: - - +-------------------+----------+ - | '.. _[' label ']' | footnote | - +--+----------------+ | - | (body elements)+ | - +---------------------------+ - -.. _inline markup: - -Inline Markup -============= -Inline markup is the markup of text within a text block. Inline markup -cannot be nested. - -There are six inline markup constructs. Four of the constructs (emphasis_, -`strong emphasis`_, `interpreted text`_, and `inline literals`_) use -start-strings and end-strings to indicate the markup. The -`indirect hyperlinks`_ construct -(shared by `internal hyperlinks`_) uses an end-string -only. `Standalone hyperlinks`_ are interpreted implicitly, and use no extra -markup. - -The inline markup start-string and end-string recognition rules are as -follows: - -1. Inline markup start-strings must be immediately preceeded by whitespace - and zero or more of single or double quotes, '(', '[', or '{'. - -2. Inline markup start-strings must be immediately followed by - non-whitespace. - -3. Inline markup end-strings must be immediately preceeded by - non-whitespace. - -4. Inline markup end-strings must be immediately followed by zero or more - of single or double quotes, '.', ',', ':', ';', '!', '?', '-', ')', ']', - or '}', followed by whitespace. - -5. If an inline markup start-string is immediately preceeded by a single or - double quote, '(', '[', or '{', it must not be immediately followed by - the corresponding single or double quote, ')', ']', or '}'. - -6. An inline markup end-string must be separated by at least one character - from the start-string. - -7. Except for the end-string of `inline literals`_, an unescaped backslash - preceeding a start-string or end-string will disable markup recognition. - See `escaping mechanism`_ above for details. - -For example, none of the following are recognized as inline markup -start-strings: ' * ', '"*"', "'*'", '(*)', '(* ', '[*]', '{*}', '\*', ' ` -', etc. - -.. _emphasis: - -Emphasis --------- -DTD element: emphasis. - -Text enclosed by single asterisk characters (start-string = end-string = -'*') is emphasized:: - - This is *emphasized text*. - -Emphasized text is typically displayed in italics. - -.. _strong emphasis: - -Strong Emphasis ---------------- -DTD element: strong. - -Text enclosed by double-asterisks (start-string = end-string = '**') is -emphasized strongly:: - - This is **strong text**. - -Strongly emphasized text is typically displayed in boldface. - -.. _interpreted text: - -Interpreted Text ----------------- -DTD element: interpreted. - -Text enclosed by single backquote characters (start-string = end-string = -'`') is interpreted:: - - This is `interpreted text`. - -The semantics of interpreted text are domain-dependent. It can be used as -implicit or explicit descriptive markup (such as for program identifiers, -as in the `Python Extensions`_ to reStructuredText), for cross-reference -interpretation (such as index entries), or for other applications where -context can be inferred. The role of the interpreted text may be inferred -implicitly. The role of the interpreted text may also be indicated -explicitly, either a prefix (role + colon + space) or a suffix (space + -colon + role), depending on which reads better:: - - `role: interpreted text` - - `interpreted text :role` - -.. _inline literals: - -Inline Literals ---------------- -DTD element: literal. - -Text enclosed by double-backquotes (start-string = end-string = '``') is -treated as inline literals:: - - This text is an example of ``inline literals``. - -Inline literals may contain any characters except two adjacent backquotes -in an end-string context (according to the recognition rules above). No -markup interpretation (including backslash-escape interpretation) is done -within inline literals. Line breaks are *not* preserved; other whitespace -is not guaranteed to be preserved. - -Inline literals are useful for short code snippets. For example:: - - The regular expression ``[+-]?(\d+(\.\d*)?|\.\d+)`` matches - non-exponential floating-point numbers. - -.. _hyperlinks: - -Hyperlinks ----------- -Hyperlinks are indicated by a trailing underscore, '_', except for -`standalone hyperlinks`_ which are recognized independently. - -.. _standalone hyperlinks: - -Standalone Hyperlinks -..................... -DTD element: link. - -An absolute URI_ within a text block is treated as a general external -hyperlink with the URI itself as the link's text (start-string = end-string -= '', the empty string). For example:: - - See http://www.python.org for info. - -would be marked up in HTML as:: - - See http://www.python.org for info. - -.. _URI: - -Uniform Resource Identifier: - URIs are a general form of URLs (Uniform Resource Locators). - For the syntax of URIs see RFC2396_. - -.. _indirect hyperlinks: - -Indirect Hyperlinks -................... - -DTD element: link. - -Indirect hyperlinks consist of two parts. In the text body, there is a -source link, a name with a trailing underscore (start-string = '', -end-string = '_'; start-string = '\`', end-string = '\`_'):: - - See the Python_ home page for info. - -Somewhere else in the document is a target link containing a URI (see -`Hyperlink Targets`_ for a full description):: - - .. _Python: http://www.python.org - -After processing into HTML, this should be expressed as:: - - See the Python home page for info. - --------------------- - -See the Python_ home page for info. - -.. _Python: http://www.python.org - --------------------- - -Phrase-links (a hyperlink whose name is a phrase, two or more -space-separated words) can be expressed by enclosing the phrase in -backquotes and treating the backquoted text as a link name:: - - Want to learn about `my favorite programming language`_? - - .. _my favorite programming language: http://www.python.org - --------------------- - -Want to learn about `my favorite programming language`_? - -.. _my favorite programming language: http://www.python.org - --------------------- - -Whitespace is normalized within hyperlink names, which are -case-insensitive. - -.. _internal hyperlinks: - -Internal Hyperlinks -................... -DTD element: link. - -Internal hyperlinks connect one point to another within a document. They -are identical to indirect hyperlinks (start-string = '', end-string = '_'; -start-string = '\`', end-string = '\`_') except that there is no URI in the -target link. See `Hyperlink Targets`_ for a full description. For example:: - - Clicking on this internal hyperlink will take us to the target_ below. - - .. _target: - - The hyperlink target above points to this paragraph. - --------------------- - -Clicking on this internal hyperlink will take us to the target_ below. - -.. _target: - -The hyperlink target above points to this paragraph. - --------------------- - -.. _footnote references: - -Footnote References -................... -DTD element: footnote_reference. - -Footnote references consist of a square-bracketed label (no whitespace), -with a trailing underscore (start-string = '[', end-string = ']_'):: - - Please refer to the fine manual [GVR2001]_. - -See Footnotes_ for the footnote itself. - -.. _reStructuredText: http://structuredtext.sf.net -.. _Python Docstring Processing System: http://docstring.sf.net -.. _Doc-SIG: http://www.python.org/sigs/doc-sig/ -.. _gpdi.dtd: http://docstring.sf.net/spec/gpdi.dtd -.. _RFC822: http://www.rfc-editor.org/rfc/rfc822.txt -.. _RFC2396: http://www.rfc-editor.org/rfc/rfc2396.txt -.. _Python Extensions: http://structuredtext.sf.net/spec/pyextensions.txt - diff --git a/_sphinx/source/nexuslogo.png b/_sphinx/source/nexuslogo.png deleted file mode 100755 index bd748b375..000000000 Binary files a/_sphinx/source/nexuslogo.png and /dev/null differ diff --git a/_sphinx/source/preface.rst b/_sphinx/source/preface.rst deleted file mode 100755 index 0f3452aba..000000000 --- a/_sphinx/source/preface.rst +++ /dev/null @@ -1,136 +0,0 @@ -.. $Id$ - -.. _preface: - -Preface -================================================= - -With this edition of the manual, NeXus introduces a complete version -of the documentation of the NeXus standard. The content from the wiki -has been converted, augmented (in some parts significantly), clarified, -and indexed. The NeXus Definition Language (NXDL) is introduced now -to define base classes and application definitions. -NXDL replaces the previous method (meta-DTD) to define NeXus classes. -NeXus base classes and instrument definitions -are now assigned to one of three classifications: - -#. *base classes* (that represent the components used - to build a NeXus data file), -#. *application definitions* (that define a minimum - set of data for a specific purpose such as scientific data processing - or an instrument definition), - and -#. *contributed definitions* (definitions and specifications - that are in an incubation status before ratification by the NIAC). - -Additional examples have been added to respond to -inquiry from the users of the NeXus standard about implementation -and usage. Hopefully, the improved documentation with -more examples and the new NXDL will reduce -the learning barriers incurred by those new to NeXus. - - -Representation of data examples -------------------------------------------------- - -.. index:: - single: data; examples - -Most of the examples of data files have been written in a format -intended to show the structure of the file rather than the data content. -In some cases, where it is useful, some of the data is shown. -Consider this prototype example: - -.. code-block:: text - :linenos: - - entry:NXentry - instrument:NXinstrument - detector:NXdetector - data:[] - @axes = "bins" - @long_name = "strip detector 1-D array" - @signal = 1 - bins:[0, 1, 2, ... 1023] - @long_name = "bin index numbers" - sample:NXsample - name = "zeolite" - data:NXdata - data --> /entry/instrument/detector/data - bins --> /entry/instrument/detector/bins - -Some words on the notation: - -* Hierarchy is represented by indentation. - Objects on the same indentation level are in the same group -* The combination ``name:NXclass`` denotes a NeXus group with - name ``name`` and class ``NXclass``. -* A simple name (no following class) denotes a data field. - An equal sign is used to show the value, where this is - important to the example. -* Sometimes, a data type is specified and possibly a set of - dimensions. For example, ``energy:NX_NUMBER[NE]`` says ``energy`` - is a 1-D array of numbers (either integer or floating point) - of length ``NE``. -* Attributes are noted as ``@name=value`` pairs separated by comma. - The ``@`` symbol only indicates this is an attribute. The ``@`` - symbol is not part of the attribute name. -* Links are shown with a text arrow ``-->`` indicating the source - of the link (using HDF5 notation listing the sequence of names). - -[Line 1] - shows that there is one group at the root level of the file named - ``entry``. This group is of type ``NXentry`` - which means it conforms to the specification of the ``NXentry`` - NeXus base class. Using the HDF5 nomenclature, we would refer to this - as the ``/entry`` group. - -[Lines 2, 10, and 12] - The ``/entry`` group contains three subgroups: - ``instrument``, ``sample``, and ``data``. - These groups are of type ``NXinstrument``, ``NXsample``, - and ``NXdata``, respectively. - -[Line 4] - The data of this example is stored in the - ``/entry/instrument/detector`` group in the dataset called - ``data`` (HDF5 path is ``/entry/instrument/detector/data``). - The indication of ``data:[]`` says that ``data`` is an - array of unspecified dimension(s). - -[Lines 5-7] - There are three attributes of ``/entry/instrument/detector/data``: - ``axes``, ``long_name``, and ``signal``. - -[Line 8] (reading ``bins:[0, 1, 2, ... 1023]``) - shows that - ``bins`` is a 1-D array of length presumably 1024. A small, - representative selection of values are shown. - -[Line 9] - an attribute that shows a descriptive name of - ``/entry/instrument/detector/bins``. This attribute - might be used by a NeXus client while plotting the data. - -[Line 11] (reading ``name = "zeolite"``) - shows how a string value is represented. - -[Lines 13-14] - The ``/entry/data`` group has two datasets that are actually - linked as shown. (As you will see later, the ``NXdata`` group - is required and enables NeXus clients to easily determine what to - offer for display on a default plot.) - - -Class path specification -------------------------------------------------- - -In some places in this documentation, a path may be shown -using the class types rather than names. For example: -``/NXentry/NXinstrument/NXcrystal/wavelength`` -identifies a dataset called ``wavelength`` -that is inside a group of type ``NXcrystal`` inside a group -of type ``NXinstrument`` inside a group of type ``NSentry``. -This nomenclature is used when the exact name of each group is -either unimportant or not specified. Often, this will be used in -a NXDL specification to indicate the connections of a link. diff --git a/_sphinx/source/revhistory.rst b/_sphinx/source/revhistory.rst deleted file mode 100755 index 92050c8cf..000000000 --- a/_sphinx/source/revhistory.rst +++ /dev/null @@ -1,39 +0,0 @@ -.. $Id$ - -.. _revhistory: - -Revision History -================================================= - - -============= =========== ===================================================================== ========== -NUMBER DATE DESCRIPTION NAME -============= =========== ===================================================================== ========== -3.2a 2012-05 Changing documentation source from DocBook to Sphinx PRJ -3.1.0 2012-05 Ready for release. PRJ -3.1 2012-02 Now using ``cmake`` to control multiplatform build PRJ - and packaging. -1.0b 2011-11 Preparing manual for initial release. Also PRJ - preparing to convert manual source from - DocBook to Sphinx for next release of manual. -draft 2010-11 Nearly complete but still much finishing work PRJ - remains. The description of dimensions and the - description of the coordinate system needs major - revision and improvement. More examples are - needed. The manual is now divided into two - volumes. Volume I is the User Manual, Volume II - is the Reference Documentation. Much of the - NXDL chapter in Volume II is autogenerated from - the ``nxdl.xsd`` Schema and the NXDL source - files. - - Initial release of NXDL, manual, and next release - of NAPI (compatibility release), - manual in editing stage, packaging tools need to be built. -initial draft 2010 spring Most of the content from the old NeXus PRJ - mediawiki documentation is included. Some new - wiki content has been introduced but should be - easy to identify for inclusion in the manual. -.. 2009-11 Started conversion from the old NeXus mediawiki PFP - documentation. -============= =========== ===================================================================== ========== diff --git a/_sphinx/source/volume1/design/data-linking.png b/_sphinx/source/volume1/design/data-linking.png deleted file mode 100755 index 37219acc2..000000000 Binary files a/_sphinx/source/volume1/design/data-linking.png and /dev/null differ diff --git a/_sphinx/source/volume1/design/datarules.rst b/_sphinx/source/volume1/design/datarules.rst deleted file mode 100755 index 66fe038de..000000000 --- a/_sphinx/source/volume1/design/datarules.rst +++ /dev/null @@ -1,587 +0,0 @@ -.. $Id$ - -.. _DataRules: - -Rules for Storing Data Items in NeXus Files -=========================================== - -This section describes the rules which apply for -storing single data fields in data files. - - - -.. _Design-Naming: - -Naming Conventions ------------------- - -Group and field names used within NeXus follow a naming -convention which adheres to these rules. :index:`rules; naming` -The names of NeXus `group `_ and `field `_ -objects must contain only a restricted set of characters. -This set may be described by this regular expression syntax. - -.. _RegExpName: - -:: - - [A-Za-z_][\w_]* - -This name pattern starts with a letter (upper or lower case) -or "`_`" (underscore), then letters, -numbers, and "`_`" and is limited to no more than 63 characters -(imposed by the HDF5 rules for names). - -.. index:: rules; HDF5 - -Sometimes it is necessary to combine words in order to -build a descriptive name for a data field or a group. -In such cases lowercase words are connected by underscores. :: - - number_of_lenses - -For all data fields, only names from the NeXus base class dictionaries are to -be used. -If a data field name or even a complete component is missing, -please suggest the addition to the NIAC. The addition will usually be -accepted provided it is adequately documented -and not a duplication of an existing field. - -.. note: - The NeXus base classes provide a comprehensive dictionary - of terms than can be used for each class. - :index:`NeXus basic motivation; defined dictionary` - - - -.. _Design-NeXusDimensions: - -NeXus Storage -------------- - -NeXus stores multi dimensional arrays of physical values -in C language storage order, :index:`dimension; storage order` -last dimension is the fastest varying. This is the rule. - - **Good reasons are required to deviate from this rule.** - -One good reason to deviate from this rule is the situation -where data must be streamed to disk as fast as possible and -a conversion to NeXus storage order is not possible. -In such cases, exceptions can be made. It is possible -to store data in other storage orders in NeXus -as well as to specify that the data needs to be converted first -before being useful. - -.. ... store data in other storage orders in NeXus ... - - - - -.. _Design-NonCStorageOrder: - -Non C Storage Order -................... - -In order to indicate that the storage order :index:`dimension; storage order` -is different from C storage order two -additional data set attributes, offset and stride, -have to be stored which together define the storage -layout of the data. Offset and stride contain rank -numbers according to the rank of the multidimensional -data set. Offset describes the step to make when the -dimension is multiplied by 1. Stride defines the step to -make when incrementing the dimension. -This is best explained by some examples. - - -Offset and Stride for 1-D data -++++++++++++++++++++++++++++++ - -* raw data = 0 1 2 3 4 5 6 7 8 9 - -.. code-block:: text - - size[1] = { 10 } // assume uniform overall array dimensions - -* default stride - -.. code-block:: text - :linenos: - - stride[1] = { 1 } - offset[1] = { 0 } - for i: - result[i]: - 0 1 2 3 4 5 6 7 8 9 - -* reverse stride - -.. code-block:: text - :linenos: - - stride[1] = { -1 } - offset[1] = { 9 } - for i: - result[i]: - 9 8 7 6 5 4 3 2 1 0 - - -Offset and Stride for 2-D data -++++++++++++++++++++++++++++++ - -* raw data = 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 - -.. code-block:: text - - size[2] = { 4, 5 } // assume uniform overall array dimensions - -* row major (C) stride - -.. code-block:: text - :linenos: - - stride[2] = { 5, 1 } - offset[2] = { 0, 0 } - for i: - for j: - result[i][j]: - 0 1 2 3 4 - 5 6 7 8 9 - 10 11 12 13 14 - 15 16 17 18 19 - -* column major (Fortran) stride - -.. code-block:: text - :linenos: - - stride[2] = { 1, 4 } - offset[2] = { 0, 0 } - for i: - for j: - result[i][j]: - 0 4 8 12 16 - 1 5 9 13 17 - 2 6 10 14 18 - 3 7 11 15 19 - -* "crazy reverse" row major (C) stride - -.. code-block:: text - :linenos: - - stride[2] = { -5, -1 } - offset[2] = { 4, 5 } - for i: - for j: - result[i][j]: - 19 18 17 16 15 - 14 13 12 11 10 - 9 8 7 6 5 - 4 3 2 1 0 - - -Offset and Stride for 3-D data -++++++++++++++++++++++++++++++ - -* raw data = 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 - 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 - 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 - -.. code-block:: text - - size[3] = { 3, 4, 5 } // assume uniform overall array dimensions - -* row major (C) stride - -.. code-block:: text - :linenos: - - stride[3] = { 20, 5, 1 } - offset[3] = { 0, 0, 0 } - for i: - for j: - for k: - result[i][j][k]: - 0 1 2 3 4 - 5 6 7 8 9 - 10 11 12 13 14 - 15 16 17 18 19 - - 20 21 22 23 24 - 25 26 27 28 29 - 30 31 32 33 34 - 35 36 37 38 39 - - 40 41 42 43 44 - 45 46 47 48 49 - 50 51 52 53 54 - 55 56 57 58 59 - -* column major (Fortran) stride - -.. code-block:: text - :linenos: - - stride[3] = { 1, 3, 12 } - offset[3] = { 0, 0, 0 } - for i: - for j: - for k: - result[i][j][k]: - 0 12 24 36 48 - 3 15 27 39 51 - 6 18 30 42 54 - 9 21 33 45 57 - - 1 13 25 37 49 - 4 16 28 40 52 - 7 19 31 43 55 - 10 22 34 46 58 - - 2 14 26 38 50 - 5 17 29 41 53 - 8 20 32 44 56 - 11 23 35 47 59 - -.. 2011-10-15,PRJ: NXformula has not been ratified by the NIAC. - This entire part is premature. - - .. _Design-DataValueTransformations: - - Data Value Transformations - ++++++++++++++++++++++++++ - - .. TODO: Is it too early to include a section about Data Value Transformations and NXformula? - - It is possible to store raw values in NeXus data files. Such data has to be stored in - special `NXformula` [#]_ groups together with the data and information required to transform - it into physical values. - - .. [#] NeXus has not yet defined the `NXformula` group (or base class) for use in NeXus data files. - The exact content of the `NXformula` group is still under discussion. - - - -.. _Design-DataTypes: - -NeXus Data Types ----------------- - -Matching regular expressions for NeXus data types - -================ =================================== -description matching regular expression -================ =================================== -integer ``NX_INT(8|16|32|64)`` -floating-point ``NX_FLOAT(32|64)`` -array ``(\[0-9\])?`` -valid item name ``^[A-Za-z_][A-Za-z0-9_]*$`` -valid class name ``^NX[A-Za-z0-9_]*$`` -================ =================================== - -NeXus supports numeric data as either integer or floating-point -numbers. A number follows that indicates the number of bits in the word. -The table above shows the regular expressions that -matches the data type specifier. - -integers - ``NX_INT8``, ``NX_INT16``, ``NX_INT32``, or ``NX_INT64`` - -floating-point numbers - ``NX_FLOAT32`` or ``NX_FLOAT64`` - -date / time stamps - ``NX_DATE_TIME`` or ``ISO8601`` - - Dates and times :index:`date and time` are specified using - ISO-8601 standard definitions. - Refer to :ref:`Design-Dates-Times`. - -strings - All strings are to be encoded in UTF-8. Since most strings in a - NeXus file are restricted to a small set of characters and - the first 128 characters are standard across encodings, - the encoding of most of the strings in a NeXus file will be a moot point. - UTF-8 encoding will be important when recording - peoples' names in :ref:`NXuser` - and text notes in :ref:`NXnote`. - - .. index:: utility; nxvalidate - - Because the few places where encoding is important also - have unpredictable content, as well as the way in which - current operating systems handle character encoding, it - is practically impossible to test the encoding used. Hence, - `nxvalidate` provides no messages relating to character encoding. - -binary data - Binary data is to be written as ``UINT8``. - -images - Binary image data is to be written using ``UINT8``, - the same as binary data, but with an accompanying image mime-type. - If the data is text, the line terminator is ``[CR][LF]``. - - - -.. _Design-Dates-Times: - -NeXus dates and times ---------------------- - -.. index:: date and time - -NeXus dates and times should be stored using the -ISO 8601 [#ISO8601]_ format, such as: - -.. code-block:: text - - 1996-07-31T21:15:22+0600 - -**Note:** - The `T` appears literally in the string, - to indicate the beginning of the time element, as specified - in ISO 8601. It is common to use a space in place of the `T`. - While human-readable, compatibility with the ISO 8601 standard is not - assured with this substitution. - -The standard also allows for time intervals in fractional seconds -with *1 or more digits of precision*. -This avoids confusion, e.g. between U.S. and European conventions, -and is appropriate for machine sorting. - -.. [#ISO8601] ISO 8601, http://www.w3.org/TR/NOTE-datetime - -.. Uh, a leftover ... ... something above should be one level lower. - - - - -.. _Design-Units: - -NeXus Units ------------ - -.. index:: units - -Given the plethora of possible applications of NeXus, it is difficult to -define units -to use. Therefore, the general rule is that you are free to -store data in any unit you find fit. However, any data field must have a -units attribute which describes the units, Wherever possible, SI units are -preferred. NeXus units are written as a string attribute (``NX_CHAR``) -and describe the engineering units. The string -should be appropriate for the value. -Values for the NeXus units must be specified in -a format compatible with Unidata UDunits. [#UDunits]_ -The UDunits specification also includes instructions for derived units. -At present, the contents of NeXus `units` attributes -are not validated in data files. -Application definitions may specify units to be used for fields -using an `enumeration`. :index:`enumeration` - -.. [#UDunits] Unidata UDunits, http://www.unidata.ucar.edu/software/udunits/udunits-2-units.html - - -Linking Multi Dimensional Data with Axis Data ---------------------------------------------- - -NeXus allows to store multi dimensional arrays of data. -In most cases -it is not sufficient to just have the indices into the array as a label for -the dimensions of the data. Usually the information which physical value -corresponds to an index into a dimension :index:`dimension` -of the multi dimensional data set. -To this purpose a means is needed to locate appropriate data arrays which describe -what each dimension of a multi dimensional data set actually corresponds too. -There is a standard HDF facility to do this: it is called dimension scales. -Unfortunately, at a time, there was only one global namespace for dimension scales. -Thus NeXus had to come up with its own scheme for locating axis data which is described -here. A side effect of the NeXus scheme is that it is possible to have multiple -mappings of a given dimension to physical data. For example a TOF data set can have the TOF -dimension as raw TOF or as energy. - -There are two methods of linking :index:`link` -each data dimension to its respective dimension scale. -:index:`dimension; dimension scales` -The preferred method uses the ``axes`` attribute -to specify the names of each dimension scale. -The original method uses the ``axis`` attribute to identify -with an integer the axis whose value is the number of the dimension. -After describing each of these methods, the two methods will be compared. -A prerequisite for both methods is that the data fields describing the axis -are stored together with the multi dimensional data set whose axes need to be defined -in the same NeXus group. If this leads to data duplication, use links. - - - -.. _Design-Linking-ByName: - -Linking by name using the `axes` attribute -.......................................... - -The preferred method is to define an attribute of the data itself -called *axes*. :index:`axes` The ``axes`` attribute contains the names of -each dimension scale :index:`dimension; dimension scales` -as a colon (or comma) separated list in -the order they appear in C. For example: - -Preferred way of denoting axes -++++++++++++++++++++++++++++++ - - -.. code-block:: text - :linenos: - - data:NXdata - time_of_flight = 1500.0 1502.0 1504.0 ... - polar_angle = 15.0 15.6 16.2 ... - some_other_angle = 0.0 0.0 2.0 ... - data = 5 7 14 ... - @axes = polar_angle:time_of_flight - @signal = 1 - - - -.. _Design-LinkingByDimNumber: - -Linking by dimension number using the `axis` attribute -++++++++++++++++++++++++++++++++++++++++++++++++++++++ - -The original method is to define an attribute of each dimension -scale called *axis*. :index:`axis` -It is an integer whose value is the number of -the dimension, in order of fastest varying dimension. :index:`dimension; fastest varying` -That is, if the array being stored is data with elements -``data[j][i]`` in C and -``data(i,j)`` in Fortran, where ``i`` is the -time-of-flight index and ``j`` is -the polar angle index, the :ref:`NXdata` group :index:`NXdata` -would contain: - -.. code-block:: text - :linenos: - - data:NXdata - time_of_flight = 1500.0 1502.0 1504.0 ... - @axis = 1 - @primary = 1 - polar_angle = 15.0 15.6 16.2 ... - @axis = 2 - @primary = 1 - some_other_angle = 0.0 0.0 2.0 ... - @axis = 1 - data = 5 7 14 ... - @signal = 1 - -The ``axis`` attribute must -be defined for each dimension scale. -The ``primary`` attribute is unique to this method of linking. - -There are limited circumstances in which more -than one dimension scale :index:`dimension; dimension scales` -for the same data dimension can be included in the same -:ref:`NXdata` group. :index:`NXdata` -The most common is when the dimension scales are -the three components of an -*(hkl)* scan. In order to -handle this case, we have defined another attribute -of type integer called -``primary`` whose value determines the order -in which the scale is expected to be -chosen for plotting, :index:`NeXus basic motivation; default plot` -i.e. - - **Note:** - The `primary` attribute can only be - used with the first method of defining dimension scales - :index:`dimension; dimension scales` - discussed above. In addition to - the ``signal`` data, this - group could contain a data set of the same rank - :index:`rank` - and dimensions called ``errors`` - containing the standard deviations of the data. - -1st choice: - ``primary="1"`` - -2nd choice: - ``primary="2"`` - -etc. - -If there is more than one scale with the same value of the ``axis`` attribute, one -of them must have set ``primary="1"``. Defining the ``primary`` -attribute for the other scales is optional. - - -.. _Design-Linking-Discussion: - -Discussion of the two linking methods -+++++++++++++++++++++++++++++++++++++ - -In general the method using the ``axes`` attribute on the multi dimensional -data set :index:`dimension; data set` should be preferred. -This leaves the actual axis describing data sets -unannotated and allows them to be used as an axis for other multi dimensional -data. This is especially a concern as an axis describing a data set may be linked -into another group where it may describe a completely different dimension -of another data set. - -Only when alternative axes definitions are needed, the ``axis`` method -should be used to specify an axis of a data set. -This is shown in the example above for -the ``some_other_angle`` field where ``axis="1"`` -denotes another possible primary axis for plotting. The default -axis for plotting carries the ``primary="1"`` attribute. - -Both methods of linking data axes will be supported in NeXus -utilities that identify dimension scales, :index:`dimension; dimension scales` -such as ``NXUfindaxis()``. - - -.. _Rules-StoringDetectors: - -Storing Detectors ------------------ - -There are very different types of detectors out there. Storing their data -can be a challenge. As a general guide line: if the detector has some -well defined form, this should be reflected in the data file. A linear -detector becomes a linear array, a rectangular detector becomes an -array of size ``xsize`` times ``ysize``. -Some detectors are so irregular that this -does not work. Then the detector data is stored as a linear array, with the -index being detector number till ``ndet``. Such detectors must be accompanied -by further arrays of length ``ndet`` which give -``azimuthal_angle``, ``polar_angle`` and ``distance`` for each detector. - -If data from a time of flight (TOF) instrument must be described, then the -TOF dimension becomes the last dimension, for example an area detector of -``xsize`` *vs.* ``ysize`` -is stored with TOF as an array with dimensions -``xsize``, ``ysize``, ``ntof``. - - -.. _Rules-StoringData-Monitors: - -Monitors are Special --------------------- - -Monitors, :index:`monitor` detectors that measure the properties -of the experimental probe rather than the -sample, have a special place in NeXus files. Monitors are crucial to normalize data. -To emphasize their role, monitors are not stored in the -:ref:`NXinstrument` hierarchy but as :ref:`NXmonitor` group(s) as direct -children of the :ref:`NXentry` level, as there might be multiple monitors. Of special -importance is the monitor in a group called ``control``. -This is the main monitor against which the data has to be normalized. -This group also contains the counting control information, -i.e. counting mode, times, etc. - -Monitor data may be multidimensional. Good examples are scan monitors -where a monitor value per scan point is expected or -time-of-flight monitors. diff --git a/_sphinx/source/volume1/design/fileformat.rst b/_sphinx/source/volume1/design/fileformat.rst deleted file mode 100755 index 88864445a..000000000 --- a/_sphinx/source/volume1/design/fileformat.rst +++ /dev/null @@ -1,189 +0,0 @@ -.. $Id$ - -.. _Fileformat: - -===================================== -Physical File format -===================================== - -.. index:: NeXus; low-level file formats -.. index:: NAPI; bypassing - -This section describes how NeXus structures are mapped to features of the -underlying physical file format. -This can also be considered a guide for people who wish to create NeXus -files without using the NeXus-API. - -.. _Fileformat-HDF-Choice: - -Choice of HDF as Underlying File Format -------------------------------------------------- - -.. index:: HDF -.. index:: API - -At its beginnings, the founders of NeXus identified the Hierarchical Data -Format (HDF) [#]_, as a multi-platform data storage format with capacity -for conveying large data payloads and a substantial user community. HDF -(now HDF5) was provided with software to read and write data (this is the -application-programmer interface, or API) using a large number of -computing systems in common use for neutron and X-ray science. HDF is a -binary data file format that supports compression and structured data. - -.. [#] HDF: http://www.hdfgroup.org, - initially from the National Center for Supercomputing - Applications (NCSA) at the University of Illinois at - Urbana-Champaign (UIUC) and later spun off into its own group - called The HDF Group (THG). - -.. _Fileformat-Mapping-HDF: - -Mapping NeXus into HDF -------------------------------------------------- - -.. index:: attributes - -NeXus data structures map directly to HDF structures. - -NeXus *groups* - HDF4 *vgroups* or HDF5 *groups* - -NeXus data sets (or *fields*) - HDF4 *SDS (scientific data sets)* or HDF5 *datasets* - -Attributes - HDF group or dataset attributes. - -The only special case is the NeXus class name. -HDF4 supports a group class -which is set with the ``Vsetclass()`` call -and read with ``VGetclass()``. -HDF-5 has no group class. Thus the NeXus class -is stored as a group attribute with the name ``NX_class``. - -NeXus links directly map to the HDF linking mechanisms. - - - -.. _Fileformat-Mapping-XML: - -Mapping NeXus into XML -------------------------------------------------- - -.. index:: attributes - -This takes a bit more work than HDF. -At the root of NeXus XML file -is a XML element with the name ``NXroot``. -Further XML attributes to -``NXroot`` define the NeXus file level attributes. - -NeXus groups are encoded into XML as elements with the name of the NeXus -class and an XML attribute ``name`` which defines the NeXus name of the -group. Further group attributes become XML attributes. An example of a -NeXus group element in XML: - -.. code-block:: text - :linenos: - - - - -.. index:: dimension - -NeXus data sets are encoded as XML elements with the name of the data. An -attribute ``NAPItype`` defines the type and dimensions of the data. The -actual data is stored as ``PCDATA`` [#]_ in the element. An example of two -NeXus data elements in XML: - -.. code-block:: text - :linenos: - - - monitor - - - 21 456 127876 319 - - - -.. [#] ``PCDATA`` is the XML term for - *parsed character data* - (see: http://www.w3schools.com/xml/xml_cdata.asp) - -.. index:: dimension -.. index:: attributes - -Data are printed in appropriate formats and in C storage order. -The codes understood for ``NAPItype`` are -all the NeXus data type names. The dimensions -are given in square brackets as a comma -separated list. No dimensions need to be given if -the data is just a single value. -Data attributes are represented as XML attributes. -If the attribute is not a text string, then the -attribute is given in the form: *type:value*, for example: -``signal="NX_INT32:1"``. - -.. index:: link -.. index:: NAPIlink - -NeXus links are stored in XML as XML elements with the name ``NAPIlink`` -and a XML attribute ``target`` which stores the path to the linked entity -in the file. If the item is linked under a different name, then this name -is specified as a XML attribute name to the element ``NAPIlink``. - -The authors of the NeXus API worked with the author of the miniXML XML -[#miniXML]_ library to create a reasonably efficient way of handling -numeric data with XML. Using the NeXus API handling something like 400 -detectors versus 2000 time channels in XML is not a problem. But you may -hit limits with XML as the file format when data becomes to large or you -try to process NeXus XML files with general XML tools. General XML tools -are normally ill-prepared to process large amounts of numbers. - -.. [#miniXML] MiniXML: http://www.minixml.org/ - - - - -.. _Fileformat-SpecialAttributes: - -Special Attributes -------------------------------------------------- - -.. index:: attributes - -NeXus makes use of some special attributes for its internal purposes. -These attributes are stored as normal group or data set attributes -in the respective file format. These are: - -.. index:: link - -target - The `target` attribute is automatically created when items get linked. - The target attribute contains a text string with - the path to the source of the item linked. - -``napimount`` - The ``napimount`` attribute is used to implement - external linking in NeXus. - The string is a URL to the file and group in the - external file to link too. The system is meant to be extended. - But as of now, the only format supported is: - ``nxfile://path-to-file#path-infile``. - This is a NeXus file in the file system at path-to-file - and the group path-infile in that - NeXus file. - -.. index:: NAPIlink - -``NAPIlink`` - NeXus supports linking items in another group under another name. - This is only supported natively in HDF-5. - For HDF-4 and XML a crutch is needed. - This crutch is a special class name or attribute - ``NAPIlink`` combined with the - target attribute. For groups, ``NAPILink`` - is the group class, for data items a special attribute - with the name ``NAPIlink``. - \ No newline at end of file diff --git a/_sphinx/source/volume1/design/index.rst b/_sphinx/source/volume1/design/index.rst deleted file mode 100755 index 3f0437027..000000000 --- a/_sphinx/source/volume1/design/index.rst +++ /dev/null @@ -1,718 +0,0 @@ -.. $Id$ - -.. TODO: subdivide this file - -.. _NeXus-Design: - -************ -NeXus Design -************ - -This chapter actually defines the rules to use for -writing valid NeXus files. An explanation of NeXus objects -is followed by the definition of NeXus coordinate systems, -the rules for structuring files and the rules for -storing single items of data. - - **Note:** - In this manual, we use the terms *field*, *data field*, and - *data item* synonymously to be consistent - with their meaning between NeXus data file instances and - NXDL specification files. - -.. index:: hierarchy -.. index:: data objects; fields - -The structure of NeXus files is extremely flexible, -allowing the storage both of simple data sets, such as a -single data array and its axes, and also of highly complex -data, such as the simulation results or an entire -multi-component instrument. This flexibility is a necessity -as NeXus strives to capture data from a wild variety of -applications in x-ray, muSR and neutron scattering. The -flexibility is achieved through a structural -:index:`hierarchy`, with related *fields* -collected together into *groups*, -making NeXus files easy to navigate, even without any -documentation. NeXus files are self-describing, and -should be easy to understand, at -least by those familiar with the experimental technique. - -.. _Design-Objects: - -======================= -NeXus Objects and Terms -======================= - -Before discussing the design of NeXus in greater detail -it is necessary to define the objects and terms -used by NeXus. These are: - -:ref:`Design-Groups` - Group data fields and other groups together. - Groups represent levels in the NeXus hierarchy - -:ref:`Design-Fields` - Multidimensional arrays and scalars - representing the actual data to be stored - -:ref:`Design-Attributes` - Additional metadata which can be assigned - to groups or data fields - -:ref:`Design-Links` - Elements which point to data stored in - another place in the file hierarchy - -:ref:`Design-NeXusClasses` - Dictionaries of names possible in the - various types of NeXus groups - -:ref:`Design-NeXusApplications` - Describe the content of a NeXus file - for a particular usage case - -:ref:`Design-CoordinateSystem` - Coordinate systems are used to describe the - positions and orientations of objects. - -:ref:`Rules` - This section describes *where to place data* within - a NeXus data file. - -:ref:`DataRules` - This section describes *how to store data* in a NeXus data file. - -:ref:`Fileformat` - This section describes how NeXus structures - are mapped to features of the underlying - physical file format. - -In the following sections these elements of -NeXus files will be defined in more detail. - -.. _Design-Groups: - -Data Groups -+++++++++++ - -.. index:: data objects; groups -.. index:: hierarchy -.. index:: rules; HDF - -NeXus files consist of data groups, -which contain fields and/or other -groups to form a hierarchical structure. -This hierarchy is designed to make it -easy to navigate a NeXus file by storing related fields together. Data -groups are identified both by a name, which must be unique within a particular -group, and a class. There can be multiple groups with the same class -but they must have different names (based on the HDF rules). -For the class names used with NeXus data groups -the prefix `NX` is reserved. Thus all NeXus class -names start with `NX`. - -.. _Design-Fields: - -Data Fields -+++++++++++ - -.. index:: data objects; fields -.. index:: data objects; data items - -Data fields -contain the essential information stored in a NeXus file. They can -be scalar values or multidimensional arrays of a variety of sizes (1-byte, -2-byte, 4-byte, 8-byte) and types (integers, floats, characters). The fields may -store both experimental results (counts, detector angles, etc), and other -information associated with the experiment (start and end times, user names, -etc). Data fields are identified by their names, which must be unique within the -group in which they are stored. - -.. _Design-Attributes: - -Data Attributes -+++++++++++++++ - -.. index:: data objects; attributes -.. index:: units -.. index:: NeXus basic motivation; default plot -.. index:: data objects; attributes; global - -Attributes -are extra (meta-)information that are associated with particular -fields. They are used to annotate the data, for example with physical units -or calibration offsets, and may be scalar numbers or character -strings. NeXus also uses attributes to identify plottable data -and their axes, etc. -A description of possible attributes can be found -in the table titled :ref:`table.ExampleAttributes`. -Finally, NeXus files themselves have global -attributes which are listed in the :ref:`table.GlobalAttributes` table -that identify the NeXus version, file creation time, etc. -Attributes are identified by their -names, which must be unique in each field. - - - -.. _table.ExampleAttributes: - -Example NeXus Data Attributes ------------------------------ - -For the full specification of attributes, -see :ref:`volume2.NXDL.section`. - -.. tabularcolumns:: |l|l|L| - -+---------------------+----------+-------------------------------------------+ -| Name | Type | Description | -+=====================+==========+===========================================+ -| units | NX_CHAR | Data units, given as character strings, | -| | | must conform to the NeXus units standard. | -| | | See the "NeXus units" section | -| | | for details. | -+---------------------+----------+-------------------------------------------+ -| signal | NX_INT | Defines which data set contains the | -| | | signal to be plotted use ``signal="1"`` | -| | | for main signal | -+---------------------+----------+-------------------------------------------+ -| axes | NX_CHAR | Defines the names of the dimension | -| | | scales for this data set as a | -| | | colon-delimited list. For example, | -| | | suppose data is an array with elements | -| | | ``data[j][i]`` (C) | -| | | or ``data(i,j)`` (Fortran), with | -| | | dimension scales `time_of_flight[i]` | -| | | and `polar_angle[j]`, then data would | -| | | have an attribute | -| | | ``axes="polar_angle:time_of_flight"`` | -| | | in addition to an attribute | -| | | ``signal="1"``. | -+---------------------+----------+-------------------------------------------+ -| axis | NX_INT | The original way of designating data | -| | | for plotting, now superceded by the | -| | | axes attribute. This defines the rank | -| | | of the signal data for which this data | -| | | set is a dimension scale in order of | -| | | the fastest varying index (see a longer | -| | | discussion in | -| | | :ref:`Design-Linking-ByName`), | -| | | i.e. if the array being stored is data, | -| | | with elements ``data[j][i]`` in C and | -| | | ``data(i,j)`` in Fortran, axis would | -| | | have the following values: | -| | | ith dimension (``axis="1"``), | -| | | jth dimension (``axis="2"``), etc. | -+---------------------+----------+-------------------------------------------+ -| primary | NX_INT32 | Defines the order of preference for | -| | | dimension scales which apply to the | -| | | same rank of signal data. Use | -| | | `primary="1"` to indicate preferred | -| | | dimension scale | -+---------------------+----------+-------------------------------------------+ -| long_name | NX_CHAR | Defines title of signal data or | -| | | axis label of dimension scale | -+---------------------+----------+-------------------------------------------+ -| calibration_status | NX_CHAR | either `Nominal` or `Measured` | -| | | Defines status of data value. | -+---------------------+----------+-------------------------------------------+ -| offset | NX_INT | Rank values off offsets to use for | -| | | each dimension if the data is not in | -| | | C storage order | -+---------------------+----------+-------------------------------------------+ -| stride | NX_INT | Rank values of steps to use when | -| | | incrementing the dimension | -+---------------------+----------+-------------------------------------------+ -| transformation_type | NX_CHAR | `translation` or `rotation` | -+---------------------+----------+-------------------------------------------+ -| vector | NX_FLOAT | 3 values describing the axis of | -| | | rotation or the direction of translation | -+---------------------+----------+-------------------------------------------+ -| interpretation | NX_CHAR | Describes how to display the data. | -| | | Allowed values include: | -| | | scaler (0-D data), | -| | | spectrum (1-D data), | -| | | image (2-D data), | -| | | or vertex (3-D data). | -+---------------------+----------+-------------------------------------------+ - -.. _table.GlobalAttributes: - -NeXus File Global Attributes ----------------------------- - -.. tabularcolumns:: |l|l|L| - -+------------------+----------+--------------------------------------+ -| Name | Type | Description | -+==================+==========+======================================+ -| file_name | NX_CHAR | Original name of NeXus file. | -+------------------+----------+--------------------------------------+ -| file_time | ISO 8601 | Date and time of file creation | -+------------------+----------+--------------------------------------+ -| file_update_time | ISO 8601 | Date and time of last file change | -| | | at close | -+------------------+----------+--------------------------------------+ -| NeXus_version | NX_CHAR | Version of NeXus API used in writing | -| | | the file | -+------------------+----------+--------------------------------------+ -| creator | NX_CHAR | Facility or program where the file | -| | | originated | -+------------------+----------+--------------------------------------+ - -.. _Design-Links: - -Data Links -++++++++++ - -.. index:: link -.. index:: target, link - -Links are pointers to existing data somewhere else. -The concept is very much like -symbolic links in a unix filesystem. -The NeXus definition sometimes requires -access to the same data in different groups -within the same file. -For example: detector data is stored in the -``NXinstrument/NXdetector`` group -but may be needed in ``NXdata`` for automatic plotting. -Rather then replicating the data, NeXus uses -links in such situations. See the figure :ref:`fig.data-linking` for -a more descriptive representation of the concept of linking. - -.. _fig.data-linking: - -Linking in a NeXus file ------------------------ - -.. figure:: data-linking.png - :width: 400 pt - - Linking in a NeXus file. - See example code below: :ref:`example.data-linking` - -.. _Design-NeXusClasses: - -NeXus Classes -+++++++++++++ - -.. index:: NXDL -.. index:: rules; naming - -Data groups often describe objects in the experiment (monitors, detectors, -monochromators, etc.), so that the contents (both data fields and/or other data -groups) comprise the properties of that object. NeXus has defined a set of standard -objects, or base classes, out of which a NeXus file can be constructed. This is each data group -is identified by a name and a class. The group class, defines the type of object -and the properties that it can contain, whereas the group name defines a unique instance -of that class. These classes are -defined in XML using the NeXus Definition Language (NXDL) -format. All NeXus class types adopted by the NIAC *must* -begin with `NX`. -Classes not adopted by the NIAC *must not* -start with `NX`. - -.. index:: NeXus basic motivation; default plot - -Not all classes define physical objects. Some refer to logical groupings of -experimental information, such as plottable data, -sample environment logs, beam -profiles, etc. -There can be multiple instances of each class. On -the other hand, a typical NeXus file will only contain a small subset of the -possible classes. - -NeXus base classes are not proper classes in the -same sense as used in object oriented programming -languages. In fact the use of the term classes is -actually misleading but has established itself -during the development of NeXus. NeXus base -classes are rather dictionaries of field names -and their meanings which are permitted in a -particular NeXus group implementing the NeXus -class. This sounds complicated but becomes easy -if you consider that most NeXus groups describe -instrument components. Then for example, a -:ref:`NXmonochromator` base class describes all the -possible field names which NeXus allows to be -used to describe a monochromator. - -Most NeXus base classes represent instrument components. -Some are used as containers to structure information in a -file (:ref:`NXentry`, :ref:`NXcollection`, :ref:`NXinstrument`, -:ref:`NXprocess`, :ref:`NXparameters`). But there are some base -classes which have special uses that need to be -mentioned here: - -:ref:`NXdata` - `NXdata` is used to identify the default plottable data. - The notion of a default plot of data is a basic - motivation of NeXus. - -:ref:`NXlog` - `NXlog` is used to store time stamped data like the - log of a temperature controller. Basically you give - a start time, and arrays with a difference in seconds - to the start time and the values read. - -:ref:`NXnote` - `NXnote` provides a place to store general notes, - images, video or whatever. A mime type is stored - together with a binary blob of data. Please use this - only for auxiliary information, for example an image - of your sample, or a photo of your boss. - -:ref:`NXgeometry` - `NXgeometry` and its subgroups :ref:`NXtranslation`, - :ref:`NXorientation`, and :ref:`NXshape` are used to store absolute - positions in the laboratory coordinate system or to - define shapes. - -These groups can appear anywhere in the NeXus hierarchy, -where needed. Preferably close to the component they -annotate or in a :ref:`NXcollection`. All of the base classes -are documented in the reference manual. - -.. _NXdata-facilitates-TheDefaultPlot: - -`NXdata` Facilitates Automatic Plotting ---------------------------------------- - -The most notable special base class -(also known as *group*) in NeXus is :ref:`NXdata`. -`NXdata` is the answer to a basic motivation of NeXus -to facilitate automatic plotting of data. -:index:`NeXus basic motivation; default plot` -`NXdata` is designed to contain the main dataset -and its associated dimension scales (axes) -:index:`dimension scale` -of a NeXus data file. The usage scenario is that an -automatic data plotting program just opens a -:ref:`NXentry` and then continues to search for any -`NXdata` groups. These `NXdata` groups represent -the plottable data. Here is the way an -automatic plotting program ought to work: - -1. Search for ``NXentry`` groups - -2. Open an ``NXentry`` - -3. Search for ``NXdata`` groups - -4. Open an ``NXdata`` group - -5. Identify the plottable data. - - a. Search for a dataset with attribute ``signal=1``. - This is your main dataset. - (There should be only one dataset that matches.) - - b. Try to read the axes attribute of the - main dataset, if it exists. - - i. The value of axes is a colon- or - comma-separated list of the datasets describing - the dimension scales - (such as ``axes="polar_angle:time_of_flight"``). - - ii. Parse axes and open the datasets to describe - your dimension scales - - c. If axes does not exist: - - i. Search for datasets with attributes - ``axis=1``, ``axis=2``, etc. - These are the datasets describing your axis. - There may be several datasets for any axis, - i.e. there may be multiple datasets with - the attribute ``axis=1``. Among them the - dataset with the attribute ``primary=1`` is - the preferred one. All others are - alternative dimension scales. - - ii. Open the datasets to describe - your dimension scales. - -6. Having found the default plottable data - and its dimension scales: make the plot - -.. _Design-NeXusApplications: - -NeXus Application Definitions -+++++++++++++++++++++++++++++ - -The objects described so far provide us with the means to -store data from a wide variety of instruments, simulations -or processed data as resulting from data analysis. -But NeXus strives to express strict standards for certain -applications of NeXus too. The tool which NeXus uses for -the expression of such strict standards is the NeXus -Application Definition. A NeXus Application Definition -describes which groups and data items have to be present -in a file in order to properly describe an application -of NeXus. For example for describing a powder diffraction -experiment. Typically an application definition will contain -only a small subset of the many groups and fields defined -in NeXus. NeXus application definitions are also expressed -in the NeXus Definition Language (NXDL). A tool exists which -allows to validate a NeXus file against a given -application definition. - - **NeXus application definition is a contract** - - Another way to look at a NeXus application definition - is as a contract between a file writer and a file consumer - (reader). A contract which reads: - - *If you write your files - following a particular NeXus application definition, - I can process these files with my software.* - -Yet another way to look at a NeXus application definition -is to understand it as an interface definition between data -files and the software which uses this file. Much like an -interface in the Java or other modern object oriented -programming languages. - -In contrast to NeXus base classes, NeXus supports inheritance -in application definitions. - -Please note that a NeXus Application Definition will only -define the bare minimum of data necessary to perform common -analysis with data. Practical files will nearly always -contain more data. One of the beauties of NeXus is that it -is always possible to add more data to a file without breaking -its compliance with its application definition. - -.. _Design-CoordinateSystem: - -NeXus Coordinate Systems -++++++++++++++++++++++++ - -.. index:: geometry -.. index:: McStas -.. index:: CIF - -Coordinate systems in NeXus underwent quite some development. -Initially, just positions of relevant motors were -stored without further standardization. This soon proved to -be too little and the *NeXus polar coordinate* system was -developed. This system still is very close to angles -meaningful to an instrument scientist but allows to define -general positions of components easily. Then users from the -simulation community approached the NeXus team and asked for -a means to store absolute coordinates. This was implemented -through the use of the `NXgeometry` class on top of the -*McStas* [#McStas]_ -system. We soon learned that all the things we do -can be expressed through the McStas coordinate system. -So the McStas coordinate system -became the reference coordinate system for NeXus. -`NXgeometry` was expanded to allow the description of shapes -when the demand came up. -Later members of the CIF [#CIF]_ team -convinced the NeXus team of the beauty of transformation -matrices and NeXus was enhanced to store the necessary -information to fully map CIF concepts. Not much had to be -changed though as we choose to document the existing angles -in CIF terms. The CIF system allows to store arbitrary -operations and nevertheless calculate absolute coordinates in -the laboratory coordinate system. It also allows to convert -from local, for example detector coordinate systems, to -absolute coordinates in the laboratory system. - -.. [#McStas] McStas, http://www.mcstas.org, also http://mcstas.risoe.dk -.. [#CIF] CIF (Crystallographic Information Framework), http://www.iucr.org/resources/cif - -.. _Design-Coordinate-NXgeometry: - -McStas and `NXgeometry` System ------------------------------- - -.. index:: geometry -.. index:: McStas - -NeXus uses the *McStas coordinate system* [#McStas]_ -as its laboratory coordinate system. -The instrument is given a global, absolute coordinate system where: - -* the *z* axis points in the direction of the incident beam, -* the *x* axis is perpendicular to the beam in the horizontal - plane pointing left as seen from the source -* the *y* axis points upwards. - -See below for a drawing of the McStas coordinate system. The origin of this -coordinate system is the sample position or, if this is ambiguous, the center of the sample holder -with all angles and translations set to zero. -The McStas coordinate system is -illustrated in figure :ref:`fig.mcstasccord`. - -.. _fig.mcstasccord: - -.. figure:: mcstascoord.png - :width: 400 pt - - The McStas Coordinate System - -.. note:: The NeXus definition of `+z` is opposite to that - in the International Tables for Crystallography, - volume G, [#IUCr_G]_ and consequently, `+x` is also reversed. - - .. [#IUCr_G] **International Tables for Crystallography** - *Volume G: Definition and exchange of crystallographic data*. - Sydney Hall and Brian McMahon, Editors. - Published for the IUCr by Springer, 2005 - ISBN 1-4020-3138-6, 594 + xii pages - -The NeXus `NXgeometry` class directly uses the McStas -coordinate system. `NXgeometry` classes can appear in any -component in order to specify its position. The suggested -name to use is geometry. In `NXgeometry` the -`NXtranslation/values` field defines the absolute position of -the component in the McStas coordinate system. The -`NXorientation/value` field describes the orientation of the -component as a vector of in the McStas coordinate system. - -.. Comment by MK: - I think NXgeometry sucks. It is decided upon, so we have to document it as is. But I do think that - it introduces too many levels of hierarchy. I would rather like to have: - - an absolute_position[n,3] field at component level. This makes the absolute position easy to see and the n opens up - easily for those components which consist of many subcomponents like a many pixel detector. - - an absolute_orientation[n?,3] field to define the orientation at component level. May be we need an n here too for multi - pixel components. - - I would love to pull down the NXshape group to component level too. - Perhaps we can allow that and mark NXgeometry deprecated? - - -.. _Design-Coordinate-Spherical: - -Simple (Spherical Polar) Coordinate System ------------------------------------------- - -.. index:: geometry - -In this system, the instrument is considered as a set of -components through which the incident beam passes. The -variable **distance** is assigned to each component and -represents the effective beam flight path length between this -component and the sample. A sign convention is used where -negative numbers represent components pre-sample and positive -numbers components post-sample. At each component there is -local spherical coordinate system with the angles -*polar_angle* and *azimuthal_angle*. The size of the sphere -is the distance to the previous component. - -In order to understand this spherical polar coordinate system -it is helpful to look initially at the common condition that -azimuthal_angle is zero. This corresponds to working directly -in the horizontal scattering plane of the instrument. In this -case polar_angle maps directly to the setting commonly known -as two theta. Now, there are instruments where components -live outside of the scattering plane. Most notably detectors. -In order to describe such components we first apply the tilt -out of the horizontal scattering plane as the -azimuthal_angle. Then, in this tilted plane, we rotate to the -component. The beauty of this is that polar_angle is always -two theta. Which, in the case of a component out of the -horizontal scattering plane, is not identical to the value -read from the motor responsible for rotating the component. -This situation is shown in figure -:ref:`fig.polar-geometry-figure`. - -.. _fig.polar-geometry-figure: - -.. figure:: polplane.png - :width: 200 pt - - NeXus Simple (Spherical Polar) Coordinate System - - -.. _CoordinateTransformations: - -Coordinate Transformations --------------------------- - -.. index:: coordinates; transformations - -Another way to look at coordinates is through the use of transformation matrices. -In this world view, the absolute position of a component or a detector pixel with respect to -the laboratory corrdinate system is calculated by applying a series of translations and -rotations. These operations are commonly expressed as transformation matrices and their -combination as matrix multiplication. A very important aspect is that the order of application -of the individual operations *does* matter. Another important aspect is that -any operation transforms the whole coordinate system and gives rise to a new local coordinate system. -The mathematics behind this is -well known and used in such applications such as industrial robot control, space flight and -computer games. The beauty in this comes from the fact that the operations to apply map easily -to instrument settings and constants. It is also easy to analyze the contribution of each individual -operation: this can be studied under the condition that all other operations are at a zero setting. - -In order to use coordinate transformations, several morsels of information need to be known: - -Type - The type of operation: rotation or translation - -Direction - The direction of the translation or the direction of the rotation axis - -Value - The angle of rotation or the length of the translation - -Order - The order of operations to apply to move a component into its place. - -.. _tb.table-transform: - -Actions of standard NeXus fields -................................ - -================= ==================== ================= -Field Name transformation_type vector -================= ==================== ================= -polar_angle rotation 0 1 0 -azimuthal_angle rotation 0 0 1 -meridional_angle rotation 1 0 0 -distance translation 0 0 1 -height translation 0 1 0 -x_translation translation 1 0 0 -chi rotation 0 0 1 -phi rotation 0 1 0 -================= ==================== ================= - -The type and direction of the NeXus standard operations is documented in table :ref:`tb.table-transform`. -NeXus can now also allow non standard operations to be stored in data files. In such cases additional data -attributes are required which describe the operation. These are *transformation_type* which -can be either translation or rotation. The other is *vector* which is 3 float values describing -the direction of translation or rotation. The value is of course always the value of the data field in the data file. - -How NeXus describes the order of operations to apply has not yet been decided upon. The authors favorite scheme -is to use a special field at each instrument component, named *transform* which describes the -operations to apply to get the component into its position as a list of colon separated paths to the operations -to apply relative to the current `NXentry`. For paths in the same group, only the name need to be given. Detectors -may need two such fields: the transfrom field to get the detector as a whole into its position -and a *transform_pixel* field which describes how the absolute position of a detector pixel -can be calculated. - -For the NeXus spherical coordinate system, the order is implicit and is given by:: - - azimuthal_angle:polar_angle:distance - -This is also a nice example of the application of transformation matrices: - -#. You first apply azimuthal_angle as a rotation around *z*. - This rotates the whole coordinate out of the plane. - -#. Then you apply polar_angle as a rotation around *y* - in the tilted coordinate system. - -#. This also moves the direction of the *z* vector. - Along which you translate the component to place by distance. - -.. toctree:: - :maxdepth: 1 - - rules/index - datarules - fileformat diff --git a/_sphinx/source/volume1/design/mcstascoord.png b/_sphinx/source/volume1/design/mcstascoord.png deleted file mode 100755 index 6f7d41b40..000000000 Binary files a/_sphinx/source/volume1/design/mcstascoord.png and /dev/null differ diff --git a/_sphinx/source/volume1/design/polplane.png b/_sphinx/source/volume1/design/polplane.png deleted file mode 100755 index 83868c45f..000000000 Binary files a/_sphinx/source/volume1/design/polplane.png and /dev/null differ diff --git a/_sphinx/source/volume1/design/rules/index.rst b/_sphinx/source/volume1/design/rules/index.rst deleted file mode 100755 index 1e3f7b579..000000000 --- a/_sphinx/source/volume1/design/rules/index.rst +++ /dev/null @@ -1,75 +0,0 @@ -.. $Id$ - -.. _Rules: - -================================================ -Rules for Structuring Information in NeXus Files -================================================ - -.. index:: rules; NeXus -.. index:: rules; naming - -All NeXus files contain one or many groups of type ``NXentry`` at root -level. Many files contain only one ``NXentry`` group, then the name is -``entry``. The NXentry level of hierarchy is there to support the storage -of multiple related experiments in one file. Or to allow the NeXus file to -serve as a container for storing a whole scientific workflow from data -acquisition to publication ready data. Also, ``NXentry`` class groups can -contain raw data or processed data. For files with more than one -``NXentry`` group, since HDF requires that no two items at the same level -in an HDF file may have the same name, the NeXus fashion is to assign -names with an incrementing index appended, such as ``entry1``, ``entry2``, -``entry3``, etc. - - -In order to illustrate what is written in the text, -example hierarchies like the one in -figure Raw Data are provided. - -.. _Rules-NXentry-raw-data: - -Content of a Raw Data ``NXentry`` Group ---------------------------------------- - -An example raw data hierarchy is shown in the next figure (only showing -the relevant parts of the data hierarchy). In the example shown, the -``data`` field in the :ref:`NXdata` group is linked to the 2-D detector data -(a 512x512 array of 32-bit integers) which has the attribute ``signal=1``. -Note that ``[,]`` represents a 2D array. - -.. code-block:: text - :linenos: - - entry:NXentry - instrument:NXinstrument - source:NXsource - .... - detector:NXdetector - data:NX_INT32[512,512] - @signal = 1 - sample:NXsample - control:NXmonitor - data:NXdata - data --> /entry/instrument/detector/data - -An :ref:`NXentry` describing raw data contains at least a :ref:`NXsample`, one -:ref:`NXmonitor`, one :ref:`NXdata` and a :ref:`NXinstrument` group. It is good -practice to use the names ``sample`` for the :ref:`NXsample` group, -``control`` for the :ref:`NXmonitor` group holding the experiment -controlling monitor and ``instrument`` for the :ref:`NXinstrument` group. -The :ref:`NXinstrument` group contains further groups describing the -individual components of the instrument as appropriate. - -.. index:: hierarchy - -The ``NXdata`` group contains links to all those data items in the -``NXentry`` hierarchy which are required to put up a default plot of the -data. As an example consider a SAXS instrument with a 2D detector. The -``NXdata`` will then hold a link to the detector image. If there is only -one ``NXdata`` group, it is good practice to name it ``data``. Otherwise, -the name of the detector bank represented is a good selection. - -.. TODO: show an example of this - - -.. include rules/processed here diff --git a/_sphinx/source/volume1/design/rules/processed.rst0 b/_sphinx/source/volume1/design/rules/processed.rst0 deleted file mode 100755 index 8977fb857..000000000 --- a/_sphinx/source/volume1/design/rules/processed.rst0 +++ /dev/null @@ -1,380 +0,0 @@ -.. $Id$ - -.. _: - ---------------------------------------------- - -.. index:: - -
- Content of a processed data ``NXentry`` group - Processed data, see figure Processed Data, - in this context means the results of a data reduction or - data analysis program. Note that ``[]`` represents a 1D array. - -
- NeXus Processed Data Hierarchy - -
- - - NeXus stores such data in a simplified - ``NXentry`` structure. A processed data ``NXentry`` - has at minimum a ``NXsample``, - a ``NXdata`` and a ``NXprocess`` group. - Again the preferred name for the ``NXsample`` - group is ``sample``. - In the case of processed data, the ``NXdata`` group holds the - result of the processing together with the associated axis data. - The ``NXprocess`` - group holds the name and version of the program used for this processing - step and further ``NXparameter`` groups. These groups ought to contain the - parameters used for this data processing step in suitable detail so that - the processing step can be reproduced. - - - Optionally a processed data ``NXentry`` - can hold a ``NXinstrument`` group with - further groups holding relevant information about the instrument. The - preferred name is again ``instrument``. Whereas for a raw data file, NeXus - strives to capture as much data as possible, a ``NXinstrument`` group for - processed data may contain a much-reduced subset. - -
- -.. _: - ---------------------------------------------- - -.. index:: - -
- <literal>NXsubentry</literal> or Multi-Method Data - - Especially at synchrotron facilities, there are experiments which perform several different methods - on the sample at the same time. For example, combine a powder diffraction experiment with XAS. - This may happen in the same scan, so the data needs to be grouped together. A suitable NXentry - would need to adhere to two different application definitions. This leads to name clashes which cannot be - easily resolved. In order to solve this issue, the following scheme was implemented in NeXus: - - The complete beamline (all data) is stored in an - appropriate hierarchy in an NXentry. - - The NXentry group contains further NXsubentry groups, one for each method. The NXsubentry group is constructed - like a NXentry group. It contains links to all those data items required to fulfill the application definition - for the particular method it represents. - - - See figure NeXus Multi Method Hierarchy for an example hierarchy. - Note that ``[,]`` represents a 2D array. - - -
- NeXus Multi Method Hierarchy - -
- - -
- -.. _: - ---------------------------------------------- - -.. index:: - -
- Rules for Special Cases - -
- Scans - - Scans are difficult to capture because they have great variety. Basically, - any variable can be scanned. Such behaviour cannot be captured in application definitions. - Therefore NeXus solves this difficulty with a set of - rules. In this section, ``NP`` is used as a symbol for the number of scan - points. - - - - The scan dimension ``NP`` is always the first dimension of any - multi-dimensional dataset. The reason for this is that HDF allows the first - dimension of a dataset to be unlimited. - - Which means, that data can be - appended to the dataset during the scan. - - - - - All data is stored as arrays of dimensions ``NP``, original dimensions - of the data at the appropriate position in the ``NXentry`` hierarchy. - - hierarchy - - - - - - The ``NXdata`` group has to contain links to all variables varied during - the scan and the detector data. Thus the ``NXdata`` group mimics the usual - tabular representation of a scan. - - - - - Datasets in an ``NXdata`` group must contain the proper attributes - to enable the default plotting, - - NeXus basic motivation - default plot - - as described in the section titled - NXdata - Facilitates Automatic Plotting. - - - - -
- Simple scan - - Examples may be in order here. Let us start with a simple case, the sample is - rotated around its rotation axis and data is collected in a single point - detector. See figure Simple Scan for an overview. - Then we have: - - - - A dataset at ``NXentry/NXinstrument/NXdetector/data`` - of length ``NP`` containing - the count data. - - - - - A dataset at ``NXentry/NXsample/rotation_angle`` - of length ``NP`` containing - the positions of ``rotation_angle`` at the various steps of the scan. - - - - - ``NXdata`` contains links to - ``NXentry/NXinstrument/NXdetector/data`` and - ``NXentry/NXsample/rotation_angle``. - - - - - All other data fields have their normal dimensions. - - - - -
- NeXus Simple Scan Example - -
-
- -
- Simple scan with area detector - - The next example is the same scan but with an area detector with ``xsize`` - times ``ysize`` pixels. The only thing which changes is that - ``/NXentry/NXinstrument/NXdetector/data`` will have the dimensions - ``NP, xsize, ysize``. See figure Simple Scan with Area Detector - for an overview. - - -
- NeXus Simple Scan Example with Area Detector - -
-
- - -
- Complex <emphasis>hkl</emphasis> scan - - The next example involves a complex movement along an axis in reciprocal - space which requires mutiple motors of a four circle diffractometer to be - varied during the scan. We then have: - - - - A dataset at ``NXentry/NXinstrument/NXdetector/data`` of length - ``NP`` containing - the count data. - - - - - A dataset at ``NXentry/NXinstrument/NXdetector/polar_angle`` of length - ``NP`` containing - the positions of the detector's polar_angle at the various steps - of the scan. - - - - - A dataset at ``NXentry/NXsample/rotation_angle`` of length - ``NP`` containing - the positions of ``rotation_angle`` at the various steps of the scan. - - - - - A dataset at ``NXentry/NXsample/chi`` of length ``NP`` containing - the positions of chi at the various steps of the scan. - - - - - A dataset at ``NXentry/NXsample/phi`` of length ``NP`` containing - the positions of phi at the various steps of the scan. - - - - - A dataset at ``NXentry/NXsample/h`` of length ``NP`` containing - the positions of the reciprocal coordinate ``h`` at the - various steps of the scan. - - - - - A dataset at ``NXentry/NXsample/k`` of length ``NP`` containing - the positions of the reciprocal coordinate ``k`` at the - various steps of the scan. - - - - - A dataset at ``NXentry/NXsample/l`` of length ``NP`` containing - the positions of the reciprocal coordinate ``l`` at the - various steps of the scan. - - - - - ``NXdata`` contains links to - ``NXentry/NXinstrument/NXdetector/data``, - ``NXentry/NXinstrument/NXdetector/polar_angle``, - ``NXentry/NXsample/rotation_angle``, - ``NXentry/NXsample/chi``, - ``NXentry/NXsample/phi``, - ``NXentry/NXsample/h``, - ``NXentry/NXsample/k`` and - ``NXentry/NXsample/l `` - The datasets in ``NXdata`` must have the - appropriate attributes as described in the axis location section. - - - - - All other data fields have their normal dimensions. - - - - -
- NeXus Complex <emphasis>hkl</emphasis> Scan - -
-
-
- Multi-parameter scan: XAS - - Data can be stored almost anywhere in the NeXus tree. While the previous examples - showed data arrays in either NXdetector or NXsample, - this example demonstrates that data can be stored in other places. Links are used - to reference the data. - - - The example is for X-ray Absorption Spectroscopy (XAS) data where the monochromator - energy is step-scanned and counts are read back from detectors before (I0) - and after (I) the sample. These energy scans are repeated at a sequence - of sample temperatures to map out, for example, a phase transition. While it is customary - in XAS to plot log(I0/I), we show them separately here - in two different NXdata - groups to demonstrate that such things are possible. - Note that the length of the 1-D energy array is NE while - the length of the 1-D temperature array is NT - -
- NeXus Multi-parameter scan: XAS - -
-
-
- - -
- Rastering - - Rastering is the process of making experiments at various locations in the - sample volume. Again, rasterisation experiments can be variable. Some people - even raster on spirals! Rasterisation experiments are treated the same way as - described above for scans. Just replace ``NP`` with - ``P``, the number of raster points. - - - Special rules apply if a rasterisation happens on a regular grid of size - ``xraster, yraster``. Then the variables varied in the rasterisation will be - of dimensions ``xraster, yraster`` and the detector data of dimensions - ``xraster, yraster, (orginal dimensions)`` - of the detector. For example, an area detector of - size ``xsize, ysize`` then it is stored with - dimensions ``xraster, yraster, xsize, ysize``. - - - Be warned: if you use the 2D rasterisation method with ``xraster, yraster`` you may end up with - invalid data if the scan is aborted prematurely. This cannot happen if the first method is used. - - - -
- -
- NXcollection - - On demand from the community, NeXus introduced a more informal method of storing - information in a NeXus file. This is the NXcollection class which can appear anywhere - underneath NXentry. NXcollection is a container for holding other data. - The foreseen use is to document collections of similar data which do not otherwise fit easily into the ``NXinstrument`` - or ``NXsample`` hierarchy, such as the intent to record all motor positions on a synchrotron beamline. - Thus, NXcollection serves as a quick point of access to data for an instrument scientist or another expert. - An example usage case is documented in figure NXcollection example - . -
- NXcollection Example - - -
- - - Data in NXcollection has to be augmented by a NXsubentry - or NXentry adhering to an application definition. - -
- -
- diff --git a/_sphinx/source/volume1/faq.rst b/_sphinx/source/volume1/faq.rst deleted file mode 100644 index b107ff671..000000000 --- a/_sphinx/source/volume1/faq.rst +++ /dev/null @@ -1,259 +0,0 @@ -.. $Id$ - - -.. _FAQ: - -========================== -Frequently Asked Questions -========================== - -.. Undefined Labels - ---------------- - -.. _this example: -.. _mailing lists: -.. _nexus api: -.. _definitions repository: -.. _nxvalidate-java: - - -.. index:: FAQ - -This is a list of commonly asked questions concerning the NeXus data format. - - -How many facilities use NeXus? ------------------------------------------------------------ - -This is not easy to say, not all facilities using NeXus actively -participate in the committee. Some facilities (the list is incomplete) -have reported their adoption status on the NeXus wiki [#]_. -Please have a look at this list. - - .. [#] Facilities reporting use of NeXus: http://wiki.nexusformat.org/Facilities - -NeXus files are binary? This is crazy! How am I supposed to see my data? ---------------------------------------------------------------------------- - - -NeXus files are not binary *per se*. If you use the XML backend the -data are stored in a relatively human readable form (see -:ref:`this example`). -This backend however is only recommended for very small data sets. With -the multidimensional data that is routinely recorded on many modern -instruments it is very difficult anyway to retrieve useful -information on a VT100 terminal. If you want to try, for example -``nxbrowse`` -is a utility provided by the NeXus community that can be very -helpful to those who want to inspect their files and avoid -graphical applications. For larger data volumes the binary backends -used with the appropriate tools are by far superior in terms of -efficiency and speed and most users happily accept that after having -worked with supersized "human readable" files for a while. - -What on-disk file format should I choose for my data? ---------------------------------------------------------------------------- - -HDF5 is the default file container to use for NeXus data. It -is the recommended format for all applications. HDF4 is still -supported as a on disk format for NeXus but for new installations -preference should be given to HDF5. The XML backend is available -for special use cases. Choose this option with care considering the -space and speed implications. - -Why are the NeXus classes so complicated? I'll never store all that information --------------------------------------------------------------------------------------- - -The NeXus classes are essentially *glossaries of terms*. If you -need to store a piece of information, consult the class definitions -to see if it has been defined. If so, use it. It is not compulsory -to include every item that has been defined in the base class if it -is not relevant to your experiment. On the other hand, a NeXus -application definition lists a smaller set of compulsory items that -should allow other researchers or software to analyze your data. -You should really follow the application definition that -corresponds to your experiment to take full advantage of NeXus. - -I don't like NeXus. It seems much faster and simpler to develop my own file format. Why should I even consider NeXus? ------------------------------------------------------------------------------------------------------------------------------------------------------- - -If you consider using an efficient on disk storage format, -HDF5 is a better choice than most others. It is fast and efficient -and well supported in all main stream programming languages and a -fair share of popular analysis packages. The format is so widely -used and backed by a big organisation that it will continue to be -supported for the foreseeable future. -So if you are going to use HDF5 anyway, why not use the NeXus -definition to lay out the data in a standardised way? The NeXus -community spent years trying to get the standard right and -while you will not agree with every single choice they made in the -past, you should be able to store the data you have in a quite -reasonable way. If you do not comply with NeXus chances are most -people will perceive your format as different but not necessarily -better than NeXus by any large measure. So it may not be worth the -effort. Seriously. -If you encounter any problems because the classes are not -sufficient to describe your configuration, please contact the NIAC -Executive Secretary explaining the problem, and post a suggestion -at the relevant class wiki page. Or raise the problem in one of the -:ref:`mailing lists`. -The NIAC is always willing to consider new proposals. - -.. index:: NIAC - -I want to produce an application definition. How do I go about it? ---------------------------------------------------------------------------- - -.. index:: NXDL - -Read the NXDL Tutorial in -:ref:`NXDL_Tutorial-CreatingNxdlSpec`. -The procedures for acceptance are defined in the NIAC constitution. -Refer to the most recent version of the NIAC constitution on the -NIAC wiki [#]_. - - .. [#] NIAC wiki: http://www.nexusformat.org/NIAC - -What is the purpose of ``NXdata``? ---------------------------------------------------------------------------- - -.. index:: NeXus basic motivation; default plot - -``NXdata`` contains links to the data stored elsewhere in the -``NXentry``. It identifies the default plottable data. This is one of the -basic motivations (see :ref:`SimplePlotting`) -for the NeXus standard. The choice of the name ``NXdata`` -is historic and does not really reflect its function. - - -.. _`how to find the plottable data`: - -How do I identify the plottable data? ---------------------------------------------------------------------------- - -.. index:: NeXus basic motivation; default plot - -Any program whose aim is to identify plottable data should use the -following procedure: - - .. index:: dimension scale - .. index:: rank - -#. Open the first top level NeXus group with class ``NXentry``. -#. Open the first NeXus group with class ``NXdata``. -#. Loop through NeXus fields in this group searching for the item - with attribute ``signal="1"`` - indicating this field has the plottable data. -#. Check to see if this field has an attribute called - ``axes``. If so, the attribute value contains a colon (or comma) - delimited list (in the C-order of the data array) with the names - of the dimension scales - associated with the plottable data. And - then you can skip the next two steps. -#. If the ``axes`` - attribute is not defined, search for the one-dimensional NeXus - fields with attribute ``primary="1"``. -#. These are the dimension scales - to label the axes of each - dimension of the data. -#. Link each dimension scale - to the respective data dimension by - the ``axis`` attribute (``axis="1"``, - ``axis="2"``, ... up to the rank of the data). -#. If necessary, close the ``NXdata`` - group, open the next one and repeat steps 3 to 6. -#. If necessary, close the ``NXentry`` - group, open the next one and repeat steps 2 to 7. - -Consult the :ref:`NeXus API` -section, which describes the routines available to program these -operations. In the course of time, generic NeXus browsers will -provide this functionality automatically. - - -How can I specify reasonable axes for my data? ---------------------------------------------------------------------------- - -See the section: :ref:`NXdata-facilitates-TheDefaultPlot`. - -Why aren't ``NXsample`` and ``NXmonitor`` groups stored in the ``NXinstrument`` group? ------------------------------------------------------------------------------------------------- - -A NeXus file can contain a number of ``NXentry`` -groups, which may represent different scans in an experiment, or -sample and calibration runs, etc. In many cases, though by no means -all, the instrument has the same configuration so that it would be -possible to save space by storing the ``NXinstrument`` -group once and using multiple links in the remaining ``NXentry`` -groups. It is assumed that the sample and monitor information would -be more likely to change from run to run, and so should be stored -at the top level. - -Specifications are boring. Where can I find some good example data files? ---------------------------------------------------------------------------- - -There are a few checked into the :ref:`definitions repository`. -At the moment the selection is quite limited and not very representative. - -Can I use a NXDL specification to parse a NeXus data file? ---------------------------------------------------------------------------- - -This should be possible as there is nothing in the NeXus -specifications to prevent this but it is not implemented in NAPI. -You would need to implement it for yourself. You would be wise to -consult the algorithms in the Java version of -``NXvalidate`` -(see :ref:`NXvalidate-java`) for more details. - -Why do I need to specify the ``NAPItype``? --------------------------------------------- - -*My programming language does not need that information and -I don't care about C and colleagues. Can I leave it out?* - -.. index:: NAPI - -``NAPItype`` -is necessary. When implementing the NeXus-XML API we strived to -make this as general as HDF and reasonably efficient for medium -sized datasets. This is why we store arrays as a large bunch of -numbers in C-storage order. And we need the -``NAPItype`` -to figure out the dimensions of the dataset. - -.. index:: dimension; data set - -Do I have to use the ``NAPI`` subroutines? Can't I read (or write) the NeXus data files with my own routines? ------------------------------------------------------------------------------------------------------------------------------------------------------- - -You are not required to use the NAPI to write valid NeXus -data files. It is possible to avoid the NAPI to write and read -valid NeXus data files. But, the programmer who chooses this path -must have more understanding of how the NeXus HDF or XML data file -is written. Validation of data files written without the NAPI is -strongly encouraged. - -I'm using links to place data in two places. Which one should be the data and which one is the link? ------------------------------------------------------------------------------------------------------------------------------------------------------- - -.. COMMENT: say it clearly -.. COMMENT: answer the question -.. COMMENT: say it again another way - -NeXus uses HDF5 hard links. -Both places have pointers to the actual data. -That is the way hard links work in HDF5. -There is no need for a preference to either location. -NeXus defines a ``target`` attribute to label -one directory entry as the source of the data (in this, the -link *target*). This has value in -only a few situations such as when -converting the data from one format to another. By identifying -the original in place, duplicate copies of the data are not -converted. -In HDF, a hard link points to a data object. -A soft link points to a directory entry. -Since NeXus uses hard links, there is no need to distinguish -between two (or more) directory entries that point to the same data. - -.. index:: link diff --git a/_sphinx/source/volume1/index.rst b/_sphinx/source/volume1/index.rst deleted file mode 100755 index 76cbe1ae7..000000000 --- a/_sphinx/source/volume1/index.rst +++ /dev/null @@ -1,19 +0,0 @@ -.. $Id$ - -.. :title-reference:`NeXus User Manual` - -.. _NeXus User Manual: - -############################################################################## -NeXus: User Manual -############################################################################## - -Contents: - -.. toctree:: - :maxdepth: 2 - :numbered: - - introduction/index - design/index - faq diff --git a/_sphinx/source/volume1/introduction/NAPI.rst b/_sphinx/source/volume1/introduction/NAPI.rst deleted file mode 100755 index 8175186e4..000000000 --- a/_sphinx/source/volume1/introduction/NAPI.rst +++ /dev/null @@ -1,37 +0,0 @@ -.. $Id$ - -.. _Introduction-NAPI: - -===================================================================== -NAPI: The NeXus Application Programming Interface -===================================================================== - -.. index:: NAPI - -The NeXus API consists of routines to read and -write NeXus data files and -was written to shield (and hide) the complexity -of the HDF API from scientific programmers and -users of the NeXus Data Standard. - -Further documentation of the NeXus Application Programming Interface -(NAPI) for bindings to specific programming language can be obtained -from the NeXus development site. [#]_ - -For a more detailed description of the internal workings of NAPI -that is maintained (mostly) concurrent with code revisions, -see the NAPI chapter in Volume II of this documentation and also -`NeXusIntern.pdf `_ -in the NeXus code repository. [#]_ -Likely this is only interesting for experienced -programmers who wish to hack the NAPI. - -.. [#] http://download.nexusformat.org -.. [#] http://svn.nexusformat.org/code/trunk/doc/api/NeXusIntern.pdf - -.. toctree:: - - howto/write - howto/read - howto/browse - diff --git a/_sphinx/source/volume1/introduction/howto/browse.rst b/_sphinx/source/volume1/introduction/howto/browse.rst deleted file mode 100755 index 61cd93678..000000000 --- a/_sphinx/source/volume1/introduction/howto/browse.rst +++ /dev/null @@ -1,93 +0,0 @@ -.. $Id$ - -.. _Introduction-HowToBrowse: - -How do I browse a NeXus file? ---------------------------------------------------------------------------------- - -.. index:: file; browse -.. index:: utility; nxbrowse - -NeXus files can also be viewed by a command-line browser, -``NXbrowse``, which is included with the NeXus API (:ref:`Introduction-NAPI`). -The following is an example session of using ``nxbrowse`` -to view a data -file from the LRMECS spectrometer at IPNS. The following commands -are used in :ref:`ex.NXbrowse.lrmecs` in this session (see -the ``nxbrowse`` web page): - -.. _ex.NXbrowse.lrmecs: - -Using ``NXbrowse`` -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -.. code-block:: text - :linenos: - - %> nxbrowse lrcs3701.nxs - - NXBrowse 3.0.0. Copyright (C) 2000 R. Osborn, M. Koennecke, P. Klosowski - NeXus_version = 1.3.3 - file_name = lrcs3701.nxs - file_time = 2001-02-11 00:02:35-0600 - user = EAG/RO - NX> dir - NX Group : Histogram1 (NXentry) - NX Group : Histogram2 (NXentry) - NX> open Histogram1 - NX/Histogram1> dir - NX Data : title[44] (NX_CHAR) - NX Data : analysis[7] (NX_CHAR) - NX Data : start_time[24] (NX_CHAR) - NX Data : end_time[24] (NX_CHAR) - NX Data : run_number (NX_INT32) - NX Group : sample (NXsample) - NX Group : LRMECS (NXinstrument) - NX Group : monitor1 (NXmonitor) - NX Group : monitor2 (NXmonitor) - NX Group : data (NXdata) - NX/Histogram1> read title - title[44] (NX_CHAR) = MgB2 PDOS 43.37g 8K 120meV E0@240Hz T0@120Hz - NX/Histogram1> open data - NX/Histogram1/data> dir - NX Data : title[44] (NX_CHAR) - NX Data : data[148,750] (NX_INT32) - NX Data : time_of_flight[751] (NX_FLOAT32) - NX Data : polar_angle[148] (NX_FLOAT32) - NX/Histogram1/data> read time_of_flight - time_of_flight[751] (NX_FLOAT32) = [ 1900.000000 1902.000000 1904.000000 ...] - units = microseconds - long_name = Time-of-Flight [microseconds] - NX/Histogram1/data> read data - data[148,750] (NX_INT32) = [ 1 1 0 ...] - units = counts - signal = 1 - long_name = Neutron Counts - axes = polar_angle:time_of_flight - NX/Histogram1/data> close - NX/Histogram1> close - NX> quit - -.. index:: example; simple - -[line 1] - Start ``NXbrowse`` from the UNIX command - line and open file ``lrcs3701.nxs`` from - IPNS/LRMECS. -[line 8] - List the contents of the current group. -[line 11] - Open the NeXus group ``Histogram1``. -[line 23] - Print the contents of the NeXus data labelled ``title``. -[line 41] - Close the current group. -[line 43] - Quits ``NXbrowse``. - -The source code of ``NXbrowse`` [#]_ -provides an example of how to write a NeXus reader. -The test programs included in the NeXus API (:ref:`Introduction-NAPI`) -may also be useful to study. - -.. [#] https://svn.nexusformat.org/code/trunk/applications/NXbrowse/NXbrowse.c diff --git a/_sphinx/source/volume1/introduction/howto/read.rst b/_sphinx/source/volume1/introduction/howto/read.rst deleted file mode 100755 index 64654e222..000000000 --- a/_sphinx/source/volume1/introduction/howto/read.rst +++ /dev/null @@ -1,41 +0,0 @@ -.. $Id$ - -.. _Introduction-HowToRead: - -How do I read a NeXus file? ---------------------------------------------------------------------------------- - -.. index:: file; read -.. index:: NAPI -.. index:: rank - -Reading a NeXus file is almost identical to writing one. Obviously, it is not -necessary to call ``NXmakedata()`` -since the item already exists, but it -is necessary to call one of the query routines to find out the rank -and length of the data before allocating an array to store it. - -Here is part of a program to read the two-theta array from the file -created by :ref:`ex.simple.write` above. - -.. _ex.simple.read: - -Reading a simple NeXus file -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -.. index:: example; simple - -.. code-block:: text - :linenos: - - NXopen ('NXfile.nxs', NXACC_READ, &fileID); - NXopengroup (fileID, "Scan", "NXentry"); - NXopengroup (fileID, "data", "NXdata"); - NXopendata (fileID, "two_theta"); - NXgetinfo (fileID, &rank, dims, &datatype); - NXmalloc ((void **) &tth, rank, dims, datatype); - NXgetdata (fileID, tth); - NXclosedata (fileID); - NXclosegroup (fileID); - NXclosegroup (fileID); - NXclose (fileID); diff --git a/_sphinx/source/volume1/introduction/howto/write.rst b/_sphinx/source/volume1/introduction/howto/write.rst deleted file mode 100755 index 0f32996df..000000000 --- a/_sphinx/source/volume1/introduction/howto/write.rst +++ /dev/null @@ -1,117 +0,0 @@ -.. $Id$ - -.. _Introduction-HowToWrite: - -How do I write a NeXus file? ---------------------------------------------------------------------------------- - -.. index:: file; write -.. index:: NAPI - -The NeXus Application Program Interface (API) -provides a set of subroutines that make it easy to read and write -NeXus files. These subroutines are available in C, Fortran 77, Fortran 90, Java, -Python, C++, -and IDL. Access from other languages, such as Python, is anticipated in the near -future. It is also possible to read NeXus HDF files in a number of data analysis -tools, such as LAMP, ISAW, IgorPro, and Open GENIE. NeXus XML files can be read -by any program or library that supports XML. - -The API uses a very simple *state* -model to navigate through a NeXus file. -When you open a file, the API provides a file *handle*, -which then stores the -current location, i.e. which group and/or field is currently open. Read and -write operations then act on the currently open entity. -Following the :ref:`fig.simple-example`, -we walk through some parts of a typical NeXus program written in C. - -.. _ex.simple.write: - -Writing a simple NeXus file -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -.. index:: example; simple -.. code-block:: text - :linenos: - - #include "napi.h" - - int main() - { - NXhandle fileID; - NXopen ('NXfile.nxs', NXACC_CREATE, &fileID); - NXmakegroup (fileID, "Scan", "NXentry"); - NXopengroup (fileID, "Scan", "NXentry"); - NXmakegroup (fileID, "data", "NXdata"); - NXopengroup (fileID, "data", "NXdata"); - /* somehow, we already have arrays tth and counts, each length n*/ - NXmakedata (fileID, "two_theta", NX_FLOAT32, 1, &n); - NXopendata (fileID, "two_theta"); - NXputdata (fileID, tth); - NXputattr (fileID, "units", "degrees", 7, NX_CHAR); - NXclosedata (fileID); /* two_theta */, NX_INT32, 1, &n); - NXopendata (fileID, "counts"); - NXputdata (fileID, counts); - NXclosedata (fileID); /* counts */ - NXclosegroup (fileID); /* data */ - NXclosegroup (fileID); /* Scan */ - NXclose (&fileID); - return; - } - -[line 6] - Open the file ``NXfile.nxs`` with - *create* - access (implying write access). - NAPI returns a file identifier of type ``NXhandle``. - -[line 7] - Next, we create an - ``NXentry`` group to contain the scan using - ``NXmakegroup()`` and then - open it for access using ``NXopengroup()``. - -[line 9] - The plottable data - is contained within an ``NXdata`` group, which must - also be created and opened. - -.. index:: NeXus basic motivation; default plot - -[line 12] - To create a field, call ``NXmakedata()``, specifying the - data name, type (``NX_FLOAT32``), rank - (in this case, - ``1``), and length of the array - (``n``). Then, it can be opened for writing. - -.. index:: rank - -[line 14] - Write the data using ``NXputdata()``. - -[line 15] - With the field still open, we can also add some data attributes, - such as the data units, - which are specified as a character string (type ``NX_CHAR``) - that is 7 bytes long. - -.. index:: attributes; data -.. index:: units - -[line 16] - Then we close the field before opening another. - In fact, the API will do this automatically if you - attempt to open another field, but it is - better style to close it yourself. - -[line 17] - The remaining fields in this group are added in a similar - fashion. Note that the indentation whenever a new field or - group are opened is just intended to make the structure of - the NeXus file more transparent. - -[line 20] - Finally, close the groups (``NXdata`` and - ``NXentry``) before closing the file itself. diff --git a/_sphinx/source/volume1/introduction/index.rst b/_sphinx/source/volume1/introduction/index.rst deleted file mode 100755 index 64fc97bfa..000000000 --- a/_sphinx/source/volume1/introduction/index.rst +++ /dev/null @@ -1,39 +0,0 @@ -.. $Id$ - -.. _nexus-introduction: - -*************************************************************************** -NeXus Introduction -*************************************************************************** - -.. index:: NeXus basic motivation; unified format - -In recent years, a community of scientists and computer programmers working -in neutron and synchrotron facilities around the world came to the -conclusion that a common data format would fulfill a valuable function in -the scattering community. As instrumentation becomes more complex and data -visualization become more challenging, individual scientists, or even -institutions, have found it difficult to keep up with new developments. A -common data format makes it easier, both to exchange experimental results -and to exchange ideas about how to analyze them. It promotes greater -cooperation in software development and stimulates the design of more -sophisticated visualization tools. For additional background information see -:ref:`History`. - - *The programmers who produce intermediate files for - storing analyzed data should agree on simple interchange rules.* - -.. index:: rules - -This section is designed to give a brief introduction to NeXus, the data -format and tools that have been developed in response to these needs. It -explains what a modern data format such as NeXus is and how to write simple -programs to read and write NeXus files. - - -.. toctree:: - :maxdepth: 2 - - whatis/index - motivations/index - NAPI diff --git a/_sphinx/source/volume1/introduction/motivations/data-post-nexus.jpg b/_sphinx/source/volume1/introduction/motivations/data-post-nexus.jpg deleted file mode 100755 index 19d612ccc..000000000 Binary files a/_sphinx/source/volume1/introduction/motivations/data-post-nexus.jpg and /dev/null differ diff --git a/_sphinx/source/volume1/introduction/motivations/data-pre-nexus.jpg b/_sphinx/source/volume1/introduction/motivations/data-pre-nexus.jpg deleted file mode 100755 index 4d6eff59b..000000000 Binary files a/_sphinx/source/volume1/introduction/motivations/data-pre-nexus.jpg and /dev/null differ diff --git a/_sphinx/source/volume1/introduction/motivations/dictionary.rst b/_sphinx/source/volume1/introduction/motivations/dictionary.rst deleted file mode 100755 index f2e6ca4d9..000000000 --- a/_sphinx/source/volume1/introduction/motivations/dictionary.rst +++ /dev/null @@ -1,21 +0,0 @@ -.. $Id$ - -.. _DefinedDictionary: - -*************************************************************************** -A Defined Dictionary of Terms -*************************************************************************** - -.. index:: NeXus basic motivation; defined dictionary - -A necessary feature of a standard for the interchange of scientific data is -a *defined dictionary* (or *lexicography*) of terms. This dictionary -declares the expected spelling and meaning of terms when they are present so -that it is not necessary to search for all the variant forms of *energy* -when it is used to describe data (e.g., ``E``, ``e``, ``keV``, ``eV``, -``nrg``, ...). - -NeXus recognized that each scientific specialty has developed a unique -dictionary and needs to categorize data using those terms. The NeXus -Application Definitions provide the means to document the lexicography for -use in data files of that scientific specialty. diff --git a/_sphinx/source/volume1/introduction/motivations/index.rst b/_sphinx/source/volume1/introduction/motivations/index.rst deleted file mode 100755 index bc72b61a5..000000000 --- a/_sphinx/source/volume1/introduction/motivations/index.rst +++ /dev/null @@ -1,75 +0,0 @@ -.. $Id: introduction.rst 881 2011-09-12 01:47:48Z Pete Jemian $ - -.. _MotivationsForNeXus: - -*************************************************************************** -Motivations for the NeXus standard in the Scientific Community -*************************************************************************** - -.. - Today: - * Lots of different data formats - * Time wasted converting data - * Old formats no longer capable of delivering for new high throughput detectors - * Difficult to add additional data - * Often, for DA multiple different files needed - * Badly documented formats - Tomorrow, with NeXus: - * Single, efficient, platform independent data format - * All information in one file - * Self-describing - * Extendable - -By the early 1990s, several groups of scientists in the fields of neutron -and X-ray science had recognized a common and troublesome pattern in the -data acquired at various scientific instruments and user facilities. Each -of these instruments and facilities had a locally defined format for -recording experimental data. With lots of different formats, much of the -scientists' time was being wasted in the task of writing import readers -for processing and analysis programs. As is common, the exact information -to be documented from each instrument in a data file evolves, such as the -implementation of new high-throughput detectors. Many of these formats -lacked the generality to extend to the new data to be stored, thus another -new format was devised. In such environments, the documentation of each -generation of data format is often lacking. - -Three parallel developments have led to NeXus: - -#. June 1994: - Mark Koennecke (Paul Scherer Institute, Switzerland) made a - proposal using netCDF for the European neutron scattering - community while working at the ISIS pulsed neutron facility. - -#. August 1994: - Jon Tischler and Mitch Nelson (Oak Ridge National Laboratory, USA) - proposed an HDF-based format as a standard for data storage at the - Advanced Photon Source (Argonne National Laboratory, USA). - -#. October 1996: - Przemek Klosowski (National Institute of Standards and Technology, USA) - produced a first draft of the NeXus proposal drawing on ideas - from both sources. - -These scientists proposed methods to store data using a self-describing, -extensible format that was already in broad use in other scientific -disciplines. Their proposals formed the basis for the current design of -the NeXus standard which was developed at two workshops, SoftNeSS'95 (NIST -Sept. 1995) and SoftNeSS'96 (Argonne Oct. 1996), attended by -representatives of a range of neutron and x-ray facilities. - -.. _basic.motivations: - -Basic motivations for the NeXus standard ------------------------------------------------- - -.. index:: NeXus basic motivation - -The NeXus API was released in late 1997. -Basic motivations for this standard were: - -.. toctree:: - :maxdepth: 1 - - plotting - unified - dictionary diff --git a/_sphinx/source/volume1/introduction/motivations/plotting.rst b/_sphinx/source/volume1/introduction/motivations/plotting.rst deleted file mode 100755 index a8e4d29b6..000000000 --- a/_sphinx/source/volume1/introduction/motivations/plotting.rst +++ /dev/null @@ -1,19 +0,0 @@ -.. $Id$ - -.. _SimplePlotting: - -*************************************************************************** -Simple plotting -*************************************************************************** - -.. index:: NeXus basic motivation; default plot - -An important motivation for the design of NeXus was to simplify -the creation of a default plot view. While the best -representation of a set of observations will vary, depending on -various conditions, a good suggestion is often known *a priori*. -This suggestion is described in the ``NXdata`` element so that -any program that is used to browse NeXus data files can provide -a *best representation* without request for user input. - -.. TODO: this screams for an example, data and plot diff --git a/_sphinx/source/volume1/introduction/motivations/unified.rst b/_sphinx/source/volume1/introduction/motivations/unified.rst deleted file mode 100755 index a2c8f2dbe..000000000 --- a/_sphinx/source/volume1/introduction/motivations/unified.rst +++ /dev/null @@ -1,116 +0,0 @@ -.. $Id$ - -.. _UnifiedFormat: - -*************************************************************************** -A Unified Format for Reduction and Analysis -*************************************************************************** - -.. index:: NeXus basic motivation; unified format - -Another important motivation for NeXus, indeed the *raison d'etre*, was -the community need to analyze data from different user facilities. A -single data format that is in use at a variety of facilities would provide -a major benefit to the scientific community. This unified format should -be capable of describing any type of data from the scientific experiments, -at any step of the process from data acquisition to data reduction and -analysis. This unified format also needs to allow data to be written to -storage as efficiently as possible to enable use with high-speed data -acquisition. - -.. hit these points: - Portable, - self describing, - extendable, - public domain - -**Self-description**, combined with a reliance on a **multi-platform** -(and thereby **portable**) data storage format, are valued components of a -data storage format where the longevity of the data is expected to be -longer than the lifetime of the facility at which it is acquired. As the -name implies, self-description within data files is the practice where the -structure of the information contained within the file is evident from the -file itself. A multi-platform data storage format must faithfully -represent the data identically on a variety of computer systems, -regardless of the bit order or byte order or word size native to the -computer. - -The scientific community continues to grow the various types of data to be -expressed in data files. This practice is expected to continue as part of -the investigative process. To gain broad acceptance in the scientific user -community, any data storage format proposed as a standard would need to be -**extendable** and continue to provide a means to express the latest -notions of scientific data. - -The maintenance cost of common data structures meeting the motivations -above (self-describing, portable, and extendable) is not insurmountable -but is often well-beyond the research funding of individual members of the -muon, neutron, and X-ray science communities. Since it is these members -that drive the selection of a data storage format, it is necessary for the -user cost to be as minimal as possible. In this case, experience has shown -that the format must be in the **public-domain** for it to be commonly -accepted as a standard. A benefit of the public-domain aspect is that the -source code for the API is open and accessible, a point which has received -notable comment in the scientific literature. - -.. PRJ: For example, there was a letter to the editor of J Appl Cryst - in the late 1970s complaining about the increasingly-common - practice of withholding the source code. If we find the - reference, we should cite it here. - -.. index:: API - -More recently, NeXus has recognized that part of the scientific community -with a desire to write and record scientific data, has small data volumes -and a large aversion to the requirement of a complicated API necessary to -access data in binary files such as HDF. For such information, the NeXus -API has been extended by the addition of the eXtensible Markup Language -(XML) [#]_ as an alternative to HDF. XML is a text-based format that -supports compression and structured data and has broad usage in business -and e-commerce. While possibly complicated, XML files are human readable, -and tools for translation and extraction are plentiful. The API has -routines to read and write XML data and to convert between HDF and XML. - -.. [#] XML: http://www.w3.org/XML/. - There are many other descriptions of XML, - for example: http://en.wikipedia.org/wiki/XML - - -.. _CommonExchangeFormat: - -NeXus as a Common Data Exchange Format ---------------------------------------------- - -By the late 1980s, it had become common practice for a scientific -instrument or facility to define its own data format, often at the -convenience of the local computer system. Data from these facilities were -not easily interchanged due to various differences in computer systems and -the compression schemes of binary data. It was necessary to contact the -facility to obtain a description so that one could write an import routine -in software. Experience with facilities closing (and subsequent lack of -access to information describing the facility data format) revealed a -significant limitation with this common practice. Further, there existed -a *N * N* number of conversion routines necessary to convert data between -various formats. In the next figure, circles -represent different data file formats while arrows represent conversion -routines. Note that the red circle only maps to one other format. - -.. _fig.data-pre-nexus: - -.. figure:: data-pre-nexus.jpg - :width: 200 pt - :alt: example NeXus data file hierarchy - - *N* separate file formats - -One early idea has been for NeXus to become the common data exchange -format, and thereby reduce the number of data conversion routines from -*N * N* down to *2N*, as shown in the next figure. - -.. _fig.data-post-nexus: - -.. figure:: data-post-nexus.jpg - :width: 200 pt - :alt: example NeXus data file hierarchy - - *N* separate file formats joined by a common NeXus converter diff --git a/_sphinx/source/volume1/introduction/whatis/Hierarchy.png b/_sphinx/source/volume1/introduction/whatis/Hierarchy.png deleted file mode 100755 index 64e0367c0..000000000 Binary files a/_sphinx/source/volume1/introduction/whatis/Hierarchy.png and /dev/null differ diff --git a/_sphinx/source/volume1/introduction/whatis/NXinstrument.png b/_sphinx/source/volume1/introduction/whatis/NXinstrument.png deleted file mode 100755 index 2ff1dd054..000000000 Binary files a/_sphinx/source/volume1/introduction/whatis/NXinstrument.png and /dev/null differ diff --git a/_sphinx/source/volume1/introduction/whatis/Simple.png b/_sphinx/source/volume1/introduction/whatis/Simple.png deleted file mode 100755 index 5ab9407e5..000000000 Binary files a/_sphinx/source/volume1/introduction/whatis/Simple.png and /dev/null differ diff --git a/_sphinx/source/volume1/introduction/whatis/community.rst b/_sphinx/source/volume1/introduction/whatis/community.rst deleted file mode 100755 index 85af0bb05..000000000 --- a/_sphinx/source/volume1/introduction/whatis/community.rst +++ /dev/null @@ -1,28 +0,0 @@ -.. $Id$ - -.. _Scientific_Community: - -NeXus Scientific Community -------------------------------------------------------- - -NeXus began as a group of scientists with the goal of defining a common -data storage format to exchange experimental results and to exchange ideas -about how to analyze them. - -.. index:: scientific community -.. index:: wiki - -The NeXus Scientific Community provides the scientific data, advice, and -continued involvement with the NeXus standard. NeXus provides a forum for -the scientific community to exchange ideas in data storage through the -NeXus wiki. [#wiki]_ - -.. index:: NIAC - -The NeXus International Advisory Committee (see :ref:`NIAC-link`) -supervises the development and maintenance of the NeXus common data format -for neutron, x-ray, and muon science. The NIAC supervises a technical -committee to oversee the NeXus Application Programmer Interface (NAPI) and -the NeXus class definitions. - -.. [#wiki] http://www.nexusformat.org diff --git a/_sphinx/source/volume1/introduction/whatis/design.rst b/_sphinx/source/volume1/introduction/whatis/design.rst deleted file mode 100755 index a966a3a5c..000000000 --- a/_sphinx/source/volume1/introduction/whatis/design.rst +++ /dev/null @@ -1,245 +0,0 @@ -.. $Id$ - - -.. _Introduction-DesignPrinciples: - -A Set of Design Principles --------------------------- - -.. index:: NeXus; Design Principles - -NeXus data files contain four types of entity: -data groups, data fields, attributes, and links. -See :ref:`Design-Groups` for more details. - -1. :ref:`Design-Groups` - *Data groups* are like folders that can contain - a number of fields and/or other groups. - -.. index:: data objects; groups - -2. :ref:`Design-Fields` - *Data fields* - can be scalar values or multidimensional arrays of a - variety of sizes (1-byte, 2-byte, 4-byte, 8-byte) and types - (characters, integers, floats). In HDF, fields are - represented as HDF *Scientific Data Sets* - (also known as SDS). - -.. index:: data objects; fields -.. index:: HDF; Scientific Data Sets -.. see also - data objects, fields -.. index:: Scientific Data Sets -.. see also - data objects, fields -.. index:SDS -.. see also - data objects, fields - -3. :ref:`Design-Attributes` - Extra information required to - describe a particular group or field, - such as the data units, - can be stored as a data attribute. - -.. index:: units -.. index:: attributes; data -.. index:: data objects; attributes - -4. :ref:`Design-Links` - Links are used to reference the plottable data - from :ref:`NXdata` when the data is provided in - other groups such as :ref:`NXmonitor` or :ref:`NXdetector`. - -.. index:: NeXus basic motivation; default plot -.. index:: link - -In fact, a NeXus file can be viewed as a computer file system. Just as files -are stored in folders (or subdirectories) to make them easy to locate, so NeXus -fields are stored in groups. The group hierarchy -is designed to make it easy to navigate a NeXus file. - -.. index:: hierarchy - - -.. _Introduction-ExampleFile: - -Example of a NeXus File -^^^^^^^^^^^^^^^^^^^^^^^ - -.. index:: hierarchy; example NeXus data file -.. index:: example; NeXus data file - -The following diagram shows an example of a NeXus data file -represented as a tree structure. - -.. figure:: Hierarchy.png - :width: 300 pt - :alt: example NeXus data file hierarchy - - Example of a NeXus data file - -Note that each field is identified by a name, such as ``counts``, -but each group is identified both by a name and, after a colon as a -delimiter, the class type, e.g., ``monitor:NXmonitor``). -The class types, which all begin with ``NX``, -define the sort of fields that the group should contain, in this -case, counts from a beamline monitor. The hierarchical design, with data -items nested in groups, makes it easy to identify information if you are -browsing through a file. - - -.. _Introduction-ImportantClasses: - -Important Classes -^^^^^^^^^^^^^^^^^ - -Here are some of the important classes found in nearly all NeXus files. A -complete list can be found in the NeXus Design section (:ref:`NeXus-Design`). - -.. note: :ref:`NXentry` and :ref:`NXdata` - are the only two classes **required** in a valid NeXus data file. - -.. index:: classes; base class: NXentry - -:ref:`NXentry` - (**Required:**) - The top level of any NeXus file contains one or more - groups with the class ``NXentry``. - These contain all the data that is required to - describe an experimental run or scan. Each - ``NXentry`` typically contains a number of - groups describing sample information (class - ``NXsample``), instrument details (class - ``NXinstrument``), and monitor counts (class - ``NXmonitor``). - -.. index:: classes; base class: NXdata -.. index:: NeXus basic motivation; default plot - -:ref:`NXdata` - (**Required:**) - Each ``NXentry`` group contains one or more - groups with class ``NXdata``. - These groups contain the experimental results - in a self-contained way, i.e., it should be possible to - generate a sensible plot of the data - from the information - contained in each ``NXdata`` group. That means it - should contain the axis labels and titles as well as the - data. - -.. index:: classes; base class: NXsample - -:ref:`NXsample` - A ``NXentry`` group will often contain a group - with class ``NXsample``. - This group contains information pertaining to - the sample, such as its chemical composition, mass, and - environment variables (temperature, pressure, magnetic - field, etc.). - -.. index:: classes; base class: NXinstrument - -:ref:`NXinstrument` - There might also be a group with class - ``NXinstrument``. - This is designed to encapsulate all the - instrumental information that might be relevant to a - measurement, such as flight paths, collimations, chopper - frequencies, etc. - -.. figure:: NXinstrument.png - :width: 200 pt - :alt: example NeXus data file hierarchy - - NXinstrument excerpt - -Since an instrument can comprise several beamline components each -defined by several parameters, they are each specified by a separate group. -This hides the complexity from generic file browsers, but makes the -information available in an intuitively obvious way if it is required. - - -.. _Introduction-SimpleExample: - -Simple Data File Example -^^^^^^^^^^^^^^^^^^^^^^^^ - -NeXus data files do not need to be complicated. -In fact, the following diagram shows an extremely simple NeXus file -(in fact, the simple example shows the minimum information necessary -for a NeXus data file) that could be used to transfer -data between programs. (Later in this section, we show how to write and -read this simple example.) - -.. _fig.simple-example: - -.. figure:: Simple.png - :width: 250 pt - :alt: Simple Data File Example figure - - Simple Data File Example - -This illustrates the fact that the structure of NeXus files is -extremely flexible. It can accommodate very complex instrumental -information, if required, but it can also be used to store very simple data -sets. In the next example, a NeXus data file is shown as XML: - -.. _ex.verysimple.xml: - -``verysimple.xml``: A very simple NeXus Data file (in XML) -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -.. code-block:: xml - :linenos: - - - - - - - 1193 4474 - 53220 274310 - 515430 827880 - 1227100 1434640 - 1330280 1037070 - 598720 316460 - 56677 1000 - 1000 - - - 18.90940 18.90960 18.90980 18.91000 - 18.91020 18.91040 18.91060 18.91080 - 18.91100 18.91120 18.91140 18.91160 - 18.91180 18.91200 18.91220 - - - - - -.. index:: example; very simple - -NeXus files are easy to create. This example NeXus file was created using -a short Python program and NeXpy: - -.. _ex.verysimple.py: - -``verysimple.py``: Using NeXpy to write a very simple NeXus Data file (in HDF5) -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -.. literalinclude:: ../../../../../docbook/examples/verysimple.py - :language: python - :linenos: - :tab-width: 4 diff --git a/_sphinx/source/volume1/introduction/whatis/index.rst b/_sphinx/source/volume1/introduction/whatis/index.rst deleted file mode 100755 index a5b04266e..000000000 --- a/_sphinx/source/volume1/introduction/whatis/index.rst +++ /dev/null @@ -1,60 +0,0 @@ -.. $Id$ - -.. _WhatIsNeXus: - -===================================================================== -What is NeXus? -===================================================================== - -The NeXus data format has four components: - -.. index:: NeXus - -#. :ref:`Introduction-DesignPrinciples` - to help people understand what is in the data files. -#. :ref:`Introduction-DataStorageObjects` - (base classes and application definitions) to allow - the development of more portable analysis software. -#. :ref:`Introduction-SetOfSubroutines` - (utilities) to make it easy to read and write NeXus data files. -#. :ref:`Scientific_Community` - provides the scientific data, advice, and continued involvement - with the NeXus standard. NeXus provides a forum for the scientific - community to exchange ideas in data storage. - -.. description of the low-level formats was pulled from the intro in 2011 - In addition, NeXus relies on a set of low-level file formats to actually - store NeXus files on physical media. Each of these components are described - in more detail in :ref:`Fileformat`. - -.. index:: NAPI - -The NeXus Application-Programmer Interface (NAPI), which -provides the set of subroutines for reading and writing NeXus data files, -is described briefly in :ref:`Introduction-NAPI`. -(Further details are provided in the NAPI chapter of Volume II of this -documentation.) - -The principles guiding the design and implementation of the NeXus standard -are described in :ref:`NeXus-Design`. - -Base classes and applications, -which comprise the data storage objects used in NeXus data files, -are detailed in the *Class Definitions* chapter of -Volume II of this documentation. - -.. With this information, it should be possible to bypass the NAPI and - read & write NeXus data directly in the low-level file format. - -Additionally, a brief list describing the set of NeXus Utilities -available to browse, validate, translate, and visualise -NeXus data files is provided in :ref:`Utilities`. - - -.. toctree:: - :maxdepth: 2 - - design - objects - subroutines - community diff --git a/_sphinx/source/volume1/introduction/whatis/lowlevel.rst0 b/_sphinx/source/volume1/introduction/whatis/lowlevel.rst0 deleted file mode 100755 index 79739c61e..000000000 --- a/_sphinx/source/volume1/introduction/whatis/lowlevel.rst0 +++ /dev/null @@ -1,18 +0,0 @@ -.. $Id$ - included by introduction.rst - -A Set of Low-Level File Formats ---------------------------------------------------------------------- - -.. _LowLevelFormat: - -.. index:: NeXus; low-level file formats - -To actually store NeXus files on physical media, different low-level file -formats -are available, namely HDF4, HDF5, and XML. The NeXus code library may be -configured to support all of them, or any nonempty subset. Applications that -create NeXus files need to decide (or let the user decide) in which low-level -format data shall be stored. Generic data analysis applications should be able -to read any low-level format. More information is provided in -:ref:`Fileformat`. diff --git a/_sphinx/source/volume1/introduction/whatis/objects.rst b/_sphinx/source/volume1/introduction/whatis/objects.rst deleted file mode 100755 index 417417d1c..000000000 --- a/_sphinx/source/volume1/introduction/whatis/objects.rst +++ /dev/null @@ -1,85 +0,0 @@ -.. $Id$ - - -.. _Introduction-DataStorageObjects: - -A Set of Data Storage Objects ---------------------------------------------------------------------- -.. index:: instrument definitions - -If the design principles are followed, -it will be easy for anyone browsing a -NeXus file to understand what it contains, -without any prior information. -However, if you are writing specialized -visualization or analysis software, you will need to -know precisely what specific information is contained -in advance. For that reason, NeXus -provides a way of defining the format for -particular instrument types, -such as time-of-flight small angle neutron scattering. This requires -some agreement by the relevant communities, but enables the development of -much more portable software. - -The set of data storage objects is divided into three parts: -base classes, application definitions, and contributed definitions. -The base classes represent a set of components that define -the dictionary of all possible terms to be used with that component. -The application definitions specify the minimum required information to satisfy -a particular scientific or data analysis software interest. -The contributed definitions have been submitted by the scientific community -for incubation before they are adopted by the NIAC or for availability -to the community. - -These instrument definitions are formalized as XML files, using NXDL, -(as described in the NXDL chapter in Volume II of this documentation) -to specify the names of data fields, and other NeXus data objects. -The following is an example of such a file for -the simple NeXus file shown above. - -.. _ex.verysimple.nxdl.xml: - -``verysimple.nxdl.xml``: A very simple NeXus Definition Language (NXDL) file -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -.. code-block:: xml - :linenos: - - - - - - A very simple NeXus NXDL file - - - - - counts recorded by detector - - - rotation angle of detector arm - - - - - -.. index:: example; very simple - -.. (See *A complete example of writing and - reading a NeXus data file* for an example to write and read data - using the structure of :ref:`ex.verysimple.nxdl.xml`.) - -This chapter has several examples of writing and reading NeXus data files. -If you want to define the format of a particular type of NeXus file -for your own use, e.g. as the standard output from a program, you are encouraged -to *publish* the format using this XML format. -An example of how to do this is shown in the section titled -Creating a NXDL Specification (:ref:`NXDL_Tutorial-CreatingNxdlSpec`). diff --git a/_sphinx/source/volume1/introduction/whatis/subroutines.rst b/_sphinx/source/volume1/introduction/whatis/subroutines.rst deleted file mode 100755 index 330de5ea9..000000000 --- a/_sphinx/source/volume1/introduction/whatis/subroutines.rst +++ /dev/null @@ -1,46 +0,0 @@ -.. $Id$ - -.. _Introduction-SetOfSubroutines: - -A Set of Subroutines ---------------------------------------------------------------------- - -NeXus data files are high-level so the user only needs to -know how the data are referenced in the file but does not -need to be concerned where the data are stored in the file. Thus, the data -are most easily accessed using a subroutine library tuned to the -specifics of the data format. - -In the past, a data format was defined by a document -describing the precise location of every item in the data file, -either as row and column numbers in an ASCII file, or as record -and byte numbers in a binary file. It is the job of the subroutine -library to retrieve the data. This subroutine library is commonly -called an application-programmer interface or API. - -For example, in NeXus, a program to read in the wavelength of an experiment -would contain lines similar to the following: - -.. _ex.simple.c: - -Simple example of reading data using the NeXus API -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -.. index:: example; simple -.. code-block:: c - :linenos: - - NXopendata (fileID, "wavelength"); - NXgetdata (fileID, lambda); - NXclosedata (fileID); - -In this example, the program requests the value of the data that has -the label ``wavelength``, storing the result in the variable lambda. -``fileID`` is a file identifier that is provided by NeXus when the -file is opened. - -We shall provide a more complete example when we have -discussed the contents of the NeXus files. - -.. introduction: low-level routines was dropped form the manual in 2011 -.. .. include:: intro-lowlevel.inc diff --git a/_sphinx/source/volume2/NXDL/applications/NXarchive.rst b/_sphinx/source/volume2/NXDL/applications/NXarchive.rst deleted file mode 100644 index d79c0e6b0..000000000 --- a/_sphinx/source/volume2/NXDL/applications/NXarchive.rst +++ /dev/null @@ -1,107 +0,0 @@ -.. _NXarchive: - -######### -NXarchive -######### - -.. index:: ! . NXDL applications; NXarchive - -category: - applications - -NXDL source: - NXarchive - - (http://svn.nexusformat.org/definitions/trunk/applications/NXarchive.nxdl.xml) - -version: - 1.0b - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - :ref:`NXentry`, :ref:`NXinstrument`, :ref:`NXsample`, :ref:`NXsource`, :ref:`NXuser` - -documentation: - This is a definition for data to be archived by ICAT (see: - http://www.icatproject.org/), - - .. COMMENT: text from the icatproject.org site - the database (with supporting software) that provides an - interface to all ISIS experimental data and will provide - a mechanism to link all aspects of ISIS research from - proposal through to publication. - - - -.. rubric:: Basic Structure of **NXarchive** - -.. code-block:: text - :linenos: - - NXarchive (application definition, version 1.0b) - (overlays NXentry) - entry:NXentry - @index - collection_description:NX_CHAR - collection_identifier:NX_CHAR - collection_time:NX_FLOAT - definition:NX_CHAR - duration:NX_FLOAT - end_time:NX_DATE_TIME - entry_identifier:NX_CHAR - experiment_description:NX_CHAR - experiment_identifer:NX_CHAR - program:NX_CHAR - @version - release_date:NX_CHAR - revision:NX_CHAR - run_cycle:NX_CHAR - start_time:NX_DATE_TIME - title:NX_CHAR - instrument:NXinstrument - description:NX_CHAR - name:NX_CHAR - NXsource - name:NX_CHAR - probe:NX_CHAR - type:NX_CHAR - sample:NXsample - chemical_formula:NX_CHAR - description:NX_CHAR - electric_field:NX_FLOAT - magnetic_field:NX_FLOAT - name:NX_CHAR - preparation_date:NX_CHAR - pressure:NX_FLOAT - sample_id:NX_CHAR - situation:NX_CHAR - stress_field:NX_FLOAT - temperature:NX_FLOAT - type:NX_CHAR - user:NXuser - facility_user_id:NX_CHAR - name:NX_CHAR - role:NX_CHAR - - -.. rubric:: Symbols used in definition of **NXarchive** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXarchive** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ - diff --git a/_sphinx/source/volume2/NXDL/applications/NXdirecttof.rst b/_sphinx/source/volume2/NXDL/applications/NXdirecttof.rst deleted file mode 100644 index edd2b33df..000000000 --- a/_sphinx/source/volume2/NXDL/applications/NXdirecttof.rst +++ /dev/null @@ -1,65 +0,0 @@ -.. _NXdirecttof: - -########### -NXdirecttof -########### - -.. index:: ! . NXDL applications; NXdirecttof - -category: - applications - -NXDL source: - NXdirecttof - - (http://svn.nexusformat.org/definitions/trunk/applications/NXdirecttof.nxdl.xml) - -version: - 1.0b - -SVN Id: - $Id$ - -extends class: - :ref:`NXtofraw` - -other classes included: - :ref:`NXentry`, :ref:`NXfermi_chopper`, :ref:`NXinstrument` - -documentation: - This is a application definition for raw data from a direct geometry TOF spectrometer - - - -.. rubric:: Basic Structure of **NXdirecttof** - -.. code-block:: text - :linenos: - - NXdirecttof (application definition, version 1.0b) - (overlays NXentry) - entry:NXentry - definition:NX_CHAR - start_time:NX_DATE_TIME - title:NX_CHAR - NXinstrument - fermi_chopper:NXfermi_chopper - energy:NX_FLOAT - rotation_speed:NX_FLOAT - - -.. rubric:: Symbols used in definition of **NXdirecttof** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXdirecttof** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/applications/NXfluo.rst b/_sphinx/source/volume2/NXDL/applications/NXfluo.rst deleted file mode 100644 index 5848a16ee..000000000 --- a/_sphinx/source/volume2/NXDL/applications/NXfluo.rst +++ /dev/null @@ -1,81 +0,0 @@ -.. _NXfluo: - -###### -NXfluo -###### - -.. index:: ! . NXDL applications; NXfluo - -category: - applications - -NXDL source: - NXfluo - - (http://svn.nexusformat.org/definitions/trunk/applications/NXfluo.nxdl.xml) - -version: - 1.0 - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - :ref:`NXdata`, :ref:`NXdetector`, :ref:`NXentry`, :ref:`NXinstrument`, :ref:`NXmonitor`, :ref:`NXmonochromator`, :ref:`NXsample`, :ref:`NXsource` - -documentation: - This is an application definition for raw data from an X-ray fluorescence - experiment - - - -.. rubric:: Basic Structure of **NXfluo** - -.. code-block:: text - :linenos: - - NXfluo (application definition, version 1.0) - (overlays NXentry) - entry:NXentry - definition:NX_CHAR - start_time:NX_DATE_TIME - title:NX_CHAR - data:NXdata - data --> /entry/instrument/fluorecence/data - energy --> /entry/instrument/fluorecence/energy - NXinstrument - fluorescence:NXdetector - data:NX_INT[nenergy] - energy:NX_FLOAT[nenergy] - monochromator:NXmonochromator - wavelength:NX_FLOAT - NXsource - name:NX_CHAR - probe:NX_CHAR - type:NX_CHAR - NXmonitor - data:NX_INT - mode:NX_CHAR - preset:NX_FLOAT - NXsample - name:NX_CHAR - - -.. rubric:: Symbols used in definition of **NXfluo** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXfluo** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/applications/NXindirecttof.rst b/_sphinx/source/volume2/NXDL/applications/NXindirecttof.rst deleted file mode 100644 index 09cf70d05..000000000 --- a/_sphinx/source/volume2/NXDL/applications/NXindirecttof.rst +++ /dev/null @@ -1,66 +0,0 @@ -.. _NXindirecttof: - -############# -NXindirecttof -############# - -.. index:: ! . NXDL applications; NXindirecttof - -category: - applications - -NXDL source: - NXindirecttof - - (http://svn.nexusformat.org/definitions/trunk/applications/NXindirecttof.nxdl.xml) - -version: - 1.0b - -SVN Id: - $Id$ - -extends class: - :ref:`NXtofraw` - -other classes included: - :ref:`NXentry`, :ref:`NXinstrument`, :ref:`NXmonochromator` - -documentation: - This is a application definition for raw data from a direct geometry TOF spectrometer - - - -.. rubric:: Basic Structure of **NXindirecttof** - -.. code-block:: text - :linenos: - - NXindirecttof (application definition, version 1.0b) - (overlays NXentry) - entry:NXentry - definition:NX_CHAR - start_time:NX_DATE_TIME - title:NX_CHAR - NXinstrument - analyser:NXmonochromator - distance:NX_FLOAT[ndet] - energy:NX_FLOAT[nDet] - polar_angle:NX_FLOAT[ndet] - - -.. rubric:: Symbols used in definition of **NXindirecttof** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXindirecttof** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/applications/NXiqproc.rst b/_sphinx/source/volume2/NXDL/applications/NXiqproc.rst deleted file mode 100644 index 73568533d..000000000 --- a/_sphinx/source/volume2/NXDL/applications/NXiqproc.rst +++ /dev/null @@ -1,81 +0,0 @@ -.. _NXiqproc: - -######## -NXiqproc -######## - -.. index:: ! . NXDL applications; NXiqproc - -category: - applications - -NXDL source: - NXiqproc - - (http://svn.nexusformat.org/definitions/trunk/applications/NXiqproc.nxdl.xml) - -version: - 1.0b - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - :ref:`NXdata`, :ref:`NXentry`, :ref:`NXinstrument`, :ref:`NXparameters`, :ref:`NXprocess`, :ref:`NXsample`, :ref:`NXsource` - -documentation: - Actually this is a template from which to start an application definition. - - - -.. rubric:: Basic Structure of **NXiqproc** - -.. code-block:: text - :linenos: - - NXiqproc (application definition, version 1.0b) - (overlays NXentry) - NXentry - @entry - definition:NX_CHAR - title:NX_CHAR - NXdata - data:NX_INT[NE,NQX,NQY] - qx:NX_CHAR - qy:NX_CHAR - variable:NX_CHAR - @varied_variable - instrument:NXinstrument - name:NX_CHAR - NXsource - name:NX_CHAR - probe:NX_CHAR - type:NX_CHAR - reduction:NXprocess - program:NX_CHAR - version:NX_CHAR - input:NXparameters - filenames:NX_CHAR - output:NXparameters - NXsample - name:NX_CHAR - - -.. rubric:: Symbols used in definition of **NXiqproc** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXiqproc** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/applications/NXlauetof.rst b/_sphinx/source/volume2/NXDL/applications/NXlauetof.rst deleted file mode 100644 index 0ceb90545..000000000 --- a/_sphinx/source/volume2/NXDL/applications/NXlauetof.rst +++ /dev/null @@ -1,81 +0,0 @@ -.. _NXlauetof: - -######### -NXlauetof -######### - -.. index:: ! . NXDL applications; NXlauetof - -category: - applications - -NXDL source: - NXlauetof - - (http://svn.nexusformat.org/definitions/trunk/applications/NXlauetof.nxdl.xml) - -version: - 1.0b - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - :ref:`NXdata`, :ref:`NXdetector`, :ref:`NXentry`, :ref:`NXinstrument`, :ref:`NXmonitor`, :ref:`NXsample` - -documentation: - This is the application definition for a TOF laue diffractometer - - - -.. rubric:: Basic Structure of **NXlauetof** - -.. code-block:: text - :linenos: - - NXlauetof (application definition, version 1.0b) - (overlays NXentry) - entry:NXentry - definition:NX_CHAR - name:NXdata - data --> /NXentry/NXinstrument/NXdetector/data - time_of_flight --> /NXentry/NXinstrument/NXdetector/time_of_flight - instrument:NXinstrument - detector:NXdetector - azimuthal_angle:NX_FLOAT - data:NX_INT[number of x pixels,number of y pixels,nTOF] - @signal - distance:NX_FLOAT - polar_angle:NX_FLOAT - time_of_flight:NX_FLOAT[nTOF] - x_pixel_size:NX_FLOAT - y_pixel_size:NX_FLOAT - control:NXmonitor - data:NX_INT[nTOF] - mode:NX_CHAR - preset:NX_FLOAT - time_of_flight:NX_FLOAT[nTOF] - sample:NXsample - name:NX_CHAR - orientation_matrix:NX_FLOAT[3,3] - unit_cell:NX_FLOAT[6] - - -.. rubric:: Symbols used in definition of **NXlauetof** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXlauetof** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/applications/NXmonopd.rst b/_sphinx/source/volume2/NXDL/applications/NXmonopd.rst deleted file mode 100644 index 7496c6871..000000000 --- a/_sphinx/source/volume2/NXDL/applications/NXmonopd.rst +++ /dev/null @@ -1,84 +0,0 @@ -.. _NXmonopd: - -######## -NXmonopd -######## - -.. index:: ! . NXDL applications; NXmonopd - -category: - applications - -NXDL source: - NXmonopd - - (http://svn.nexusformat.org/definitions/trunk/applications/NXmonopd.nxdl.xml) - -version: - 1.0b - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - :ref:`NXcrystal`, :ref:`NXdata`, :ref:`NXdetector`, :ref:`NXentry`, :ref:`NXinstrument`, :ref:`NXmonitor`, :ref:`NXsample`, :ref:`NXsource` - -documentation: - Monochromatic Neutron and X-Ray Powder Diffraction. Instrument definition for a powder - diffractometer at a monochromatic neutron or X-ray beam. This is both suited for a powder - diffractometer with a single detector or a powder diffractometer with a position sensitive - detector. - - - -.. rubric:: Basic Structure of **NXmonopd** - -.. code-block:: text - :linenos: - - NXmonopd (application definition, version 1.0b) - (overlays NXentry) - entry:NXentry - definition:NX_CHAR - start_time:NX_DATE_TIME - title:NX_CHAR - NXdata - data --> /NXentry/NXinstrument/NXdetector/data - polar_angle --> /NXentry/NXinstrument/NXdetector/polar_angle - NXinstrument - NXcrystal - wavelength:NX_FLOAT[i] - NXdetector - data:NX_INT[ndet] - polar_angle:NX_FLOAT[ndet] - NXsource - name:NX_CHAR - probe:NX_CHAR - type:NX_CHAR - NXmonitor - integral:NX_FLOAT - mode:NX_CHAR - preset:NX_FLOAT - NXsample - name:NX_CHAR - rotation_angle:NX_FLOAT - - -.. rubric:: Symbols used in definition of **NXmonopd** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXmonopd** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/applications/NXrefscan.rst b/_sphinx/source/volume2/NXDL/applications/NXrefscan.rst deleted file mode 100644 index 815c2ee90..000000000 --- a/_sphinx/source/volume2/NXDL/applications/NXrefscan.rst +++ /dev/null @@ -1,85 +0,0 @@ -.. _NXrefscan: - -######### -NXrefscan -######### - -.. index:: ! . NXDL applications; NXrefscan - -category: - applications - -NXDL source: - NXrefscan - - (http://svn.nexusformat.org/definitions/trunk/applications/NXrefscan.nxdl.xml) - -version: - 1.0b - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - :ref:`NXdata`, :ref:`NXdetector`, :ref:`NXentry`, :ref:`NXinstrument`, :ref:`NXmonitor`, :ref:`NXmonochromator`, :ref:`NXsample`, :ref:`NXsource` - -documentation: - This is an application definition for a monochromatic scanning reflectometer. - It does not have the information to calculate the resolution - since it does not have any apertures. - - - -.. rubric:: Basic Structure of **NXrefscan** - -.. code-block:: text - :linenos: - - NXrefscan (application definition, version 1.0b) - (overlays NXentry) - entry:NXentry - definition:NX_CHAR - end_time:NX_DATE_TIME - start_time:NX_DATE_TIME - title:NX_CHAR - data:NXdata - data --> /NXentry/NXinstrument/NXdetector/data - polar_angle --> /NXentry/NXinstrument/NXdetector/polar_angle - rotation_angle --> /NXentry/NXsample/rotation_angle - instrument:NXinstrument - NXdetector - data:NX_INT[NP] - polar_angle:NX_FLOAT[NP] - monochromator:NXmonochromator - wavelength:NX_FLOAT - NXsource - name:NX_CHAR - probe:NX_CHAR - type:NX_CHAR - control:NXmonitor - data:NX_FLOAT[NP] - mode:NX_CHAR - preset:NX_FLOAT - sample:NXsample - name:NX_CHAR - rotation_angle:NX_FLOAT[NP] - - -.. rubric:: Symbols used in definition of **NXrefscan** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXrefscan** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/applications/NXreftof.rst b/_sphinx/source/volume2/NXDL/applications/NXreftof.rst deleted file mode 100644 index 661b08268..000000000 --- a/_sphinx/source/volume2/NXDL/applications/NXreftof.rst +++ /dev/null @@ -1,85 +0,0 @@ -.. _NXreftof: - -######## -NXreftof -######## - -.. index:: ! . NXDL applications; NXreftof - -category: - applications - -NXDL source: - NXreftof - - (http://svn.nexusformat.org/definitions/trunk/applications/NXreftof.nxdl.xml) - -version: - 1.0b - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - :ref:`NXdata`, :ref:`NXdetector`, :ref:`NXdisk_chopper`, :ref:`NXentry`, :ref:`NXinstrument`, :ref:`NXmonitor`, :ref:`NXsample` - -documentation: - This is an application definition for raw data from a TOF reflectometer. - - - -.. rubric:: Basic Structure of **NXreftof** - -.. code-block:: text - :linenos: - - NXreftof (application definition, version 1.0b) - (overlays NXentry) - entry:NXentry - definition:NX_CHAR - end_time:NX_DATE_TIME - start_time:NX_DATE_TIME - title:NX_CHAR - data:NXdata - data --> /NXentry/NXinstrument/NXdetector/data - time_binning --> /NXentry/NXinstrument/NXdetector/time_binning - instrument:NXinstrument - name:NX_CHAR - detector:NXdetector - data:NX_INT[xsize,ysize,nTOF] - distance:NX_FLOAT - polar_angle:NX_FLOAT - time_of_flight:NX_FLOAT[nTOF] - x_pixel_size:NX_FLOAT - y_pixel_size:NX_FLOAT - chopper:NXdisk_chopper - distance:NX_FLOAT - control:NXmonitor - data:NX_INT - integral:NX_INT - mode:NX_CHAR - preset:NX_FLOAT - time_of_flight:NX_FLOAT - sample:NXsample - name:NX_CHAR - rotation_angle:NX_FLOAT - - -.. rubric:: Symbols used in definition of **NXreftof** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXreftof** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/applications/NXsas.rst b/_sphinx/source/volume2/NXDL/applications/NXsas.rst deleted file mode 100644 index 3cc44e9ac..000000000 --- a/_sphinx/source/volume2/NXDL/applications/NXsas.rst +++ /dev/null @@ -1,99 +0,0 @@ -.. _NXsas: - -##### -NXsas -##### - -.. index:: ! . NXDL applications; NXsas - -category: - applications - -NXDL source: - NXsas - - (http://svn.nexusformat.org/definitions/trunk/applications/NXsas.nxdl.xml) - -version: - 1.0b - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - :ref:`NXcollimator`, :ref:`NXdata`, :ref:`NXdetector`, :ref:`NXentry`, :ref:`NXgeometry`, :ref:`NXinstrument`, :ref:`NXmonitor`, :ref:`NXmonochromator`, :ref:`NXsample`, :ref:`NXshape`, :ref:`NXsource` - -documentation: - This is an application definition for 2-D small angle scattering data collected with a - monochromatic beam and an area detector. It is meant to be suitable both for neutron SANS and - X-ray SAXS data. It covers all SAS techniques: SAS, WSAS, grazing incidence, GISAS - - - -.. rubric:: Basic Structure of **NXsas** - -.. code-block:: text - :linenos: - - NXsas (application definition, version 1.0b) - (overlays NXentry) - NXentry - @entry - definition:NX_CHAR - end_time:NX_DATE_TIME - start_time:NX_DATE_TIME - title:NX_CHAR - data:NXdata - data --> /NXentry/NXinstrument/NXdetector/data - instrument:NXinstrument - name:NX_CHAR - collimator:NXcollimator - geometry:NXgeometry - shape:NXshape - shape:NX_CHAR - size:NX_FLOAT - detector:NXdetector - aequatorial_angle:NX_FLOAT - azimuthal_angle:NX_FLOAT - beam_center_x:NX_FLOAT - beam_center_y:NX_FLOAT - data:NX_NUMBER[nXPixel,nYPixel] - distance:NX_FLOAT - polar_angle:NX_FLOAT - rotation_angle:NX_FLOAT - x_pixel_size:NX_FLOAT - y_pixel_size:NX_FLOAT - monochromator:NXmonochromator - wavelength:NX_FLOAT - wavelength_spread:NX_FLOAT - source:NXsource - name:NX_CHAR - probe:NX_CHAR - type:NX_CHAR - control:NXmonitor - integral:NX_FLOAT - mode:NX_CHAR - preset:NX_FLOAT - sample:NXsample - aequatorial_angle:NX_FLOAT - name:NX_CHAR - - -.. rubric:: Symbols used in definition of **NXsas** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXsas** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/applications/NXsastof.rst b/_sphinx/source/volume2/NXDL/applications/NXsastof.rst deleted file mode 100644 index 7adb244f1..000000000 --- a/_sphinx/source/volume2/NXDL/applications/NXsastof.rst +++ /dev/null @@ -1,97 +0,0 @@ -.. _NXsastof: - -######## -NXsastof -######## - -.. index:: ! . NXDL applications; NXsastof - -category: - applications - -NXDL source: - NXsastof - - (http://svn.nexusformat.org/definitions/trunk/applications/NXsastof.nxdl.xml) - -version: - 1.0b - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - :ref:`NXcollimator`, :ref:`NXdata`, :ref:`NXdetector`, :ref:`NXentry`, :ref:`NXgeometry`, :ref:`NXinstrument`, :ref:`NXmonitor`, :ref:`NXsample`, :ref:`NXshape`, :ref:`NXsource` - -documentation: - This is an application definition for small angle scattering using a 2D - detector in TOF mode. It strives to cover all the SAS techniques in the file again - - - -.. rubric:: Basic Structure of **NXsastof** - -.. code-block:: text - :linenos: - - NXsastof (application definition, version 1.0b) - (overlays NXentry) - NXentry - @entry - definition:NX_CHAR - start_time:NX_DATE_TIME - title:NX_CHAR - data:NXdata - data --> /NXentry/NXinstrument/NXdetector/data - time_of_flight --> /NXentry/NXinstrument/NXdetector/time_of_flight - instrument:NXinstrument - name:NX_CHAR - collimator:NXcollimator - geometry:NXgeometry - shape:NXshape - shape:NX_CHAR - size:NX_FLOAT - detector:NXdetector - aequatorial_angle:NX_FLOAT - azimuthal_angle:NX_FLOAT - beam_center_x:NX_FLOAT - beam_center_y:NX_FLOAT - data:NX_NUMBER[nXPixel,nYPixel,nTOF] - distance:NX_FLOAT - polar_angle:NX_FLOAT - rotation_angle:NX_FLOAT - time_of_flight:NX_FLOAT[nTOF] - x_pixel_size:NX_FLOAT - y_pixel_size:NX_FLOAT - source:NXsource - name:NX_CHAR - probe:NX_CHAR - type:NX_CHAR - control:NXmonitor - data:NX_INT[nTOF] - mode:NX_CHAR - preset:NX_FLOAT - time_of_flight:NX_FLOAT[nTOF] - sample:NXsample - aequatorial_angle:NX_FLOAT - name:NX_CHAR - - -.. rubric:: Symbols used in definition of **NXsastof** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXsastof** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/applications/NXscan.rst b/_sphinx/source/volume2/NXDL/applications/NXscan.rst deleted file mode 100644 index 489fb5abd..000000000 --- a/_sphinx/source/volume2/NXDL/applications/NXscan.rst +++ /dev/null @@ -1,96 +0,0 @@ -.. _NXscan: - -###### -NXscan -###### - -.. index:: ! . NXDL applications; NXscan - -category: - applications - -NXDL source: - NXscan - - (http://svn.nexusformat.org/definitions/trunk/applications/NXscan.nxdl.xml) - -version: - 1.0b - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - :ref:`NXdata`, :ref:`NXdetector`, :ref:`NXentry`, :ref:`NXinstrument`, :ref:`NXmonitor`, :ref:`NXsample` - -documentation: - Application definition for a generic scan instrument. This definition is more an - example then a stringent definition as the content of a given NeXus scan file needs to - differ for different types of scans. This example definition shows a scan like done - on a rotation camera: the sample is rotated and a detector image, the rotation angle - and a monitor value is stored at each step in the scan. In the following I use - the symbol NP as a placeholder for the number of scan points. These are the rules for - storing scan data in NeXus files which are implemented in this example: - - Each value varied throughout a scan is stored as an array of - length NP at its respective location within the NeXus hierarchy. - - For area detectors, NP is the first dimension, - example for a detector of 256x256: data[NP,256,256] - - The NXdata group contains links to all variables varied in the scan and the data. - This to give an equivalent to the more familiar classical tabular representation of scans. - - These rules exist for a reason: HDF allows the first dimension of a data set to be - unlimited. This means the data can be appended too. Thus a NeXus file built according - to the rules given above can be used in the following way: - - At the start of a scan, write all the static information. - - At each scan point, append new data from varied variables - and the detector to the file. - - - -.. rubric:: Basic Structure of **NXscan** - -.. code-block:: text - :linenos: - - NXscan (application definition, version 1.0b) - (overlays NXentry) - NXentry - definition:NX_CHAR - end_time:NX_DATE_TIME - start_time:NX_DATE_TIME - title:NX_CHAR - NXdata - data --> /NXentry/NXinstrument/NXdetector/data - rotation_angle --> /NXentry/NXsample/rotation_angle - NXinstrument - NXdetector - data:NX_INT[NP,xdim,ydim] - NXmonitor - data:NX_INT[NP] - NXsample - rotation_angle:NX_FLOAT[NP] - - -.. rubric:: Symbols used in definition of **NXscan** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXscan** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/applications/NXspe.rst b/_sphinx/source/volume2/NXDL/applications/NXspe.rst deleted file mode 100644 index e213ad06b..000000000 --- a/_sphinx/source/volume2/NXDL/applications/NXspe.rst +++ /dev/null @@ -1,82 +0,0 @@ -.. _NXspe: - -##### -NXspe -##### - -.. index:: ! . NXDL applications; NXspe - -category: - applications - -NXDL source: - NXspe - - (http://svn.nexusformat.org/definitions/trunk/applications/NXspe.nxdl.xml) - -version: - 1.0 - -SVN Id: - none - -extends class: - :ref:`NXobject` - -other classes included: - :ref:`NXcollection`, :ref:`NXdata`, :ref:`NXentry`, :ref:`NXfermi_chopper`, :ref:`NXinstrument`, :ref:`NXsample` - -documentation: - NXSPE Inelastic Format. Application definition for NXSPE file format. - - - -.. rubric:: Basic Structure of **NXspe** - -.. code-block:: text - :linenos: - - NXspe (application definition, version 1.0) - (overlays NXentry) - NXentry - definition:NX_CHAR - @version - program_name:NX_CHAR - NXSPE_info:NXcollection - fixed_energy:NX_FLOAT - ki_over_kf_scaling:NX_BOOLEAN - psi:NX_FLOAT - data:NXdata - azimuthal:NX_FLOAT - azimuthal_width:NX_FLOAT - data:NX_NUMBER - distance:NX_FLOAT - energy:NX_FLOAT - error:NX_NUMBER - polar:NX_FLOAT - polar_width:NX_FLOAT - NXinstrument - name:NX_CHAR - NXfermi_chopper - energy:NX_NUMBER - NXsample - rotation_angle:NX_NUMBER - seblock:NX_CHAR - temperature:NX_NUMBER - - -.. rubric:: Symbols used in definition of **NXspe** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXspe** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/applications/NXsqom.rst b/_sphinx/source/volume2/NXDL/applications/NXsqom.rst deleted file mode 100644 index 0840e5c18..000000000 --- a/_sphinx/source/volume2/NXDL/applications/NXsqom.rst +++ /dev/null @@ -1,84 +0,0 @@ -.. _NXsqom: - -###### -NXsqom -###### - -.. index:: ! . NXDL applications; NXsqom - -category: - applications - -NXDL source: - NXsqom - - (http://svn.nexusformat.org/definitions/trunk/applications/NXsqom.nxdl.xml) - -version: - 1.0b - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - :ref:`NXdata`, :ref:`NXentry`, :ref:`NXinstrument`, :ref:`NXparameters`, :ref:`NXprocess`, :ref:`NXsample`, :ref:`NXsource` - -documentation: - This is the application definition for S(Q,OM) processed data. As this kind of data is in - general not on a rectangular grid after data reduction, it is stored as Q,E positions plus their - intensity, table like. It is the task of a possible visualisation program to regrid this data in - a sensible way. - - - -.. rubric:: Basic Structure of **NXsqom** - -.. code-block:: text - :linenos: - - NXsqom (application definition, version 1.0b) - (overlays NXentry) - NXentry - @entry - definition:NX_CHAR - title:NX_CHAR - NXdata - data:NX_INT[NP] - en:NX_FLOAT[NP] - qx:NX_CHAR - qy:NX_CHAR - qz:NX_CHAR - instrument:NXinstrument - name:NX_CHAR - NXsource - name:NX_CHAR - probe:NX_CHAR - type:NX_CHAR - reduction:NXprocess - program:NX_CHAR - version:NX_CHAR - input:NXparameters - filenames:NX_CHAR - output:NXparameters - NXsample - name:NX_CHAR - - -.. rubric:: Symbols used in definition of **NXsqom** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXsqom** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/applications/NXtas.rst b/_sphinx/source/volume2/NXDL/applications/NXtas.rst deleted file mode 100644 index f4087d52e..000000000 --- a/_sphinx/source/volume2/NXDL/applications/NXtas.rst +++ /dev/null @@ -1,100 +0,0 @@ -.. _NXtas: - -##### -NXtas -##### - -.. index:: ! . NXDL applications; NXtas - -category: - applications - -NXDL source: - NXtas - - (http://svn.nexusformat.org/definitions/trunk/applications/NXtas.nxdl.xml) - -version: - 1.0b - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - :ref:`NXcrystal`, :ref:`NXdata`, :ref:`NXdetector`, :ref:`NXentry`, :ref:`NXinstrument`, :ref:`NXmonitor`, :ref:`NXsample`, :ref:`NXsource` - -documentation: - This is an application definition for a triple axis spectrometer. It is for the trademark - scan of the TAS, the Q-E scan. For your alignment scans use the rules in NXscan. - - - -.. rubric:: Basic Structure of **NXtas** - -.. code-block:: text - :linenos: - - NXtas (application definition, version 1.0b) - (overlays NXentry) - entry:NXentry - definition:NX_CHAR - start_time:NX_DATE_TIME - title:NX_CHAR - NXdata - data --> /NXentry/NXinstrument/NXdetector/data - ef --> /NXentry/NXinstrument/analyzer:NXcrystal/ef - ei --> /NXentry/NXinstrument/monochromator:NXcrystal/ei - en --> /NXentry/NXsample/en - qh --> /NXentry/NXsample/qh - qk --> /NXentry/NXsample/qk - ql --> /NXentry/NXsample/ql - NXinstrument - monochromator:NXcrystal - ei:NX_FLOAT[np] - rotation_angle:NX_FLOAT[np] - analyser:NXcrystal - ef:NX_FLOAT[np] - polar_angle:NX_FLOAT[np] - rotation_angle:NX_FLOAT[np] - NXdetector - data:NX_INT[np] - polar_angle:NX_FLOAT[np] - NXsource - name:NX_CHAR - probe:NX_CHAR - NXmonitor - data:NX_FLOAT[np] - mode:NX_CHAR - preset:NX_FLOAT - NXsample - en:NX_FLOAT[np] - name:NX_CHAR - orientation_matrix:NX_FLOAT[9] - polar_angle:NX_FLOAT[np] - qh:NX_FLOAT[np] - qk:NX_FLOAT[np] - ql:NX_FLOAT[np] - rotation_angle:NX_FLOAT[np] - sgl:NX_FLOAT[np] - sgu:NX_FLOAT[np] - unit_cell:NX_FLOAT[6] - - -.. rubric:: Symbols used in definition of **NXtas** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXtas** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/applications/NXtofnpd.rst b/_sphinx/source/volume2/NXDL/applications/NXtofnpd.rst deleted file mode 100644 index cde697a74..000000000 --- a/_sphinx/source/volume2/NXDL/applications/NXtofnpd.rst +++ /dev/null @@ -1,84 +0,0 @@ -.. _NXtofnpd: - -######## -NXtofnpd -######## - -.. index:: ! . NXDL applications; NXtofnpd - -category: - applications - -NXDL source: - NXtofnpd - - (http://svn.nexusformat.org/definitions/trunk/applications/NXtofnpd.nxdl.xml) - -version: - 1.0b - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - :ref:`NXdata`, :ref:`NXdetector`, :ref:`NXentry`, :ref:`NXinstrument`, :ref:`NXmonitor`, :ref:`NXsample`, :ref:`NXuser` - -documentation: - This is a application definition for raw data from a TOF neutron powder diffractometer - - - -.. rubric:: Basic Structure of **NXtofnpd** - -.. code-block:: text - :linenos: - - NXtofnpd (application definition, version 1.0b) - (overlays NXentry) - entry:NXentry - definition:NX_CHAR - pre_sample_flightpath:NX_FLOAT - start_time:NX_DATE_TIME - title:NX_CHAR - data:NXdata - data --> /NXentry/NXinstrument/NXdetector/data - detector_number --> /NXentry/NXinstrument/NXdetector/detector_number - time_of_flight --> /NXentry/NXinstrument/NXdetector/time_of_flight - NXinstrument - detector:NXdetector - azimuthal_angle:NX_FLOAT[ndet] - data:NX_INT[ndet,ntimechan] - detector_number:NX_INT[ndet] - distance:NX_FLOAT[ndet] - polar_angle:NX_FLOAT[ndet] - time_of_flight:NX_FLOAT[ntimechan] - NXmonitor - data:NX_INT[ntimechan] - distance:NX_FLOAT - mode:NX_CHAR - preset:NX_FLOAT - time_of_flight:NX_FLOAT[ntimechan] - NXsample - name:NX_CHAR - user:NXuser - name:NX_CHAR - - -.. rubric:: Symbols used in definition of **NXtofnpd** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXtofnpd** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/applications/NXtofraw.rst b/_sphinx/source/volume2/NXDL/applications/NXtofraw.rst deleted file mode 100644 index 1c5f30d5a..000000000 --- a/_sphinx/source/volume2/NXDL/applications/NXtofraw.rst +++ /dev/null @@ -1,88 +0,0 @@ -.. _NXtofraw: - -######## -NXtofraw -######## - -.. index:: ! . NXDL applications; NXtofraw - -category: - applications - -NXDL source: - NXtofraw - - (http://svn.nexusformat.org/definitions/trunk/applications/NXtofraw.nxdl.xml) - -version: - 1.0b - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - :ref:`NXdata`, :ref:`NXdetector`, :ref:`NXentry`, :ref:`NXinstrument`, :ref:`NXmonitor`, :ref:`NXsample`, :ref:`NXuser` - -documentation: - This is an application definition for raw data from a generic TOF instrument - - - -.. rubric:: Basic Structure of **NXtofraw** - -.. code-block:: text - :linenos: - - NXtofraw (application definition, version 1.0b) - (overlays NXentry) - entry:NXentry - definition:NX_CHAR - duration:NX_FLOAT - pre_sample_flightpath:NX_FLOAT - run_number:NX_INT - start_time:NX_DATE_TIME - title:NX_CHAR - data:NXdata - data --> /NXentry/NXinstrument/NXdetector/data - detector_number --> /NXentry/NXinstrument/NXdetector/detector_number - time_of_flight --> /NXentry/NXinstrument/NXdetector/time_of_flight - instrument:NXinstrument - detector:NXdetector - azimuthal_angle:NX_FLOAT[ndet] - data:NX_INT[ndet,ntimechan] - detector_number:NX_INT[ndet] - distance:NX_FLOAT[ndet] - polar_angle:NX_FLOAT[ndet] - time_of_flight:NX_FLOAT[ntimechan] - NXmonitor - data:NX_INT[ntimechan] - distance:NX_FLOAT - integral_counts:NX_INT - mode:NX_CHAR - preset:NX_FLOAT - time_of_flight:NX_FLOAT[ntimechan] - NXsample - name:NX_CHAR - nature:NX_CHAR - user:NXuser - name:NX_CHAR - - -.. rubric:: Symbols used in definition of **NXtofraw** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXtofraw** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/applications/NXtofsingle.rst b/_sphinx/source/volume2/NXDL/applications/NXtofsingle.rst deleted file mode 100644 index 91a64da7b..000000000 --- a/_sphinx/source/volume2/NXDL/applications/NXtofsingle.rst +++ /dev/null @@ -1,85 +0,0 @@ -.. _NXtofsingle: - -########### -NXtofsingle -########### - -.. index:: ! . NXDL applications; NXtofsingle - -category: - applications - -NXDL source: - NXtofsingle - - (http://svn.nexusformat.org/definitions/trunk/applications/NXtofsingle.nxdl.xml) - -version: - 1.0b - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - :ref:`NXdata`, :ref:`NXdetector`, :ref:`NXentry`, :ref:`NXinstrument`, :ref:`NXmonitor`, :ref:`NXsample`, :ref:`NXuser` - -documentation: - This is a application definition for raw data from a generic TOF instrument - - - -.. rubric:: Basic Structure of **NXtofsingle** - -.. code-block:: text - :linenos: - - NXtofsingle (application definition, version 1.0b) - (overlays NXentry) - entry:NXentry - definition:NX_CHAR - duration:NX_FLOAT - pre_sample_flightpath:NX_FLOAT - start_time:NX_DATE_TIME - title:NX_CHAR - data:NXdata - data --> /NXentry/NXinstrument/NXdetector/data - detector_number --> /NXentry/NXinstrument/NXdetector/detector_number - time_of_flight --> /NXentry/NXinstrument/NXdetector/time_of_flight - NXinstrument - detector:NXdetector - azimuthal_angle:NX_FLOAT[ndet] - data:NX_INT[xsize,ysize,ntimechan] - distance:NX_FLOAT[1] - polar_angle:NX_FLOAT[ndet] - time_of_flight:NX_FLOAT[ntimechan] - NXmonitor - data:NX_INT[ntimechan] - distance:NX_FLOAT - mode:NX_CHAR - preset:NX_FLOAT - time_of_flight:NX_FLOAT[ntimechan] - NXsample - name:NX_CHAR - nature:NX_CHAR - user:NXuser - name:NX_CHAR - - -.. rubric:: Symbols used in definition of **NXtofsingle** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXtofsingle** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/applications/NXtomo.rst b/_sphinx/source/volume2/NXDL/applications/NXtomo.rst deleted file mode 100644 index 927cf1850..000000000 --- a/_sphinx/source/volume2/NXDL/applications/NXtomo.rst +++ /dev/null @@ -1,105 +0,0 @@ -.. _NXtomo: - -###### -NXtomo -###### - -.. index:: ! . NXDL applications; NXtomo - -category: - applications - -NXDL source: - NXtomo - - (http://svn.nexusformat.org/definitions/trunk/applications/NXtomo.nxdl.xml) - -version: - 1.0b - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - :ref:`NXdata`, :ref:`NXdetector`, :ref:`NXentry`, :ref:`NXinstrument`, :ref:`NXmonitor`, :ref:`NXsample`, :ref:`NXsource` - -documentation: - This is the application definition for x-ray or neutron tomography raw data. In tomography first - some dark field images are measured, some bright field images and, of course the sample. In order - to properly sort the order of the images taken, a sequence number is stored with each image. - - - -.. rubric:: Basic Structure of **NXtomo** - -.. code-block:: text - :linenos: - - NXtomo (application definition, version 1.0b) - (overlays NXentry) - entry:NXentry - definition:NX_CHAR - end_time:NX_DATE_TIME - start_time:NX_DATE_TIME - title:NX_CHAR - data:NXdata - data --> /NXentry/NXinstrument/data:NXdetector/data - rotation_angle --> /NXentry/NXsample/rotation_angle - instrument:NXinstrument - bright_field:NXdetector - data:NX_INT[nBrightFrames,xsize,ysize] - sequence_number:NX_INT[nBrightFrames] - dark_field:NXdetector - data:NX_INT[nDarkFrames,xsize,ysize] - sequence_number:NX_INT[nDarkFrames] - sample:NXdetector - data:NX_INT[nSampleFrames,xsize,ysize] - distance:NX_FLOAT - sequence_number:NX_INT[nSampleFrames] - x_pixel_size:NX_FLOAT - y_pixel_size:NX_FLOAT - NXsource - name:NX_CHAR - probe:NX_CHAR - type:NX_CHAR - control:NXmonitor - data:NX_FLOAT[nDarkFrames + nBrightFrames + nSampleFrame] - sample:NXsample - name:NX_CHAR - rotation_angle:NX_FLOAT[nSampleFrames] - x_translation:NX_FLOAT[nSampleFrames] - y_translation:NX_FLOAT[nSampleFrames] - z_translation:NX_FLOAT[nSampleFrames] - - -.. rubric:: Symbols used in definition of **NXtomo** - -These symbols will be used below to coordinate datasets with the same shape. - -+-------------------+---------------------------------+ -| Symbol | Description | -+===================+=================================+ -| ``nBrightFrames`` | number of bright frames | -+-------------------+---------------------------------+ -| ``nDarkFrames`` | number of dark frames | -+-------------------+---------------------------------+ -| ``nSampleFrames`` | number of image (sample) frames | -+-------------------+---------------------------------+ -| ``xsize`` | number of pixels in X direction | -+-------------------+---------------------------------+ -| ``ysize`` | number of pixels in Y direction | -+-------------------+---------------------------------+ - - - - -.. rubric:: Comprehensive Structure of **NXtomo** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/applications/NXtomophase.rst b/_sphinx/source/volume2/NXDL/applications/NXtomophase.rst deleted file mode 100644 index a361c6c15..000000000 --- a/_sphinx/source/volume2/NXDL/applications/NXtomophase.rst +++ /dev/null @@ -1,107 +0,0 @@ -.. _NXtomophase: - -########### -NXtomophase -########### - -.. index:: ! . NXDL applications; NXtomophase - -category: - applications - -NXDL source: - NXtomophase - - (http://svn.nexusformat.org/definitions/trunk/applications/NXtomophase.nxdl.xml) - -version: - 1.0b - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - :ref:`NXdata`, :ref:`NXdetector`, :ref:`NXentry`, :ref:`NXinstrument`, :ref:`NXmonitor`, :ref:`NXsample`, :ref:`NXsource` - -documentation: - This is the application definition for x-ray or neutron tomography raw data with phase contrast variation at each point. In tomography first - some dark field images are measured, some bright field images and, of course the sample. In order - to properly sort the order of the images taken, a sequence number is stored with each image. - - - -.. rubric:: Basic Structure of **NXtomophase** - -.. code-block:: text - :linenos: - - NXtomophase (application definition, version 1.0b) - (overlays NXentry) - entry:NXentry - definition:NX_CHAR - end_time:NX_DATE_TIME - start_time:NX_DATE_TIME - title:NX_CHAR - data:NXdata - data --> /NXentry/NXinstrument/sample:NXdetector/data - rotation_angle --> /NXentry/NXsample/rotation_angle - instrument:NXinstrument - bright_field:NXdetector - data:NX_INT[nBrightFrames,xsize,ysize] - sequence_number:NX_INT[nBrightFrames] - dark_field:NXdetector - data:NX_INT[nDarkFrames,xsize,ysize] - sequence_number:NX_INT[nDarkFrames] - sample:NXdetector - data:NX_INT[nSampleFrames,nPhase,xsize,ysize] - distance:NX_FLOAT - sequence_number:NX_INT[nSampleFrames,nPhase] - x_pixel_size:NX_FLOAT - y_pixel_size:NX_FLOAT - NXsource - name:NX_CHAR - probe:NX_CHAR - type:NX_CHAR - control:NXmonitor - integral:NX_FLOAT[nDarkFrames + nBrightFrames + nSampleFrame] - sample:NXsample - name:NX_CHAR - rotation_angle:NX_FLOAT[nSampleFrames] - x_translation:NX_FLOAT[nSampleFrames] - y_translation:NX_FLOAT[nSampleFrames] - z_translation:NX_FLOAT[nSampleFrames] - - -.. rubric:: Symbols used in definition of **NXtomophase** - -These symbols will be used below to coordinate datasets with the same shape. - -+-------------------+---------------------------------+ -| Symbol | Description | -+===================+=================================+ -| ``nBrightFrames`` | number of bright frames | -+-------------------+---------------------------------+ -| ``nDarkFrames`` | number of dark frames | -+-------------------+---------------------------------+ -| ``nSampleFrames`` | number of image (sample) frames | -+-------------------+---------------------------------+ -| ``nPhase`` | number of phase settings | -+-------------------+---------------------------------+ -| ``xsize`` | number of pixels in X direction | -+-------------------+---------------------------------+ -| ``ysize`` | number of pixels in Y direction | -+-------------------+---------------------------------+ - - - - -.. rubric:: Comprehensive Structure of **NXtomophase** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/applications/NXtomoproc.rst b/_sphinx/source/volume2/NXDL/applications/NXtomoproc.rst deleted file mode 100644 index 5b7c678d6..000000000 --- a/_sphinx/source/volume2/NXDL/applications/NXtomoproc.rst +++ /dev/null @@ -1,90 +0,0 @@ -.. _NXtomoproc: - -########## -NXtomoproc -########## - -.. index:: ! . NXDL applications; NXtomoproc - -category: - applications - -NXDL source: - NXtomoproc - - (http://svn.nexusformat.org/definitions/trunk/applications/NXtomoproc.nxdl.xml) - -version: - 1.0b - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - :ref:`NXdata`, :ref:`NXentry`, :ref:`NXinstrument`, :ref:`NXparameters`, :ref:`NXprocess`, :ref:`NXsample`, :ref:`NXsource` - -documentation: - This is an application definition for the final result of a tomography experiment: a 3D construction of some volume of physical properties. - - - -.. rubric:: Basic Structure of **NXtomoproc** - -.. code-block:: text - :linenos: - - NXtomoproc (application definition, version 1.0b) - (overlays NXentry) - entry:NXentry - definition:NX_CHAR - title:NX_CHAR - data:NXdata - data:NX_INT[nx,nx,nz] - @transform - @offset - @scaling - x:NX_FLOAT[nx] - y:NX_FLOAT[ny] - z:NX_FLOAT[nz] - NXinstrument - NXsource - name:NX_CHAR - probe:NX_CHAR - type:NX_CHAR - reconstruction:NXprocess - date:NX_DATE_TIME - program:NX_CHAR - version:NX_CHAR - parameters:NXparameters - raw_file:NX_CHAR - NXsample - name:NX_CHAR - - -.. rubric:: Symbols used in definition of **NXtomoproc** - -These symbols will be used below to coordinate datasets with the same shape. - -+--------+---------------------------------+ -| Symbol | Description | -+========+=================================+ -| ``nx`` | number of voxels in X direction | -+--------+---------------------------------+ -| ``ny`` | number of voxels in Y direction | -+--------+---------------------------------+ -| ``nz`` | number of voxels in Z direction | -+--------+---------------------------------+ - - - - -.. rubric:: Comprehensive Structure of **NXtomoproc** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/applications/NXxas.rst b/_sphinx/source/volume2/NXDL/applications/NXxas.rst deleted file mode 100644 index 7f80c23b9..000000000 --- a/_sphinx/source/volume2/NXDL/applications/NXxas.rst +++ /dev/null @@ -1,84 +0,0 @@ -.. _NXxas: - -##### -NXxas -##### - -.. index:: ! . NXDL applications; NXxas - -category: - applications - -NXDL source: - NXxas - - (http://svn.nexusformat.org/definitions/trunk/applications/NXxas.nxdl.xml) - -version: - 1.0 - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - :ref:`NXdata`, :ref:`NXdetector`, :ref:`NXentry`, :ref:`NXinstrument`, :ref:`NXmonitor`, :ref:`NXmonochromator`, :ref:`NXsample`, :ref:`NXsource` - -documentation: - This is an application definition for raw data from an X-ray absorption - spectroscopy experiment. This is essentially a scan on energy versus incoming/ - absorbed beam - - - -.. rubric:: Basic Structure of **NXxas** - -.. code-block:: text - :linenos: - - NXxas (application definition, version 1.0) - (overlays NXentry) - NXentry - @entry - definition:NX_CHAR - start_time:NX_DATE_TIME - title:NX_CHAR - NXdata - absorbed_beam --> /entry/instrument/absorbed_beam - energy --> /entry/instrument/monochromator/energy - NXinstrument - incoming_beam:NXdetector - data:NX_INT[np] - absorbed_beam:NXdetector - data:NX_INT[np] - monochromator:NXmonochromator - energy:NX_CHAR - NXsource - name:NX_CHAR - probe:NX_CHAR - type:NX_CHAR - NXmonitor - data:NX_INT[np] - mode:NX_CHAR - preset:NX_FLOAT - NXsample - name:NX_CHAR - - -.. rubric:: Symbols used in definition of **NXxas** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXxas** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/applications/NXxasproc.rst b/_sphinx/source/volume2/NXDL/applications/NXxasproc.rst deleted file mode 100644 index 3bd0265bd..000000000 --- a/_sphinx/source/volume2/NXDL/applications/NXxasproc.rst +++ /dev/null @@ -1,73 +0,0 @@ -.. _NXxasproc: - -######### -NXxasproc -######### - -.. index:: ! . NXDL applications; NXxasproc - -category: - applications - -NXDL source: - NXxasproc - - (http://svn.nexusformat.org/definitions/trunk/applications/NXxasproc.nxdl.xml) - -version: - 1.0 - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - :ref:`NXdata`, :ref:`NXentry`, :ref:`NXparameters`, :ref:`NXprocess`, :ref:`NXsample` - -documentation: - This is an application definition for processed data from XAS. This - is energy versus I(i)/I(a) - - - -.. rubric:: Basic Structure of **NXxasproc** - -.. code-block:: text - :linenos: - - NXxasproc (application definition, version 1.0) - (overlays NXentry) - NXentry - @entry - definition:NX_CHAR - title:NX_CHAR - NXdata - data:NX_FLOAT[np] - energy:NX_CHAR - XAS_data_reduction:NXprocess - date:NX_DATE_TIME - program:NX_CHAR - version:NX_CHAR - parameters:NXparameters - raw_file:NX_CHAR - NXsample - name:NX_CHAR - - -.. rubric:: Symbols used in definition of **NXxasproc** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXxasproc** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/applications/NXxbase.rst b/_sphinx/source/volume2/NXDL/applications/NXxbase.rst deleted file mode 100644 index aac15fa3e..000000000 --- a/_sphinx/source/volume2/NXDL/applications/NXxbase.rst +++ /dev/null @@ -1,90 +0,0 @@ -.. _NXxbase: - -####### -NXxbase -####### - -.. index:: ! . NXDL applications; NXxbase - -category: - applications - -NXDL source: - NXxbase - - (http://svn.nexusformat.org/definitions/trunk/applications/NXxbase.nxdl.xml) - -version: - 1.0b - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - :ref:`NXdata`, :ref:`NXdetector`, :ref:`NXentry`, :ref:`NXinstrument`, :ref:`NXmonitor`, :ref:`NXmonochromator`, :ref:`NXsample`, :ref:`NXsource` - -documentation: - This definition covers the common parts of all monochromatic - single crystal raw data application definitions - - - -.. rubric:: Basic Structure of **NXxbase** - -.. code-block:: text - :linenos: - - NXxbase (application definition, version 1.0b) - (overlays NXentry) - entry:NXentry - definition:NX_CHAR - start_time:NX_DATE_TIME - title:NX_CHAR - NXdata - data --> /NXentry/NXinstrument/NXdetector/data - instrument:NXinstrument - detector:NXdetector - data:NX_INT[np,number of x pixels,number of y pixels] - @signal - distance:NX_FLOAT - frame_start_number:NX_INT - x_pixel_size:NX_FLOAT - y_pixel_size:NX_FLOAT - monochromator:NXmonochromator - wavelength:NX_FLOAT - source:NXsource - name:NX_CHAR - probe:NX_CHAR - type:NX_CHAR - control:NXmonitor - integral:NX_FLOAT - mode:NX_CHAR - preset:NX_FLOAT - sample:NXsample - distance:NX_FLOAT - name:NX_CHAR - orientation_matrix:NX_FLOAT[3,3] - temperature:NX_FLOAT[NP] - unit_cell:NX_FLOAT[6] - x_translation:NX_FLOAT - y_translation:NX_FLOAT - - -.. rubric:: Symbols used in definition of **NXxbase** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXxbase** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/applications/NXxeuler.rst b/_sphinx/source/volume2/NXDL/applications/NXxeuler.rst deleted file mode 100644 index 79a1dc5b8..000000000 --- a/_sphinx/source/volume2/NXDL/applications/NXxeuler.rst +++ /dev/null @@ -1,75 +0,0 @@ -.. _NXxeuler: - -######## -NXxeuler -######## - -.. index:: ! . NXDL applications; NXxeuler - -category: - applications - -NXDL source: - NXxeuler - - (http://svn.nexusformat.org/definitions/trunk/applications/NXxeuler.nxdl.xml) - -version: - 1.0b - -SVN Id: - $Id$ - -extends class: - :ref:`NXxbase` - -other classes included: - :ref:`NXdata`, :ref:`NXdetector`, :ref:`NXentry`, :ref:`NXinstrument`, :ref:`NXsample` - -documentation: - This is the application definition for raw data from a - four circle diffractometer with an eulerian cradle. - It extends NXxbase, so the full definition is the content - of NXxbase plus the data defined here. All four angles are - logged in order to support arbitray scans in reciprocal space. - - - -.. rubric:: Basic Structure of **NXxeuler** - -.. code-block:: text - :linenos: - - NXxeuler (application definition, version 1.0b) - (overlays NXentry) - entry:NXentry - definition:NX_CHAR - name:NXdata - chi --> /NXentry/NXsample/chi - phi --> /NXentry/NXsample/phi - polar_angle --> /NXentry/NXinstrument/NXdetector/polar_angle - rotation_angle --> /NXentry/NXsample/rotation_angle - instrument:NXinstrument - detector:NXdetector - polar_angle:NX_FLOAT[np] - sample:NXsample - chi:NX_FLOAT[np] - phi:NX_FLOAT[np] - rotation_angle:NX_FLOAT[np] - - -.. rubric:: Symbols used in definition of **NXxeuler** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXxeuler** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/applications/NXxkappa.rst b/_sphinx/source/volume2/NXDL/applications/NXxkappa.rst deleted file mode 100644 index 18eabbf3f..000000000 --- a/_sphinx/source/volume2/NXDL/applications/NXxkappa.rst +++ /dev/null @@ -1,74 +0,0 @@ -.. _NXxkappa: - -######## -NXxkappa -######## - -.. index:: ! . NXDL applications; NXxkappa - -category: - applications - -NXDL source: - NXxkappa - - (http://svn.nexusformat.org/definitions/trunk/applications/NXxkappa.nxdl.xml) - -version: - 1.0b - -SVN Id: - $Id$ - -extends class: - :ref:`NXxbase` - -other classes included: - :ref:`NXdata`, :ref:`NXdetector`, :ref:`NXentry`, :ref:`NXinstrument`, :ref:`NXsample` - -documentation: - This is the application definition for raw data from a kappa geometry (CAD4) single crystal - diffractometer. It extends NXxbase, so the full definition is the content of NXxbase plus the - data defined here. - - - -.. rubric:: Basic Structure of **NXxkappa** - -.. code-block:: text - :linenos: - - NXxkappa (application definition, version 1.0b) - (overlays NXentry) - entry:NXentry - definition:NX_CHAR - name:NXdata - kappa --> /NXentry/NXsample/kappa - phi --> /NXentry/NXsample/phi - polar_angle --> /NXentry/NXinstrument/NXdetector/polar_angle - rotation_angle --> /NXentry/NXsample/rotation_angle - instrument:NXinstrument - detector:NXdetector - polar_angle:NX_FLOAT[np] - sample:NXsample - alpha:NX_FLOAT - kappa:NX_FLOAT[np] - phi:NX_FLOAT[np] - rotation_angle:NX_FLOAT[np] - - -.. rubric:: Symbols used in definition of **NXxkappa** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXxkappa** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/applications/NXxlaue.rst b/_sphinx/source/volume2/NXDL/applications/NXxlaue.rst deleted file mode 100644 index b583a37ca..000000000 --- a/_sphinx/source/volume2/NXDL/applications/NXxlaue.rst +++ /dev/null @@ -1,65 +0,0 @@ -.. _NXxlaue: - -####### -NXxlaue -####### - -.. index:: ! . NXDL applications; NXxlaue - -category: - applications - -NXDL source: - NXxlaue - - (http://svn.nexusformat.org/definitions/trunk/applications/NXxlaue.nxdl.xml) - -version: - 1.0b - -SVN Id: - $Id$ - -extends class: - :ref:`NXxrot` - -other classes included: - :ref:`NXdata`, :ref:`NXentry`, :ref:`NXinstrument`, :ref:`NXsource` - -documentation: - This is the application definition for raw data from a single crystal laue - camera. It extends NXxrot. - - - -.. rubric:: Basic Structure of **NXxlaue** - -.. code-block:: text - :linenos: - - NXxlaue (application definition, version 1.0b) - (overlays NXentry) - entry:NXentry - definition:NX_CHAR - instrument:NXinstrument - source:NXsource - distribution:NXdata - data:NX_CHAR - wavelength:NX_CHAR - - -.. rubric:: Symbols used in definition of **NXxlaue** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXxlaue** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/applications/NXxlaueplate.rst b/_sphinx/source/volume2/NXDL/applications/NXxlaueplate.rst deleted file mode 100644 index a91814672..000000000 --- a/_sphinx/source/volume2/NXDL/applications/NXxlaueplate.rst +++ /dev/null @@ -1,63 +0,0 @@ -.. _NXxlaueplate: - -############ -NXxlaueplate -############ - -.. index:: ! . NXDL applications; NXxlaueplate - -category: - applications - -NXDL source: - NXxlaueplate - - (http://svn.nexusformat.org/definitions/trunk/applications/NXxlaueplate.nxdl.xml) - -version: - 1.0b - -SVN Id: - $Id$ - -extends class: - :ref:`NXxlaue` - -other classes included: - :ref:`NXdetector`, :ref:`NXentry`, :ref:`NXinstrument` - -documentation: - This is the application definition for raw data from a single crystal laue - camera witha an image plate as a detector. It extends NXxlaue. - - - -.. rubric:: Basic Structure of **NXxlaueplate** - -.. code-block:: text - :linenos: - - NXxlaueplate (application definition, version 1.0b) - (overlays NXentry) - entry:NXentry - definition:NX_CHAR - instrument:NXinstrument - detector:NXdetector - diameter:NX_FLOAT - - -.. rubric:: Symbols used in definition of **NXxlaueplate** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXxlaueplate** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/applications/NXxnb.rst b/_sphinx/source/volume2/NXDL/applications/NXxnb.rst deleted file mode 100644 index 58bc0316d..000000000 --- a/_sphinx/source/volume2/NXDL/applications/NXxnb.rst +++ /dev/null @@ -1,72 +0,0 @@ -.. _NXxnb: - -##### -NXxnb -##### - -.. index:: ! . NXDL applications; NXxnb - -category: - applications - -NXDL source: - NXxnb - - (http://svn.nexusformat.org/definitions/trunk/applications/NXxnb.nxdl.xml) - -version: - 1.0b - -SVN Id: - $Id$ - -extends class: - :ref:`NXxbase` - -other classes included: - :ref:`NXdata`, :ref:`NXdetector`, :ref:`NXentry`, :ref:`NXinstrument`, :ref:`NXsample` - -documentation: - This is the application definition for raw data from a single crystal diffractometer - measuring in normal beam mode. It extends NXxbase, so the full definition is the content of - NXxbase plus the data defined here. All angles are logged in order to support arbitray scans in - reciprocal space. - - - -.. rubric:: Basic Structure of **NXxnb** - -.. code-block:: text - :linenos: - - NXxnb (application definition, version 1.0b) - (overlays NXentry) - entry:NXentry - definition:NX_CHAR - name:NXdata - polar_angle --> /NXentry/NXinstrument/NXdetector/polar_angle - rotation_angle --> /NXentry/NXsample/rotation_angle - tilt --> /NXentry/NXinstrument/NXdetector/tilt - instrument:NXinstrument - detector:NXdetector - polar_angle:NX_FLOAT[np] - tilt_angle:NX_FLOAT[np] - sample:NXsample - rotation_angle:NX_FLOAT[np] - - -.. rubric:: Symbols used in definition of **NXxnb** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXxnb** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/applications/NXxrot.rst b/_sphinx/source/volume2/NXDL/applications/NXxrot.rst deleted file mode 100644 index 191208e17..000000000 --- a/_sphinx/source/volume2/NXDL/applications/NXxrot.rst +++ /dev/null @@ -1,72 +0,0 @@ -.. _NXxrot: - -###### -NXxrot -###### - -.. index:: ! . NXDL applications; NXxrot - -category: - applications - -NXDL source: - NXxrot - - (http://svn.nexusformat.org/definitions/trunk/applications/NXxrot.nxdl.xml) - -version: - 1.0b - -SVN Id: - $Id$ - -extends class: - :ref:`NXxbase` - -other classes included: - :ref:`NXattenuator`, :ref:`NXdata`, :ref:`NXdetector`, :ref:`NXentry`, :ref:`NXinstrument`, :ref:`NXsample` - -documentation: - This is the application definition for raw data from a rotation camera. It extends NXxbase, - so the full definition is the content of NXxbase plus the data defined here. - - - -.. rubric:: Basic Structure of **NXxrot** - -.. code-block:: text - :linenos: - - NXxrot (application definition, version 1.0b) - (overlays NXentry) - entry:NXentry - definition:NX_CHAR - name:NXdata - rotation_angle --> /NXentry/NXsample/rotation_angle - instrument:NXinstrument - attenuator:NXattenuator - attenuator_transmission:NX_FLOAT - detector:NXdetector - beam_center_x:NX_FLOAT - beam_center_y:NX_FLOAT - polar_angle:NX_FLOAT - sample:NXsample - rotation_angle:NX_FLOAT[np] - rotation_angle_step:NX_FLOAT[np] - - -.. rubric:: Symbols used in definition of **NXxrot** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXxrot** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/applications/index.rst b/_sphinx/source/volume2/NXDL/applications/index.rst deleted file mode 100644 index 6b8ec7811..000000000 --- a/_sphinx/source/volume2/NXDL/applications/index.rst +++ /dev/null @@ -1,14 +0,0 @@ -.. $Id$ - -##################################### -NeXus Application Definitions Classes -##################################### - -Contents: - -.. toctree:: - :maxdepth: 2 - :numbered: - :glob: - - NX* diff --git a/_sphinx/source/volume2/NXDL/base_classes/NXaperture.rst b/_sphinx/source/volume2/NXDL/base_classes/NXaperture.rst deleted file mode 100644 index 6310ae5c5..000000000 --- a/_sphinx/source/volume2/NXDL/base_classes/NXaperture.rst +++ /dev/null @@ -1,61 +0,0 @@ -.. _NXaperture: - -########## -NXaperture -########## - -.. index:: ! . NXDL base_classes; NXaperture - -category: - base_classes - -NXDL source: - NXaperture - - (http://svn.nexusformat.org/definitions/trunk/base_classes/NXaperture.nxdl.xml) - -version: - 1.0 - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - :ref:`NXgeometry`, :ref:`NXnote` - -documentation: - Template of a beamline aperture. - - - -.. rubric:: Basic Structure of **NXaperture** - -.. code-block:: text - :linenos: - - NXaperture (base class, version 1.0) - description:NX_CHAR - material:NX_CHAR - NXgeometry - NXgeometry - NXnote - - -.. rubric:: Symbols used in definition of **NXaperture** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXaperture** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/base_classes/NXattenuator.rst b/_sphinx/source/volume2/NXDL/base_classes/NXattenuator.rst deleted file mode 100644 index 9f90b103c..000000000 --- a/_sphinx/source/volume2/NXDL/base_classes/NXattenuator.rst +++ /dev/null @@ -1,67 +0,0 @@ -.. _NXattenuator: - -############ -NXattenuator -############ - -.. index:: ! . NXDL base_classes; NXattenuator - -category: - base_classes - -NXDL source: - NXattenuator - - (http://svn.nexusformat.org/definitions/trunk/base_classes/NXattenuator.nxdl.xml) - -version: - 1.0 - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - none - -documentation: - Template of a beamline attenuator. - If uncertain whether to use NXfilter (band-pass filter) - or NXattenuator (reduces beam intensity), then use - NXattenuator. - - - -.. rubric:: Basic Structure of **NXattenuator** - -.. code-block:: text - :linenos: - - NXattenuator (base class, version 1.0) - absorption_cross_section:NX_FLOAT - attenuator_transmission:NX_FLOAT - distance:NX_FLOAT - scattering_cross_section:NX_FLOAT - status:NX_CHAR - @time - thickness:NX_FLOAT - type:NX_CHAR - - -.. rubric:: Symbols used in definition of **NXattenuator** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXattenuator** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/base_classes/NXbeam.rst b/_sphinx/source/volume2/NXDL/base_classes/NXbeam.rst deleted file mode 100644 index 08cfeb9b7..000000000 --- a/_sphinx/source/volume2/NXDL/base_classes/NXbeam.rst +++ /dev/null @@ -1,76 +0,0 @@ -.. _NXbeam: - -###### -NXbeam -###### - -.. index:: ! . NXDL base_classes; NXbeam - -category: - base_classes - -NXDL source: - NXbeam - - (http://svn.nexusformat.org/definitions/trunk/base_classes/NXbeam.nxdl.xml) - -version: - 1.0 - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - :ref:`NXdata` - -documentation: - Template of the state of the neutron or X-ray beam at any location. It will be referenced - by beamline component groups within the NXinstrument group or by the NXsample group. Note - that variables such as the incident energy could be scalar values or arrays. This group is - especially valuable in storing the results of instrument simulations in which it is useful - to specify the beam profile, time distribution etc. at each beamline component. Otherwise, - its most likely use is in the NXsample group in which it defines the results of the neutron - scattering by the sample, e.g., energy transfer, polarizations. - - - -.. rubric:: Basic Structure of **NXbeam** - -.. code-block:: text - :linenos: - - NXbeam (base class, version 1.0) - distance:NX_FLOAT - energy_transfer:NX_FLOAT[i] - final_beam_divergence:NX_FLOAT[2,j] - final_energy:NX_FLOAT[i] - final_polarization:NX_FLOAT[2,j] - final_wavelength:NX_FLOAT[i] - final_wavelength_spread:NX_FLOAT[i] - flux:NX_FLOAT[i] - incident_beam_divergence:NX_FLOAT[2,j] - incident_energy:NX_FLOAT[i] - incident_polarization:NX_FLOAT[2,j] - incident_wavelength:NX_FLOAT[i] - incident_wavelength_spread:NX_FLOAT[i] - NXdata - - -.. rubric:: Symbols used in definition of **NXbeam** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXbeam** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/base_classes/NXbeam_stop.rst b/_sphinx/source/volume2/NXDL/base_classes/NXbeam_stop.rst deleted file mode 100644 index 624b04d1c..000000000 --- a/_sphinx/source/volume2/NXDL/base_classes/NXbeam_stop.rst +++ /dev/null @@ -1,64 +0,0 @@ -.. _NXbeam_stop: - -########### -NXbeam_stop -########### - -.. index:: ! . NXDL base_classes; NXbeam_stop - -category: - base_classes - -NXDL source: - NXbeam_stop - - (http://svn.nexusformat.org/definitions/trunk/base_classes/NXbeam_stop.nxdl.xml) - -version: - 1.0 - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - :ref:`NXgeometry` - -documentation: - A class for a beamstop. Beamstops and their positions are important for SANS - and SAXS experiments. - - - -.. rubric:: Basic Structure of **NXbeam_stop** - -.. code-block:: text - :linenos: - - NXbeam_stop (base class, version 1.0) - description:NX_CHAR - distance_to_detector:NX_FLOAT - size:NX_FLOAT - status:NX_CHAR - x:NX_FLOAT - y:NX_FLOAT - NXgeometry - - -.. rubric:: Symbols used in definition of **NXbeam_stop** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXbeam_stop** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/base_classes/NXbending_magnet.rst b/_sphinx/source/volume2/NXDL/base_classes/NXbending_magnet.rst deleted file mode 100644 index f4f7d1fd9..000000000 --- a/_sphinx/source/volume2/NXDL/base_classes/NXbending_magnet.rst +++ /dev/null @@ -1,68 +0,0 @@ -.. _NXbending_magnet: - -################ -NXbending_magnet -################ - -.. index:: ! . NXDL base_classes; NXbending_magnet - -category: - base_classes - -NXDL source: - NXbending_magnet - - (http://svn.nexusformat.org/definitions/trunk/base_classes/NXbending_magnet.nxdl.xml) - -version: - 1.0 - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - :ref:`NXdata`, :ref:`NXgeometry` - -documentation: - description for a bending magnet - - - -.. rubric:: Basic Structure of **NXbending_magnet** - -.. code-block:: text - :linenos: - - NXbending_magnet (base class, version 1.0) - accepted_photon_beam_divergence:NX_FLOAT - bending_radius:NX_FLOAT - critical_energy:NX_FLOAT - divergence_x_minus:NX_FLOAT - divergence_x_plus:NX_FLOAT - divergence_y_minus:NX_FLOAT - divergence_y_plus:NX_FLOAT - magnetic_field:NX_FLOAT - source_distance_x:NX_FLOAT - source_distance_y:NX_FLOAT - spectrum:NXdata - NXgeometry - - -.. rubric:: Symbols used in definition of **NXbending_magnet** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXbending_magnet** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/base_classes/NXcapillary.rst b/_sphinx/source/volume2/NXDL/base_classes/NXcapillary.rst deleted file mode 100644 index 24b5e36a8..000000000 --- a/_sphinx/source/volume2/NXDL/base_classes/NXcapillary.rst +++ /dev/null @@ -1,65 +0,0 @@ -.. _NXcapillary: - -########### -NXcapillary -########### - -.. index:: ! . NXDL base_classes; NXcapillary - -category: - base_classes - -NXDL source: - NXcapillary - - (http://svn.nexusformat.org/definitions/trunk/base_classes/NXcapillary.nxdl.xml) - -version: - 1.0 - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - :ref:`NXdata` - -documentation: - This is a dictionary of field names to use for describing a capillary as used - in X-ray beamlines. Based on information provided by Gerd Wellenreuther. - - - -.. rubric:: Basic Structure of **NXcapillary** - -.. code-block:: text - :linenos: - - NXcapillary (base class, version 1.0) - accepting_aperture:NX_FLOAT - focal_size:NX_FLOAT - manufacturer:NX_CHAR - maximum_incident_angle:NX_FLOAT - type:NX_CHAR - working_distance:NX_FLOAT - gain:NXdata - transmission:NXdata - - -.. rubric:: Symbols used in definition of **NXcapillary** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXcapillary** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/base_classes/NXcharacterization.rst b/_sphinx/source/volume2/NXDL/base_classes/NXcharacterization.rst deleted file mode 100644 index 4a5b07180..000000000 --- a/_sphinx/source/volume2/NXDL/base_classes/NXcharacterization.rst +++ /dev/null @@ -1,78 +0,0 @@ -.. _NXcharacterization: - -################## -NXcharacterization -################## - -.. index:: ! . NXDL base_classes; NXcharacterization - -category: - base_classes - -NXDL source: - NXcharacterization - - (http://svn.nexusformat.org/definitions/trunk/base_classes/NXcharacterization.nxdl.xml) - -version: - 1.0 - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - none - -documentation: - .. COMMENT: TODO: NXcharacterization needs proper documentation - - .. COMMENT: Template of the top-level NeXus group which contains - all the data and associated information that comprise a - single measurement. It is mandatory that there is at least - one group of this type in the NeXus file. - - - -.. rubric:: Basic Structure of **NXcharacterization** - -.. code-block:: text - :linenos: - - NXcharacterization (base class, version 1.0) - @source - @location - @mime_type - definition:NX_CHAR - @version - @URL - - -.. rubric:: Symbols used in definition of **NXcharacterization** - -No symbols are defined in this NXDL file - - - -.. rubric:: Attributes of ``definition`` element in **NXcharacterization** - -+------------+---------+-------+--------------------------------+ -| Attributes | Type | Units | Description (and Occurrences) | -+============+=========+=======+================================+ -| @source | NX_CHAR | .. | .. | -+------------+---------+-------+--------------------------------+ -| @location | NX_CHAR | .. | .. | -+------------+---------+-------+--------------------------------+ -| @mime_type | NX_CHAR | .. | .. | -+------------+---------+-------+--------------------------------+ - - -.. rubric:: Comprehensive Structure of **NXcharacterization** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/base_classes/NXcollection.rst b/_sphinx/source/volume2/NXDL/base_classes/NXcollection.rst deleted file mode 100644 index a2115fb72..000000000 --- a/_sphinx/source/volume2/NXDL/base_classes/NXcollection.rst +++ /dev/null @@ -1,64 +0,0 @@ -.. _NXcollection: - -############ -NXcollection -############ - -.. index:: ! . NXDL base_classes; NXcollection - -category: - base_classes - -NXDL source: - NXcollection - - (http://svn.nexusformat.org/definitions/trunk/base_classes/NXcollection.nxdl.xml) - -version: - 1.0 - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - none - -documentation: - Use NXcollection to gather together any set of terms. - The original suggestion is to use this as a container - class for the description of a beamline. - - For NeXus validation, NXcollection will always generate - a warning since it is always an optional group. Anything (groups, fields, - or attributes) placed in - an NXcollection group will not be validated. - - - -.. rubric:: Basic Structure of **NXcollection** - -.. code-block:: text - :linenos: - - NXcollection (contributed definition, version 1.0) - beamline:NX_CHAR - - -.. rubric:: Symbols used in definition of **NXcollection** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXcollection** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/base_classes/NXcollimator.rst b/_sphinx/source/volume2/NXDL/base_classes/NXcollimator.rst deleted file mode 100644 index 211f18a70..000000000 --- a/_sphinx/source/volume2/NXDL/base_classes/NXcollimator.rst +++ /dev/null @@ -1,67 +0,0 @@ -.. _NXcollimator: - -############ -NXcollimator -############ - -.. index:: ! . NXDL base_classes; NXcollimator - -category: - base_classes - -NXDL source: - NXcollimator - - (http://svn.nexusformat.org/definitions/trunk/base_classes/NXcollimator.nxdl.xml) - -version: - 1.0 - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - :ref:`NXgeometry`, :ref:`NXlog` - -documentation: - Template of a beamline collimator. - - - -.. rubric:: Basic Structure of **NXcollimator** - -.. code-block:: text - :linenos: - - NXcollimator (base class, version 1.0) - absorbing_material:NX_CHAR - blade_spacing:NX_FLOAT - blade_thickness:NX_FLOAT - divergence_x:NX_FLOAT - divergence_y:NX_FLOAT - frequency:NX_FLOAT - soller_angle:NX_FLOAT - transmitting_material:NX_CHAR - type:NX_CHAR - NXgeometry - frequency_log:NXlog - - -.. rubric:: Symbols used in definition of **NXcollimator** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXcollimator** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/base_classes/NXcrystal.rst b/_sphinx/source/volume2/NXDL/base_classes/NXcrystal.rst deleted file mode 100644 index 7810249cf..000000000 --- a/_sphinx/source/volume2/NXDL/base_classes/NXcrystal.rst +++ /dev/null @@ -1,115 +0,0 @@ -.. _NXcrystal: - -######### -NXcrystal -######### - -.. index:: ! . NXDL base_classes; NXcrystal - -category: - base_classes - -NXDL source: - NXcrystal - - (http://svn.nexusformat.org/definitions/trunk/base_classes/NXcrystal.nxdl.xml) - -version: - 1.0 - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - :ref:`NXdata`, :ref:`NXgeometry`, :ref:`NXlog`, :ref:`NXshape` - -documentation: - Template of a crystal monochromator or analyzer. Permits double bent - monochromator comprised of multiple segments with anisotropic - Gaussian mosaic. - - If curvatures are set to zero or are absent, array - is considered to be flat. - - Scattering vector is perpendicular to surface. Crystal is oriented - parallel to beam incident on crystal before rotation, and lies in - vertical plane. - - - -.. rubric:: Basic Structure of **NXcrystal** - -.. code-block:: text - :linenos: - - NXcrystal (base class, version 1.0) - azimuthal_angle:NX_FLOAT[i] - bragg_angle:NX_FLOAT[i] - chemical_formula:NX_CHAR - curvature_horizontal:NX_FLOAT - curvature_vertical:NX_FLOAT - cut_angle:NX_FLOAT - cylindrical_orientation_angle:NX_NUMBER - d_spacing:NX_FLOAT - density:NX_NUMBER - is_cylindrical:NX_BOOLEAN - mosaic_horizontal:NX_FLOAT - mosaic_vertical:NX_FLOAT - order_no:NX_INT - orientation_matrix:NX_FLOAT[3,3] - polar_angle:NX_FLOAT[i] - reflection:NX_INT[3] - scattering_vector:NX_FLOAT - segment_columns:NX_FLOAT - segment_gap:NX_FLOAT - segment_height:NX_FLOAT - segment_rows:NX_FLOAT - segment_thickness:NX_FLOAT - segment_width:NX_FLOAT - space_group:NX_CHAR - temperature:NX_FLOAT - temperature_coefficient:NX_FLOAT - thickness:NX_FLOAT - type:NX_CHAR - unit_cell:NX_FLOAT[n_comp,6] - unit_cell_a:NX_FLOAT - unit_cell_alpha:NX_FLOAT - unit_cell_b:NX_FLOAT - unit_cell_beta:NX_FLOAT - unit_cell_c:NX_FLOAT - unit_cell_gamma:NX_FLOAT - unit_cell_volume:NX_FLOAT - usage:NX_CHAR - wavelength:NX_FLOAT[i] - reflectivity:NXdata - transmission:NXdata - NXgeometry - temperature_log:NXlog - shape:NXshape - - -.. rubric:: Symbols used in definition of **NXcrystal** - -These symbols will be used below to coordinate dimensions with the same lengths. - -+------------+------------------------------------------------+ -| Symbol | Description | -+============+================================================+ -| ``n_comp`` | number of different unit cells to be described | -+------------+------------------------------------------------+ -| ``i`` | number of wavelengths | -+------------+------------------------------------------------+ - - - - -.. rubric:: Comprehensive Structure of **NXcrystal** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/base_classes/NXdata.rst b/_sphinx/source/volume2/NXDL/base_classes/NXdata.rst deleted file mode 100644 index c40037068..000000000 --- a/_sphinx/source/volume2/NXDL/base_classes/NXdata.rst +++ /dev/null @@ -1,145 +0,0 @@ -.. _NXdata: - -###### -NXdata -###### - -.. index:: ! . NXDL base_classes; NXdata - -category: - base_classes - -NXDL source: - NXdata - - (http://svn.nexusformat.org/definitions/trunk/base_classes/NXdata.nxdl.xml) - -version: - 1.0 - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - none - -documentation: - (required) NXdata is a template of - plottable data and their dimension scales. - - NeXus basic motivation - default plot - - It is mandatory that there is at least one NXdata group - in each NXentry group. - Note that the variable and data - can be defined with different names. - The signal and axes attribute of the - data item define which items - are plottable data and which are dimension scales. - - NeXus basic motivation - default plot - - Each NXdata group will consist of only one data set - containing plottable data and their standard deviations. - - This data set may be of arbitrary rank up to a maximum - of NX_MAXRANK=32. - - The plottable data will be identified by the attribute: - signal="1" - - The plottable data will identify the dimension - scale(s) in the axes attribute. - - If available, the standard deviations of the data are to be - stored in a data set of the same rank and dimensions, with the name errors. - - For each data dimension, there should be a one-dimensional array - of the same length. - - These one-dimensional arrays are the dimension scales of the - data, i.e. the values of the independent variables at which the data - is measured, such as scattering angle or energy transfer. - - There are two methods of linking - - link - - each data dimension to its respective dimension scale. - - The preferred (and recommended) method uses the axes - - axes - - attribute to specify the names of each dimension scale. - - The older method uses the axis attribute on each - dimension scale - to identify - with an integer the axis whose value is the number of the dimension. - - NXdata is used to implement one of the basic motivations in NeXus, - to provide a default plot for the data of this NXentry. The actual data - might be stored in another group and (hard) linked to the NXdata group. - - - -.. rubric:: Basic Structure of **NXdata** - -.. code-block:: text - :linenos: - - NXdata (base class, version 1.0) - data:NX_NUMBER[n] - @signal - @axes - @uncertainties - @long_name - errors:NX_NUMBER[n] - offset:NX_FLOAT - scaling_factor:NX_FLOAT - variable:NX_NUMBER[n] - @long_name - @distribution - @first_good - @last_good - @axis - variable_errors:NX_NUMBER[n] - x:NX_FLOAT[nx] - y:NX_FLOAT[ny] - z:NX_FLOAT[nz] - - -.. rubric:: Symbols used in definition of **NXdata** - -These symbols will be used below to coordinate datasets with the same shape. - -+--------------+------------------------------+ -| Symbol | Description | -+==============+==============================+ -| ``dataRank`` | rank of the data field | -+--------------+------------------------------+ -| ``n`` | length of the variable field | -+--------------+------------------------------+ -| ``nx`` | length of the x field | -+--------------+------------------------------+ -| ``ny`` | length of the y field | -+--------------+------------------------------+ -| ``nz`` | length of the z field | -+--------------+------------------------------+ - - - - -.. rubric:: Comprehensive Structure of **NXdata** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/base_classes/NXdetector.rst b/_sphinx/source/volume2/NXDL/base_classes/NXdetector.rst deleted file mode 100644 index bd46fd6ab..000000000 --- a/_sphinx/source/volume2/NXDL/base_classes/NXdetector.rst +++ /dev/null @@ -1,147 +0,0 @@ -.. _NXdetector: - -########## -NXdetector -########## - -.. index:: ! . NXDL base_classes; NXdetector - -category: - base_classes - -NXDL source: - NXdetector - - (http://svn.nexusformat.org/definitions/trunk/base_classes/NXdetector.nxdl.xml) - -version: - 1.0 - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - :ref:`NXcharacterization`, :ref:`NXdata`, :ref:`NXgeometry`, :ref:`NXnote` - -documentation: - Template of a detector, detector bank, or multidetector. - - - -.. rubric:: Basic Structure of **NXdetector** - -.. code-block:: text - :linenos: - - NXdetector (base class, version 1.0) - acquisition_mode:NX_CHAR - angular_calibration:NX_FLOAT[i,j] - angular_calibration_applied:NX_BOOLEAN - azimuthal_angle:NX_FLOAT[np,i,j] - beam_center_x:NX_FLOAT - beam_center_y:NX_FLOAT - bit_depth_readout:NX_INT - calibration_date:NX_DATE_TIME - count_time:NX_NUMBER[np] - crate:NX_INT[i,j] - @local_name - data:NX_NUMBER[np,i,j,tof] - @signal - @axes - @long_name - @check_sum - @link - data_error:NX_NUMBER[np,i,j,tof] - @units - @link - dead_time:NX_FLOAT[np,i,j] - description:NX_CHAR - detection_gas_path:NX_FLOAT - detector_number:NX_INT[i,j] - detector_readout_time:NX_FLOAT - diameter:NX_FLOAT - distance:NX_FLOAT[np,i,j] - flatfield:NX_FLOAT[i,j] - flatfield_applied:NX_BOOLEAN - flatfield_error:NX_FLOAT[i,j] - frame_start_number:NX_INT - gain_setting:NX_CHAR - gas_pressure:NX_FLOAT[i,j] - input:NX_INT[i,j] - @local_name - layout:NX_CHAR - local_name:NX_CHAR - number_of_cycles:NX_INT - pixel_mask:NX_FLOAT[i,j] - pixel_mask_applied:NX_BOOLEAN - polar_angle:NX_FLOAT[np,i,j] - raw_time_of_flight:NX_INT[tof+1] - @frequency - saturation_value:NX_INT - sensor_material:NX_CHAR - sensor_thickness:NX_FLOAT - sequence_number:NX_CHAR - slot:NX_INT[i,j] - @local_name - solid_angle:NX_FLOAT[i,j] - threshold_energy:NX_FLOAT - time_of_flight:NX_FLOAT[tof+1] - @axis - @primary - @long_name - @link - trigger_dead_time:NX_FLOAT - trigger_delay_time:NX_FLOAT - type:NX_CHAR - x_pixel_offset:NX_FLOAT[i,j] - @axis - @primary - @long_name - @link - x_pixel_size:NX_FLOAT[i,j] - y_pixel_offset:NX_FLOAT[i,j] - @axis - @primary - @long_name - y_pixel_size:NX_FLOAT[i,j] - NXcharacterization - efficiency:NXdata - efficiency:NX_FLOAT[i,j,k] - real_time:NX_NUMBER[i,j,k] - wavelength:NX_FLOAT[i,j,k] - NXgeometry - calibration_method:NXnote - data_file:NXnote - - -.. rubric:: Symbols used in definition of **NXdetector** - -These symbols will be used below to coordinate datasets with the same shape. - -+---------+-----------------------------------------------------------------------------+ -| Symbol | Description | -+=========+=============================================================================+ -| ``np`` | number of scan points (only present in scanning measurements) | -+---------+-----------------------------------------------------------------------------+ -| ``i`` | number of detector pixels in the first (X, slowest) direction | -+---------+-----------------------------------------------------------------------------+ -| ``j`` | number of detector pixels in the second (Y, faster) direction | -+---------+-----------------------------------------------------------------------------+ -| ``k`` | number of detector pixels in the third (Z, if necessary, fastest) direction | -+---------+-----------------------------------------------------------------------------+ -| ``tof`` | number of bins in the time-of-flight histogram | -+---------+-----------------------------------------------------------------------------+ - - - - -.. rubric:: Comprehensive Structure of **NXdetector** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/base_classes/NXdetector_group.rst b/_sphinx/source/volume2/NXDL/base_classes/NXdetector_group.rst deleted file mode 100644 index 7b5398da0..000000000 --- a/_sphinx/source/volume2/NXDL/base_classes/NXdetector_group.rst +++ /dev/null @@ -1,75 +0,0 @@ -.. _NXdetector_group: - -################ -NXdetector_group -################ - -.. index:: ! . NXDL base_classes; NXdetector_group - -category: - base_classes - -NXDL source: - NXdetector_group - - (http://svn.nexusformat.org/definitions/trunk/base_classes/NXdetector_group.nxdl.xml) - -version: - 1.0 - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - none - -documentation: - This class is used to allow a logical - grouping of detector elements (e.g. which tube, bank or group of banks) to be - recorded in the file. As well as allowing you to e.g just select the "left" or - "east" detectors, it may also be useful for determining which elements belong to the - same PSD tube and hence have e.g. the same dead time. - - For example, if we had "bank1" composed - of "tube1", "tube2" and "tube3" then group_names would be the string "bank1, - bank1/tube1, bank1/tube2,bank1/tube3" group_index would be {1,2,3,4} group_parent - would be {-1,1,1,1} - - The mapping array is interpreted as - group 1 is a top level group containing groups 2, 3 and 4 - - A group_index array in - NXdetector give the base group for a detector element. - - - -.. rubric:: Basic Structure of **NXdetector_group** - -.. code-block:: text - :linenos: - - NXdetector_group (base class, version 1.0) - group_index:NX_INT[i] - group_names:NX_CHAR - group_parent:NX_INT[] - group_type:NX_INT[] - - -.. rubric:: Symbols used in definition of **NXdetector_group** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXdetector_group** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/base_classes/NXdisk_chopper.rst b/_sphinx/source/volume2/NXDL/base_classes/NXdisk_chopper.rst deleted file mode 100644 index 091123dd1..000000000 --- a/_sphinx/source/volume2/NXDL/base_classes/NXdisk_chopper.rst +++ /dev/null @@ -1,67 +0,0 @@ -.. _NXdisk_chopper: - -############## -NXdisk_chopper -############## - -.. index:: ! . NXDL base_classes; NXdisk_chopper - -category: - base_classes - -NXDL source: - NXdisk_chopper - - (http://svn.nexusformat.org/definitions/trunk/base_classes/NXdisk_chopper.nxdl.xml) - -version: - 1.0 - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - :ref:`NXgeometry` - -documentation: - No documentation provided. - - -.. rubric:: Basic Structure of **NXdisk_chopper** - -.. code-block:: text - :linenos: - - NXdisk_chopper (base class, version 1.0) - distance:NX_FLOAT - pair_separation:NX_FLOAT - phase:NX_FLOAT - radius:NX_FLOAT - ratio:NX_INT - rotation_speed:NX_FLOAT - slit_angle:NX_FLOAT - slit_height:NX_FLOAT - slits:NX_INT - type:NX_CHAR - wavelength_range:NX_FLOAT[2] - NXgeometry - - -.. rubric:: Symbols used in definition of **NXdisk_chopper** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXdisk_chopper** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/base_classes/NXentry.rst b/_sphinx/source/volume2/NXDL/base_classes/NXentry.rst deleted file mode 100644 index c656eef6f..000000000 --- a/_sphinx/source/volume2/NXDL/base_classes/NXentry.rst +++ /dev/null @@ -1,101 +0,0 @@ -.. _NXentry: - -####### -NXentry -####### - -.. index:: ! . NXDL base_classes; NXentry - -category: - base_classes - -NXDL source: - NXentry - - (http://svn.nexusformat.org/definitions/trunk/base_classes/NXentry.nxdl.xml) - -version: - 1.0 - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - :ref:`NXcharacterization`, :ref:`NXdata`, :ref:`NXinstrument`, :ref:`NXmonitor`, :ref:`NXnote`, :ref:`NXprocess`, :ref:`NXsample`, :ref:`NXsubentry`, :ref:`NXuser` - -documentation: - (required) Template of the top-level NeXus group which contains all the data and associated - information that comprise a single measurement. It is mandatory that there is at least one - group of this type in the NeXus file. - - - -.. rubric:: Basic Structure of **NXentry** - -.. code-block:: text - :linenos: - - NXentry (base class, version 1.0) - @IDF_Version - collection_description:NX_CHAR - collection_identifier:NX_CHAR - collection_time:NX_FLOAT - definition:NX_CHAR - @version - @URL - definition_local:NX_CHAR - @version - @URL - duration:NX_INT - end_time:NX_DATE_TIME - entry_identifier:NX_CHAR - experiment_description:NX_CHAR - experiment_identifier:NX_CHAR - pre_sample_flightpath:NX_FLOAT - program_name:NX_CHAR - @version - @configuration - revision:NX_CHAR - @comment - run_cycle:NX_CHAR - start_time:NX_DATE_TIME - title:NX_CHAR - NXcharacterization - NXdata - NXinstrument - NXmonitor - experiment_documentation:NXnote - notes:NXnote - thumbnail:NXnote - @mime_type - NXprocess - NXsample - NXsubentry - NXuser - - -.. rubric:: Symbols used in definition of **NXentry** - -No symbols are defined in this NXDL file - - - -.. rubric:: Attributes of ``definition`` element in **NXentry** - -+--------------+---------+-------+--------------------------------+ -| Attributes | Type | Units | Description (and Occurrences) | -+==============+=========+=======+================================+ -| @IDF_Version | NX_CHAR | .. | .. | -+--------------+---------+-------+--------------------------------+ - - -.. rubric:: Comprehensive Structure of **NXentry** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/base_classes/NXenvironment.rst b/_sphinx/source/volume2/NXDL/base_classes/NXenvironment.rst deleted file mode 100644 index 86ea57b9f..000000000 --- a/_sphinx/source/volume2/NXDL/base_classes/NXenvironment.rst +++ /dev/null @@ -1,64 +0,0 @@ -.. _NXenvironment: - -############# -NXenvironment -############# - -.. index:: ! . NXDL base_classes; NXenvironment - -category: - base_classes - -NXDL source: - NXenvironment - - (http://svn.nexusformat.org/definitions/trunk/base_classes/NXenvironment.nxdl.xml) - -version: - 1.0 - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - :ref:`NXgeometry`, :ref:`NXnote`, :ref:`NXsensor` - -documentation: - This class describes an external condition applied to the sample - - - -.. rubric:: Basic Structure of **NXenvironment** - -.. code-block:: text - :linenos: - - NXenvironment (base class, version 1.0) - description:NX_CHAR - name:NX_CHAR - program:NX_CHAR - short_name:NX_CHAR - type:NX_CHAR - position:NXgeometry - NXnote - NXsensor - - -.. rubric:: Symbols used in definition of **NXenvironment** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXenvironment** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/base_classes/NXevent_data.rst b/_sphinx/source/volume2/NXDL/base_classes/NXevent_data.rst deleted file mode 100644 index 5e2d3288c..000000000 --- a/_sphinx/source/volume2/NXDL/base_classes/NXevent_data.rst +++ /dev/null @@ -1,62 +0,0 @@ -.. _NXevent_data: - -############ -NXevent_data -############ - -.. index:: ! . NXDL base_classes; NXevent_data - -category: - base_classes - -NXDL source: - NXevent_data - - (http://svn.nexusformat.org/definitions/trunk/base_classes/NXevent_data.nxdl.xml) - -version: - 1.0 - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - none - -documentation: - Time-of-flight events - - - -.. rubric:: Basic Structure of **NXevent_data** - -.. code-block:: text - :linenos: - - NXevent_data (base class, version 1.0) - events_per_pulse:NX_INT[j] - pixel_number:NX_INT[i] - pulse_height:NX_FLOAT[i,k] - pulse_time:NX_INT[j] - @offset - time_of_flight:NX_INT[i] - - -.. rubric:: Symbols used in definition of **NXevent_data** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXevent_data** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/base_classes/NXfermi_chopper.rst b/_sphinx/source/volume2/NXDL/base_classes/NXfermi_chopper.rst deleted file mode 100644 index 3dfca2338..000000000 --- a/_sphinx/source/volume2/NXDL/base_classes/NXfermi_chopper.rst +++ /dev/null @@ -1,70 +0,0 @@ -.. _NXfermi_chopper: - -############### -NXfermi_chopper -############### - -.. index:: ! . NXDL base_classes; NXfermi_chopper - -category: - base_classes - -NXDL source: - NXfermi_chopper - - (http://svn.nexusformat.org/definitions/trunk/base_classes/NXfermi_chopper.nxdl.xml) - -version: - 1.0 - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - :ref:`NXgeometry` - -documentation: - Description of a Fermi chopper, possibly with curved slits. - - - -.. rubric:: Basic Structure of **NXfermi_chopper** - -.. code-block:: text - :linenos: - - NXfermi_chopper (base class, version 1.0) - absorbing_material:NX_CHAR - distance:NX_FLOAT - energy:NX_FLOAT - height:NX_FLOAT - number:NX_INT - r_slit:NX_FLOAT - radius:NX_FLOAT - rotation_speed:NX_FLOAT - slit:NX_FLOAT - transmitting_material:NX_CHAR - type:NX_CHAR - wavelength:NX_FLOAT - width:NX_FLOAT - NXgeometry - - -.. rubric:: Symbols used in definition of **NXfermi_chopper** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXfermi_chopper** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/base_classes/NXfilter.rst b/_sphinx/source/volume2/NXDL/base_classes/NXfilter.rst deleted file mode 100644 index 2424e22ed..000000000 --- a/_sphinx/source/volume2/NXDL/base_classes/NXfilter.rst +++ /dev/null @@ -1,83 +0,0 @@ -.. _NXfilter: - -######## -NXfilter -######## - -.. index:: ! . NXDL base_classes; NXfilter - -category: - base_classes - -NXDL source: - NXfilter - - (http://svn.nexusformat.org/definitions/trunk/base_classes/NXfilter.nxdl.xml) - -version: - 1.0 - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - :ref:`NXdata`, :ref:`NXgeometry`, :ref:`NXlog`, :ref:`NXsensor` - -documentation: - Template for specifying the state of band pass filters. - If uncertain whether to use NXfilter (band-pass filter) - or NXattenuator (reduces beam intensity), then use - NXattenuator. - - - -.. rubric:: Basic Structure of **NXfilter** - -.. code-block:: text - :linenos: - - NXfilter (base class, version 1.0) - chemical_formula:NX_CHAR - coating_material:NX_CHAR - coating_roughness:NX_FLOAT[nsurf] - density:NX_NUMBER - description:NX_CHAR - m_value:NX_FLOAT - orientation_matrix:NX_FLOAT[n_comp,3,3] - status:NX_CHAR - substrate_material:NX_CHAR - substrate_roughness:NX_FLOAT - substrate_thickness:NX_FLOAT - temperature:NX_FLOAT - thickness:NX_FLOAT - unit_cell_a:NX_FLOAT - unit_cell_alpha:NX_FLOAT - unit_cell_b:NX_FLOAT - unit_cell_beta:NX_FLOAT - unit_cell_c:NX_FLOAT - unit_cell_gamma:NX_FLOAT - unit_cell_volume:NX_FLOAT[n_comp] - transmission:NXdata - NXgeometry - temperature_log:NXlog - sensor_type:NXsensor - - -.. rubric:: Symbols used in definition of **NXfilter** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXfilter** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/base_classes/NXflipper.rst b/_sphinx/source/volume2/NXDL/base_classes/NXflipper.rst deleted file mode 100644 index 01fe89e33..000000000 --- a/_sphinx/source/volume2/NXDL/base_classes/NXflipper.rst +++ /dev/null @@ -1,64 +0,0 @@ -.. _NXflipper: - -######### -NXflipper -######### - -.. index:: ! . NXDL base_classes; NXflipper - -category: - base_classes - -NXDL source: - NXflipper - - (http://svn.nexusformat.org/definitions/trunk/base_classes/NXflipper.nxdl.xml) - -version: - 1.0 - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - none - -documentation: - Template of a beamline spin flipper. - - - -.. rubric:: Basic Structure of **NXflipper** - -.. code-block:: text - :linenos: - - NXflipper (base class, version 1.0) - comp_current:NX_FLOAT - comp_turns:NX_FLOAT - flip_current:NX_FLOAT - flip_turns:NX_FLOAT - guide_current:NX_FLOAT - guide_turns:NX_FLOAT - thickness:NX_FLOAT - type:NX_CHAR - - -.. rubric:: Symbols used in definition of **NXflipper** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXflipper** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/base_classes/NXgeometry.rst b/_sphinx/source/volume2/NXDL/base_classes/NXgeometry.rst deleted file mode 100644 index b5fb9ac37..000000000 --- a/_sphinx/source/volume2/NXDL/base_classes/NXgeometry.rst +++ /dev/null @@ -1,65 +0,0 @@ -.. _NXgeometry: - -########## -NXgeometry -########## - -.. index:: ! . NXDL base_classes; NXgeometry - -category: - base_classes - -NXDL source: - NXgeometry - - (http://svn.nexusformat.org/definitions/trunk/base_classes/NXgeometry.nxdl.xml) - -version: - 1.0 - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - :ref:`NXorientation`, :ref:`NXshape`, :ref:`NXtranslation` - -documentation: - This is the description for a general position of a component. - It is recommended to name an instance of NXgeometry as "geometry" - to aid in the use of the definition in simulation codes such as McStas. - Also, in HDF, linked items must share the same name. - However, it might not be possible or practical in all situations. - - - -.. rubric:: Basic Structure of **NXgeometry** - -.. code-block:: text - :linenos: - - NXgeometry (base class, version 1.0) - component_index:NX_INT - description:NX_CHAR - NXorientation - NXshape - NXtranslation - - -.. rubric:: Symbols used in definition of **NXgeometry** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXgeometry** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/base_classes/NXguide.rst b/_sphinx/source/volume2/NXDL/base_classes/NXguide.rst deleted file mode 100644 index 083d46bef..000000000 --- a/_sphinx/source/volume2/NXDL/base_classes/NXguide.rst +++ /dev/null @@ -1,106 +0,0 @@ -.. _NXguide: - -####### -NXguide -####### - -.. index:: ! . NXDL base_classes; NXguide - -category: - base_classes - -NXDL source: - NXguide - - (http://svn.nexusformat.org/definitions/trunk/base_classes/NXguide.nxdl.xml) - -version: - 1.0 - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - :ref:`NXdata`, :ref:`NXgeometry` - -documentation: - NXguide is used by neutron instruments to describe - a guide consists of several mirrors building a shape through which - neutrons can be guided or directed. The simplest such form is box shaped - although elliptical guides are gaining in popularity. - The individual parts of a guide usually have common characteristics - but there are cases where they are different. - For example, a neutron guide might consist of 2 or 4 coated walls or - a supermirror bender with multiple, coated vanes. - - To describe polarizing supermirrors such as used in neutron reflection, - it may be necessary to revise this definition of NXguide - to include NXpolarizer and/or NXmirror. - - When even greater complexity exists in the definition of what - constitutes a guide, - it has been suggested that NXguide - be redefined as a NXcollection of - NXmirrors each having their own - NXgeometries describing their location(s). - - For the more general case when describing mirrors, consider using - NXmirror. - - NOTE: The NeXus International Advisory Committee welcomes - comments for revision and improvement of - this definition of NXguide. - - - -.. rubric:: Basic Structure of **NXguide** - -.. code-block:: text - :linenos: - - NXguide (base class, version 1.0) - bend_angle_x:NX_FLOAT - bend_angle_y:NX_FLOAT - coating_material:NX_FLOAT[nsurf] - coating_roughness:NX_FLOAT[nsurf] - description:NX_CHAR - external_material:NX_CHAR - incident_angle:NX_FLOAT - interior_atmosphere:NX_CHAR - m_value:NX_FLOAT[nsurf] - number_sections:NX_INT - substrate_material:NX_FLOAT[nsurf] - substrate_roughness:NX_FLOAT[nsurf] - substrate_thickness:NX_FLOAT[nsurf] - reflectivity:NXdata - data:NX_NUMBER[nsurf,nwl] - @signal - @axes - surface:NX_NUMBER[nsurf] - wavelength:NX_NUMBER[nwl] - NXgeometry - - -.. rubric:: Symbols used in definition of **NXguide** - -+-----------+-------------------------------+ -| Symbol | Description | -+===========+===============================+ -| ``nsurf`` | number of reflecting surfaces | -+-----------+-------------------------------+ -| ``nwl`` | number of wavelengths | -+-----------+-------------------------------+ - - - - -.. rubric:: Comprehensive Structure of **NXguide** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/base_classes/NXinsertion_device.rst b/_sphinx/source/volume2/NXDL/base_classes/NXinsertion_device.rst deleted file mode 100644 index 79dc35603..000000000 --- a/_sphinx/source/volume2/NXDL/base_classes/NXinsertion_device.rst +++ /dev/null @@ -1,70 +0,0 @@ -.. _NXinsertion_device: - -################## -NXinsertion_device -################## - -.. index:: ! . NXDL base_classes; NXinsertion_device - -category: - base_classes - -NXDL source: - NXinsertion_device - - (http://svn.nexusformat.org/definitions/trunk/base_classes/NXinsertion_device.nxdl.xml) - -version: - 1.0 - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - :ref:`NXdata`, :ref:`NXgeometry` - -documentation: - Description of an insertion device, as in a synchrotron. - - - -.. rubric:: Basic Structure of **NXinsertion_device** - -.. code-block:: text - :linenos: - - NXinsertion_device (base class, version 1.0) - bandwidth:NX_FLOAT - energy:NX_FLOAT - gap:NX_FLOAT - harmonic:NX_INT - k:NX_FLOAT - length:NX_FLOAT - magnetic_wavelength:NX_FLOAT - phase:NX_FLOAT - poles:NX_INT - power:NX_FLOAT - taper:NX_FLOAT - type:NX_CHAR - spectrum:NXdata - NXgeometry - - -.. rubric:: Symbols used in definition of **NXinsertion_device** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXinsertion_device** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/base_classes/NXinstrument.rst b/_sphinx/source/volume2/NXDL/base_classes/NXinstrument.rst deleted file mode 100644 index 1bbde7fff..000000000 --- a/_sphinx/source/volume2/NXDL/base_classes/NXinstrument.rst +++ /dev/null @@ -1,82 +0,0 @@ -.. _NXinstrument: - -############ -NXinstrument -############ - -.. index:: ! . NXDL base_classes; NXinstrument - -category: - base_classes - -NXDL source: - NXinstrument - - (http://svn.nexusformat.org/definitions/trunk/base_classes/NXinstrument.nxdl.xml) - -version: - 1.0 - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - :ref:`NXaperture`, :ref:`NXattenuator`, :ref:`NXbeam_stop`, :ref:`NXbeam`, :ref:`NXbending_magnet`, :ref:`NXcollimator`, :ref:`NXcrystal`, :ref:`NXdetector`, :ref:`NXdisk_chopper`, :ref:`NXfermi_chopper`, :ref:`NXfilter`, :ref:`NXflipper`, :ref:`NXguide`, :ref:`NXinsertion_device`, :ref:`NXmirror`, :ref:`NXmoderator`, :ref:`NXpolarizer`, :ref:`NXsource`, :ref:`NXvelocity_selector` - -documentation: - Template of instrument descriptions comprising various beamline components. - Each component will also be a NeXus group defined by its distance from the - sample. Negative distances represent beamline components that are before the - sample while positive distances represent components that are after the sample. - This device allows the unique identification of beamline components in a way - that is valid for both reactor and pulsed instrumentation. - - - -.. rubric:: Basic Structure of **NXinstrument** - -.. code-block:: text - :linenos: - - NXinstrument (base class, version 1.0) - name:NX_CHAR - @short_name - NXaperture - NXattenuator - NXbeam - NXbeam_stop - NXbending_magnet - NXcollimator - NXcrystal - NXdetector - NXdisk_chopper - NXfermi_chopper - NXfilter - NXflipper - NXguide - NXinsertion_device - NXmirror - NXmoderator - NXpolarizer - NXsource - NXvelocity_selector - - -.. rubric:: Symbols used in definition of **NXinstrument** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXinstrument** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/base_classes/NXlog.rst b/_sphinx/source/volume2/NXDL/base_classes/NXlog.rst deleted file mode 100644 index a515f2ba4..000000000 --- a/_sphinx/source/volume2/NXDL/base_classes/NXlog.rst +++ /dev/null @@ -1,78 +0,0 @@ -.. _NXlog: - -##### -NXlog -##### - -.. index:: ! . NXDL base_classes; NXlog - -category: - base_classes - -NXDL source: - NXlog - - (http://svn.nexusformat.org/definitions/trunk/base_classes/NXlog.nxdl.xml) - -version: - 1.0 - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - none - -documentation: - Definition of information that is recorded against time, - such as information monitored during the run. - It contains - the logged values and the times at which they were measured as elapsed time since a starting - time recorded in ISO8601 format. This method of storing logged data helps to distinguish - instances in which a variable is a dimension scale of the data, in which case it is stored - in an NXdata group, and instances in which it is logged during the - run, when it should be stored in an NXlog group. - Note: When using multiple NXlog groups, it is suggested to place - them inside a NXcollection group. In such cases, when - NXlog is used in another class, - NXcollection/NXlog - is then constructed. - - - -.. rubric:: Basic Structure of **NXlog** - -.. code-block:: text - :linenos: - - NXlog (base class, version 1.0) - average_value:NX_FLOAT - average_value_error:NX_FLOAT - description:NX_CHAR - duration:NX_FLOAT - maximum_value:NX_FLOAT - minimum_value:NX_FLOAT - raw_value:NX_NUMBER - time:NX_FLOAT - @start - value:NX_NUMBER - - -.. rubric:: Symbols used in definition of **NXlog** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXlog** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/base_classes/NXmirror.rst b/_sphinx/source/volume2/NXDL/base_classes/NXmirror.rst deleted file mode 100644 index 5515f853f..000000000 --- a/_sphinx/source/volume2/NXDL/base_classes/NXmirror.rst +++ /dev/null @@ -1,79 +0,0 @@ -.. _NXmirror: - -######## -NXmirror -######## - -.. index:: ! . NXDL base_classes; NXmirror - -category: - base_classes - -NXDL source: - NXmirror - - (http://svn.nexusformat.org/definitions/trunk/base_classes/NXmirror.nxdl.xml) - -version: - 1.0 - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - :ref:`NXdata`, :ref:`NXgeometry`, :ref:`NXshape` - -documentation: - Template of a beamline mirror or supermirror. - - - -.. rubric:: Basic Structure of **NXmirror** - -.. code-block:: text - :linenos: - - NXmirror (base class, version 1.0) - bend_angle_x:NX_FLOAT - bend_angle_y:NX_FLOAT - coating_material:NX_CHAR - coating_roughness:NX_FLOAT - description:NX_CHAR - even_layer_density:NX_FLOAT - even_layer_material:NX_CHAR - external_material:NX_CHAR - incident_angle:NX_FLOAT - interior_atmosphere:NX_CHAR - layer_thickness:NX_FLOAT - m_value:NX_FLOAT - odd_layer_density:NX_FLOAT - odd_layer_material:NX_CHAR - substrate_density:NX_FLOAT - substrate_material:NX_CHAR - substrate_roughness:NX_FLOAT - substrate_thickness:NX_FLOAT - type:NX_CHAR - reflectivity:NXdata - figure_data:NXdata - NXgeometry - shape:NXshape - - -.. rubric:: Symbols used in definition of **NXmirror** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXmirror** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/base_classes/NXmoderator.rst b/_sphinx/source/volume2/NXDL/base_classes/NXmoderator.rst deleted file mode 100644 index 3081e5ff4..000000000 --- a/_sphinx/source/volume2/NXDL/base_classes/NXmoderator.rst +++ /dev/null @@ -1,66 +0,0 @@ -.. _NXmoderator: - -########### -NXmoderator -########### - -.. index:: ! . NXDL base_classes; NXmoderator - -category: - base_classes - -NXDL source: - NXmoderator - - (http://svn.nexusformat.org/definitions/trunk/base_classes/NXmoderator.nxdl.xml) - -version: - 1.0 - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - :ref:`NXdata`, :ref:`NXgeometry`, :ref:`NXlog` - -documentation: - This is the description for a general moderator - - - -.. rubric:: Basic Structure of **NXmoderator** - -.. code-block:: text - :linenos: - - NXmoderator (base class, version 1.0) - coupled:NX_BOOLEAN - coupling_material:NX_CHAR - distance:NX_FLOAT - poison_depth:NX_FLOAT - poison_material:NX_CHAR - temperature:NX_FLOAT - type:NX_CHAR - pulse_shape:NXdata - NXgeometry - temperature_log:NXlog - - -.. rubric:: Symbols used in definition of **NXmoderator** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXmoderator** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/base_classes/NXmonitor.rst b/_sphinx/source/volume2/NXDL/base_classes/NXmonitor.rst deleted file mode 100644 index 74c4f10e7..000000000 --- a/_sphinx/source/volume2/NXDL/base_classes/NXmonitor.rst +++ /dev/null @@ -1,77 +0,0 @@ -.. _NXmonitor: - -######### -NXmonitor -######### - -.. index:: ! . NXDL base_classes; NXmonitor - -category: - base_classes - -NXDL source: - NXmonitor - - (http://svn.nexusformat.org/definitions/trunk/base_classes/NXmonitor.nxdl.xml) - -version: - 1.0 - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - :ref:`NXgeometry`, :ref:`NXlog` - -documentation: - Template of monitor data. It is similar to the NXdata groups containing - monitor data and its associated dimension scale, e.g. time_of_flight or - wavelength in pulsed neutron instruments. However, it may also include - integrals, or scalar monitor counts, which are often used in both in both - pulsed and steady-state instrumentation. - - - -.. rubric:: Basic Structure of **NXmonitor** - -.. code-block:: text - :linenos: - - NXmonitor (base class, version 1.0) - count_time:NX_FLOAT - data:NX_NUMBER[n] - @signal - @axes - distance:NX_FLOAT - efficiency:NX_NUMBER[] - end_time:NX_DATE_TIME - integral:NX_NUMBER - mode:NX_CHAR - preset:NX_NUMBER - range:NX_FLOAT[2] - sampled_fraction:NX_FLOAT - start_time:NX_DATE_TIME - time_of_flight:NX_FLOAT[] - type:NX_CHAR - NXgeometry - integral_log:NXlog - - -.. rubric:: Symbols used in definition of **NXmonitor** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXmonitor** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/base_classes/NXmonochromator.rst b/_sphinx/source/volume2/NXDL/base_classes/NXmonochromator.rst deleted file mode 100644 index b6f5d0843..000000000 --- a/_sphinx/source/volume2/NXDL/base_classes/NXmonochromator.rst +++ /dev/null @@ -1,72 +0,0 @@ -.. _NXmonochromator: - -############### -NXmonochromator -############### - -.. index:: ! . NXDL base_classes; NXmonochromator - -category: - base_classes - -NXDL source: - NXmonochromator - - (http://svn.nexusformat.org/definitions/trunk/base_classes/NXmonochromator.nxdl.xml) - -version: - 1.0 - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - :ref:`NXcrystal`, :ref:`NXdata`, :ref:`NXgeometry`, :ref:`NXvelocity_selector` - -documentation: - This is a base class for everything which - selects a wavelength or energy, be it a monochromator crystal, a velocity selector, - a undulator or whatever. - - The expected units are: - - wavelength: angstrom - - energy: eV - - - -.. rubric:: Basic Structure of **NXmonochromator** - -.. code-block:: text - :linenos: - - NXmonochromator (base class, version 1.0) - energy:NX_FLOAT - energy_error:NX_FLOAT - wavelength:NX_FLOAT - wavelength_error:NX_FLOAT - NXcrystal - distribution:NXdata - geometry:NXgeometry - NXvelocity_selector - - -.. rubric:: Symbols used in definition of **NXmonochromator** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXmonochromator** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/base_classes/NXnote.rst b/_sphinx/source/volume2/NXDL/base_classes/NXnote.rst deleted file mode 100644 index 4800e9484..000000000 --- a/_sphinx/source/volume2/NXDL/base_classes/NXnote.rst +++ /dev/null @@ -1,63 +0,0 @@ -.. _NXnote: - -###### -NXnote -###### - -.. index:: ! . NXDL base_classes; NXnote - -category: - base_classes - -NXDL source: - NXnote - - (http://svn.nexusformat.org/definitions/trunk/base_classes/NXnote.nxdl.xml) - -version: - 1.0 - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - none - -documentation: - This class can be used to store additional information in a - NeXus file e.g. pictures, movies, audio, additional text logs - - - -.. rubric:: Basic Structure of **NXnote** - -.. code-block:: text - :linenos: - - NXnote (base class, version 1.0) - author:NX_CHAR - data:NX_BINARY - date:NX_DATE_TIME - description:NX_CHAR - file_name:NX_CHAR - type:NX_CHAR - - -.. rubric:: Symbols used in definition of **NXnote** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXnote** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/base_classes/NXobject.rst b/_sphinx/source/volume2/NXDL/base_classes/NXobject.rst deleted file mode 100644 index 5cdc279d3..000000000 --- a/_sphinx/source/volume2/NXDL/base_classes/NXobject.rst +++ /dev/null @@ -1,56 +0,0 @@ -.. _NXobject: - -######## -NXobject -######## - -.. index:: ! . NXDL base_classes; NXobject - -category: - base_classes - -NXDL source: - NXobject - - (http://svn.nexusformat.org/definitions/trunk/base_classes/NXobject.nxdl.xml) - -version: - 1.0 - -SVN Id: - $Id$ - -extends class: - none - -other classes included: - none - -documentation: - This is the base object of NeXus - - - -.. rubric:: Basic Structure of **NXobject** - -.. code-block:: text - :linenos: - - NXobject (base class, version 1.0) - - -.. rubric:: Symbols used in definition of **NXobject** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXobject** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/base_classes/NXorientation.rst b/_sphinx/source/volume2/NXDL/base_classes/NXorientation.rst deleted file mode 100644 index 5faf5d4f9..000000000 --- a/_sphinx/source/volume2/NXDL/base_classes/NXorientation.rst +++ /dev/null @@ -1,59 +0,0 @@ -.. _NXorientation: - -############# -NXorientation -############# - -.. index:: ! . NXDL base_classes; NXorientation - -category: - base_classes - -NXDL source: - NXorientation - - (http://svn.nexusformat.org/definitions/trunk/base_classes/NXorientation.nxdl.xml) - -version: - 1.0 - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - :ref:`NXgeometry` - -documentation: - This is the description for a general orientation of a component - it is used by the - NXgeometry class - - - -.. rubric:: Basic Structure of **NXorientation** - -.. code-block:: text - :linenos: - - NXorientation (base class, version 1.0) - value:NX_FLOAT[numobj,6] - NXgeometry - - -.. rubric:: Symbols used in definition of **NXorientation** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXorientation** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/base_classes/NXparameters.rst b/_sphinx/source/volume2/NXDL/base_classes/NXparameters.rst deleted file mode 100644 index ba82dc2cc..000000000 --- a/_sphinx/source/volume2/NXDL/base_classes/NXparameters.rst +++ /dev/null @@ -1,58 +0,0 @@ -.. _NXparameters: - -############ -NXparameters -############ - -.. index:: ! . NXDL base_classes; NXparameters - -category: - base_classes - -NXDL source: - NXparameters - - (http://svn.nexusformat.org/definitions/trunk/base_classes/NXparameters.nxdl.xml) - -version: - 1.0 - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - none - -documentation: - Container for parameters, usually used in processing or analysis. - - - -.. rubric:: Basic Structure of **NXparameters** - -.. code-block:: text - :linenos: - - NXparameters (base class, version 1.0) - term:NX_CHAR - @units - - -.. rubric:: Symbols used in definition of **NXparameters** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXparameters** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/base_classes/NXpolarizer.rst b/_sphinx/source/volume2/NXDL/base_classes/NXpolarizer.rst deleted file mode 100644 index 1cd513ba6..000000000 --- a/_sphinx/source/volume2/NXDL/base_classes/NXpolarizer.rst +++ /dev/null @@ -1,62 +0,0 @@ -.. _NXpolarizer: - -########### -NXpolarizer -########### - -.. index:: ! . NXDL base_classes; NXpolarizer - -category: - base_classes - -NXDL source: - NXpolarizer - - (http://svn.nexusformat.org/definitions/trunk/base_classes/NXpolarizer.nxdl.xml) - -version: - 1.0 - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - none - -documentation: - Template of a beamline spin polarizer. - - This is a draft and is subject to revision. - - - -.. rubric:: Basic Structure of **NXpolarizer** - -.. code-block:: text - :linenos: - - NXpolarizer (base class, version 1.0) - composition:NX_CHAR - efficiency:NX_FLOAT - reflection:NX_INT[3] - type:NX_CHAR - - -.. rubric:: Symbols used in definition of **NXpolarizer** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXpolarizer** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/base_classes/NXpositioner.rst b/_sphinx/source/volume2/NXDL/base_classes/NXpositioner.rst deleted file mode 100644 index 4899c581a..000000000 --- a/_sphinx/source/volume2/NXDL/base_classes/NXpositioner.rst +++ /dev/null @@ -1,74 +0,0 @@ -.. _NXpositioner: - -############ -NXpositioner -############ - -.. index:: ! . NXDL base_classes; NXpositioner - -category: - base_classes - -NXDL source: - NXpositioner - - (http://svn.nexusformat.org/definitions/trunk/base_classes/NXpositioner.nxdl.xml) - -version: - 1.0 - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - none - -documentation: - This group describes a generic positioner - such as a motor or piezo-electric transducer. It is used to document the - current information of a piece of beam line equipment. - Note: When using multiple NXpositioner groups, it is suggested to place - them inside a NXcollection group. In such cases, when - NXpositioner is used in another class, - NXcollection/NXpositioner - is then constructed. - - - -.. rubric:: Basic Structure of **NXpositioner** - -.. code-block:: text - :linenos: - - NXpositioner (base class, version 1.0) - acceleration_time:NX_NUMBER - controller_record:NX_CHAR - description:NX_CHAR - name:NX_CHAR - raw_value:NX_NUMBER[n] - soft_limit_max:NX_NUMBER - soft_limit_min:NX_NUMBER - target_value:NX_NUMBER[n] - tolerance:NX_NUMBER[n] - value:NX_NUMBER[n] - velocity:NX_NUMBER - - -.. rubric:: Symbols used in definition of **NXpositioner** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXpositioner** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/base_classes/NXprocess.rst b/_sphinx/source/volume2/NXDL/base_classes/NXprocess.rst deleted file mode 100644 index 5e350b5db..000000000 --- a/_sphinx/source/volume2/NXDL/base_classes/NXprocess.rst +++ /dev/null @@ -1,60 +0,0 @@ -.. _NXprocess: - -######### -NXprocess -######### - -.. index:: ! . NXDL base_classes; NXprocess - -category: - base_classes - -NXDL source: - NXprocess - - (http://svn.nexusformat.org/definitions/trunk/base_classes/NXprocess.nxdl.xml) - -version: - 1.0 - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - :ref:`NXnote` - -documentation: - Document an event of data processing, reconstruction, or analysis for this data. - - - -.. rubric:: Basic Structure of **NXprocess** - -.. code-block:: text - :linenos: - - NXprocess (base class, version 1.0) - date:NX_DATE_TIME - program:NX_CHAR - version:NX_CHAR - NXnote - - -.. rubric:: Symbols used in definition of **NXprocess** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXprocess** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/base_classes/NXroot.rst b/_sphinx/source/volume2/NXDL/base_classes/NXroot.rst deleted file mode 100644 index 0af12c194..000000000 --- a/_sphinx/source/volume2/NXDL/base_classes/NXroot.rst +++ /dev/null @@ -1,89 +0,0 @@ -.. _NXroot: - -###### -NXroot -###### - -.. index:: ! . NXDL base_classes; NXroot - -category: - base_classes - -NXDL source: - NXroot - - (http://svn.nexusformat.org/definitions/trunk/base_classes/NXroot.nxdl.xml) - -version: - 1.0 - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - :ref:`NXentry` - -documentation: - Definition of the root NeXus group. - - - -.. rubric:: Basic Structure of **NXroot** - -.. code-block:: text - :linenos: - - NXroot (base class, version 1.0) - @NX_class - @file_time - @file_name - @file_update_time - @NeXus_version - @HDF_version - @HDF5_Version - @XML_version - @creator - NXentry - - -.. rubric:: Symbols used in definition of **NXroot** - -No symbols are defined in this NXDL file - - - -.. rubric:: Attributes of ``definition`` element in **NXroot** - -+-------------------+---------+-------+--------------------------------+ -| Attributes | Type | Units | Description (and Occurrences) | -+===================+=========+=======+================================+ -| @NX_class | NX_CHAR | .. | .. | -+-------------------+---------+-------+--------------------------------+ -| @file_time | NX_CHAR | .. | .. | -+-------------------+---------+-------+--------------------------------+ -| @file_name | NX_CHAR | .. | .. | -+-------------------+---------+-------+--------------------------------+ -| @file_update_time | NX_CHAR | .. | .. | -+-------------------+---------+-------+--------------------------------+ -| @NeXus_version | NX_CHAR | .. | .. | -+-------------------+---------+-------+--------------------------------+ -| @HDF_version | NX_CHAR | .. | .. | -+-------------------+---------+-------+--------------------------------+ -| @HDF5_Version | NX_CHAR | .. | .. | -+-------------------+---------+-------+--------------------------------+ -| @XML_version | NX_CHAR | .. | .. | -+-------------------+---------+-------+--------------------------------+ -| @creator | NX_CHAR | .. | .. | -+-------------------+---------+-------+--------------------------------+ - - -.. rubric:: Comprehensive Structure of **NXroot** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/base_classes/NXsample.rst b/_sphinx/source/volume2/NXDL/base_classes/NXsample.rst deleted file mode 100644 index b3bca535c..000000000 --- a/_sphinx/source/volume2/NXDL/base_classes/NXsample.rst +++ /dev/null @@ -1,118 +0,0 @@ -.. _NXsample: - -######## -NXsample -######## - -.. index:: ! . NXDL base_classes; NXsample - -category: - base_classes - -NXDL source: - NXsample - - (http://svn.nexusformat.org/definitions/trunk/base_classes/NXsample.nxdl.xml) - -version: - 1.0 - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - :ref:`NXbeam`, :ref:`NXdata`, :ref:`NXenvironment`, :ref:`NXgeometry`, :ref:`NXlog` - -documentation: - Template of the state of the sample. This could include scanned variables that - are associated with one of the data dimensions, e.g. the magnetic field, or - logged data, e.g. monitored temperature vs elapsed time. - - - -.. rubric:: Basic Structure of **NXsample** - -.. code-block:: text - :linenos: - - NXsample (base class, version 1.0) - changer_position:NX_INT - chemical_formula:NX_CHAR - component:NX_CHAR - concentration:NX_FLOAT[n_comp] - density:NX_FLOAT[n_comp] - description:NX_CHAR - distance:NX_FLOAT - electric_field:NX_FLOAT[n_eField] - @direction - external_DAC:NX_FLOAT - magnetic_field:NX_FLOAT[n_mField] - @direction - mass:NX_FLOAT[n_comp] - name:NX_CHAR - orientation_matrix:NX_FLOAT[n_comp,3,3] - path_length:NX_FLOAT - path_length_window:NX_FLOAT - preparation_date:NX_DATE_TIME - pressure:NX_FLOAT[n_pField] - relative_molecular_mass:NX_FLOAT[n_comp] - rotation_angle:NX_FLOAT - sample_component:NX_CHAR - sample_orientation:NX_FLOAT[3] - scattering_length_density:NX_FLOAT[n_comp] - short_title:NX_CHAR - situation:NX_CHAR - stress_field:NX_FLOAT[n_sField] - @direction - temperature:NX_FLOAT[n_Temp] - thickness:NX_FLOAT - type:NX_CHAR - unit_cell:NX_FLOAT[n_comp,6] - unit_cell_class:NX_CHAR - unit_cell_group:NX_CHAR - unit_cell_volume:NX_FLOAT[n_comp] - volume_fraction:NX_FLOAT[n_comp] - x_translation:NX_FLOAT - NXbeam - transmission:NXdata - temperature_env:NXenvironment - magnetic_field_env:NXenvironment - geometry:NXgeometry - temperature_log:NXlog - magnetic_field_log:NXlog - external_ADC:NXlog - - -.. rubric:: Symbols used in definition of **NXsample** - -symbolic array lengths to be coordinated between various fields - -+--------------+--------------------------------------------+ -| Symbol | Description | -+==============+============================================+ -| ``n_comp`` | number of compositions | -+--------------+--------------------------------------------+ -| ``n_Temp`` | number of temperatures | -+--------------+--------------------------------------------+ -| ``n_eField`` | number of values in applied electric field | -+--------------+--------------------------------------------+ -| ``n_mField`` | number of values in applied magnetic field | -+--------------+--------------------------------------------+ -| ``n_pField`` | number of values in applied pressure field | -+--------------+--------------------------------------------+ -| ``n_sField`` | number of values in applied stress field | -+--------------+--------------------------------------------+ - - - - -.. rubric:: Comprehensive Structure of **NXsample** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/base_classes/NXsensor.rst b/_sphinx/source/volume2/NXDL/base_classes/NXsensor.rst deleted file mode 100644 index 5325279e8..000000000 --- a/_sphinx/source/volume2/NXDL/base_classes/NXsensor.rst +++ /dev/null @@ -1,75 +0,0 @@ -.. _NXsensor: - -######## -NXsensor -######## - -.. index:: ! . NXDL base_classes; NXsensor - -category: - base_classes - -NXDL source: - NXsensor - - (http://svn.nexusformat.org/definitions/trunk/base_classes/NXsensor.nxdl.xml) - -version: - 1.0 - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - :ref:`NXgeometry`, :ref:`NXlog`, :ref:`NXorientation` - -documentation: - This class describes a sensor used to monitor an external condition - - the condition itself is described in NXenvironment - - - -.. rubric:: Basic Structure of **NXsensor** - -.. code-block:: text - :linenos: - - NXsensor (base class, version 1.0) - attached_to:NX_CHAR - external_field_brief:NX_CHAR - high_trip_value:NX_FLOAT - low_trip_value:NX_FLOAT - measurement:NX_CHAR - model:NX_CHAR - name:NX_CHAR - run_control:NX_BOOLEAN - short_name:NX_CHAR - type:NX_CHAR - value:NX_FLOAT[n] - value_deriv1:NX_FLOAT[] - value_deriv2:NX_FLOAT[] - geometry:NXgeometry - value_log:NXlog - value_deriv1_log:NXlog - value_deriv2_log:NXlog - external_field_full:NXorientation - - -.. rubric:: Symbols used in definition of **NXsensor** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXsensor** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/base_classes/NXshape.rst b/_sphinx/source/volume2/NXDL/base_classes/NXshape.rst deleted file mode 100644 index 0dc834df5..000000000 --- a/_sphinx/source/volume2/NXDL/base_classes/NXshape.rst +++ /dev/null @@ -1,61 +0,0 @@ -.. _NXshape: - -####### -NXshape -####### - -.. index:: ! . NXDL base_classes; NXshape - -category: - base_classes - -NXDL source: - NXshape - - (http://svn.nexusformat.org/definitions/trunk/base_classes/NXshape.nxdl.xml) - -version: - 1.0 - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - none - -documentation: - This is the description of the general shape and size of a - component, which may be made up of "numobj" separate - elements - it is used by the NXgeometry class - - - -.. rubric:: Basic Structure of **NXshape** - -.. code-block:: text - :linenos: - - NXshape (base class, version 1.0) - direction:NX_CHAR - shape:NX_CHAR - size:NX_FLOAT[numobj,nshapepar] - - -.. rubric:: Symbols used in definition of **NXshape** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXshape** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/base_classes/NXsource.rst b/_sphinx/source/volume2/NXDL/base_classes/NXsource.rst deleted file mode 100644 index 239f7868c..000000000 --- a/_sphinx/source/volume2/NXDL/base_classes/NXsource.rst +++ /dev/null @@ -1,87 +0,0 @@ -.. _NXsource: - -######## -NXsource -######## - -.. index:: ! . NXDL base_classes; NXsource - -category: - base_classes - -NXDL source: - NXsource - - (http://svn.nexusformat.org/definitions/trunk/base_classes/NXsource.nxdl.xml) - -version: - 1.0 - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - :ref:`NXdata`, :ref:`NXgeometry`, :ref:`NXnote` - -documentation: - Template of the neutron or x-ray source, insertion devices and/or moderators. - - - -.. rubric:: Basic Structure of **NXsource** - -.. code-block:: text - :linenos: - - NXsource (base class, version 1.0) - bunch_distance:NX_FLOAT - bunch_length:NX_FLOAT - current:NX_FLOAT - distance:NX_FLOAT - emittance_x:NX_FLOAT - emittance_y:NX_FLOAT - energy:NX_FLOAT - flux:NX_FLOAT - frequency:NX_FLOAT - last_fill:NX_NUMBER - @time - mode:NX_CHAR - name:NX_CHAR - @short_name - number_of_bunches:NX_INT - period:NX_FLOAT - power:NX_FLOAT - probe:NX_CHAR - pulse_width:NX_FLOAT - sigma_x:NX_FLOAT - sigma_y:NX_FLOAT - target_material:NX_CHAR - top_up:NX_BOOLEAN - type:NX_CHAR - voltage:NX_FLOAT - bunch_pattern:NXdata - title:NX_CHAR - pulse_shape:NXdata - distribution:NXdata - geometry:NXgeometry - notes:NXnote - - -.. rubric:: Symbols used in definition of **NXsource** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXsource** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/base_classes/NXsubentry.rst b/_sphinx/source/volume2/NXDL/base_classes/NXsubentry.rst deleted file mode 100644 index d93625c4d..000000000 --- a/_sphinx/source/volume2/NXDL/base_classes/NXsubentry.rst +++ /dev/null @@ -1,120 +0,0 @@ -.. _NXsubentry: - -########## -NXsubentry -########## - -.. index:: ! . NXDL base_classes; NXsubentry - -category: - base_classes - -NXDL source: - NXsubentry - - (http://svn.nexusformat.org/definitions/trunk/base_classes/NXsubentry.nxdl.xml) - -version: - 1.0 - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - :ref:`NXcharacterization`, :ref:`NXdata`, :ref:`NXinstrument`, :ref:`NXmonitor`, :ref:`NXnote`, :ref:`NXprocess`, :ref:`NXsample`, :ref:`NXuser` - -documentation: - NXsubentry is a base class virtually identical to NXentry - and is used as the (overlay) location for application definitions. - Use a separate NXsubentry for each application definition. - - To use NXsubentry with a hypothetical application definition - called NXmyappdef: - - Create a group with attribute - NX_class="NXsubentry". - - Within that group, create a field called - definition="NXmyappdef". - - There are two optional attributes of definition: - version and URL - - The intended use is to define application definitions for a - multi-technique NXentry. Previously, an application definition - replaced NXentry with its own definition. - With the increasing popularity of instruments combining - multiple techniques for data collection (such as SAXS/WAXS instruments), - it was recognized the application definitions must be entered in the NeXus - data file tree as children of NXentry. - - - -.. rubric:: Basic Structure of **NXsubentry** - -.. code-block:: text - :linenos: - - NXsubentry (base class, version 1.0) - @IDF_Version - collection_description:NX_CHAR - collection_identifier:NX_CHAR - collection_time:NX_FLOAT - definition:NX_CHAR - @version - @URL - definition_local:NX_CHAR - @version - @URL - duration:NX_INT - end_time:NX_DATE_TIME - entry_identifier:NX_CHAR - experiment_description:NX_CHAR - experiment_identifier:NX_CHAR - pre_sample_flightpath:NX_FLOAT - program_name:NX_CHAR - @version - @configuration - revision:NX_CHAR - @comment - run_cycle:NX_CHAR - start_time:NX_DATE_TIME - title:NX_CHAR - NXcharacterization - NXdata - NXinstrument - NXmonitor - experiment_documentation:NXnote - notes:NXnote - thumbnail:NXnote - @mime_type - NXprocess - NXsample - NXuser - - -.. rubric:: Symbols used in definition of **NXsubentry** - -No symbols are defined in this NXDL file - - - -.. rubric:: Attributes of ``definition`` element in **NXsubentry** - -+--------------+---------+-------+--------------------------------+ -| Attributes | Type | Units | Description (and Occurrences) | -+==============+=========+=======+================================+ -| @IDF_Version | NX_CHAR | .. | .. | -+--------------+---------+-------+--------------------------------+ - - -.. rubric:: Comprehensive Structure of **NXsubentry** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/base_classes/NXtranslation.rst b/_sphinx/source/volume2/NXDL/base_classes/NXtranslation.rst deleted file mode 100644 index 1a1e6a888..000000000 --- a/_sphinx/source/volume2/NXDL/base_classes/NXtranslation.rst +++ /dev/null @@ -1,59 +0,0 @@ -.. _NXtranslation: - -############# -NXtranslation -############# - -.. index:: ! . NXDL base_classes; NXtranslation - -category: - base_classes - -NXDL source: - NXtranslation - - (http://svn.nexusformat.org/definitions/trunk/base_classes/NXtranslation.nxdl.xml) - -version: - 1.0 - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - :ref:`NXgeometry` - -documentation: - This is the description for the general spatial location - of a component - it is used by the NXgeometry class - - - -.. rubric:: Basic Structure of **NXtranslation** - -.. code-block:: text - :linenos: - - NXtranslation (base class, version 1.0) - distances:NX_FLOAT[numobj,3] - geometry:NXgeometry - - -.. rubric:: Symbols used in definition of **NXtranslation** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXtranslation** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/base_classes/NXuser.rst b/_sphinx/source/volume2/NXDL/base_classes/NXuser.rst deleted file mode 100644 index 954d3e11e..000000000 --- a/_sphinx/source/volume2/NXDL/base_classes/NXuser.rst +++ /dev/null @@ -1,67 +0,0 @@ -.. _NXuser: - -###### -NXuser -###### - -.. index:: ! . NXDL base_classes; NXuser - -category: - base_classes - -NXDL source: - NXuser - - (http://svn.nexusformat.org/definitions/trunk/base_classes/NXuser.nxdl.xml) - -version: - 1.0 - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - none - -documentation: - Template of user's contact information. The format allows more - than one user with the same affiliation and contact information, - but a second NXuser group should be used if they have different - affiliations, etc. - - - -.. rubric:: Basic Structure of **NXuser** - -.. code-block:: text - :linenos: - - NXuser (base class, version 1.0) - address:NX_CHAR - affiliation:NX_CHAR - email:NX_CHAR - facility_user_id:NX_CHAR - fax_number:NX_CHAR - name:NX_CHAR - role:NX_CHAR - telephone_number:NX_CHAR - - -.. rubric:: Symbols used in definition of **NXuser** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXuser** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/base_classes/NXvelocity_selector.rst b/_sphinx/source/volume2/NXDL/base_classes/NXvelocity_selector.rst deleted file mode 100644 index 1260e4cba..000000000 --- a/_sphinx/source/volume2/NXDL/base_classes/NXvelocity_selector.rst +++ /dev/null @@ -1,69 +0,0 @@ -.. _NXvelocity_selector: - -################### -NXvelocity_selector -################### - -.. index:: ! . NXDL base_classes; NXvelocity_selector - -category: - base_classes - -NXDL source: - NXvelocity_selector - - (http://svn.nexusformat.org/definitions/trunk/base_classes/NXvelocity_selector.nxdl.xml) - -version: - 1.0 - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - :ref:`NXgeometry` - -documentation: - This is the description for a (typically neutron) velocity selector - - - -.. rubric:: Basic Structure of **NXvelocity_selector** - -.. code-block:: text - :linenos: - - NXvelocity_selector (base class, version 1.0) - height:NX_FLOAT - length:NX_FLOAT - num:NX_INT - radius:NX_FLOAT - rotation_speed:NX_FLOAT - spwidth:NX_FLOAT - table:NX_FLOAT - twist:NX_FLOAT - type:NX_CHAR - wavelength:NX_FLOAT - wavelength_spread:NX_FLOAT - width:NX_FLOAT - geometry:NXgeometry - - -.. rubric:: Symbols used in definition of **NXvelocity_selector** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXvelocity_selector** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/base_classes/NXxraylens.rst b/_sphinx/source/volume2/NXDL/base_classes/NXxraylens.rst deleted file mode 100644 index 9b4cf3075..000000000 --- a/_sphinx/source/volume2/NXDL/base_classes/NXxraylens.rst +++ /dev/null @@ -1,70 +0,0 @@ -.. _NXxraylens: - -########## -NXxraylens -########## - -.. index:: ! . NXDL base_classes; NXxraylens - -category: - base_classes - -NXDL source: - NXxraylens - - (http://svn.nexusformat.org/definitions/trunk/base_classes/NXxraylens.nxdl.xml) - -version: - 1.0 - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - :ref:`NXnote` - -documentation: - This is a dictionary of field names to use dor describing a X-ray lens as used at - synchrotron beam lines. Based on information provided by Gerd Wellenreuther. - - - -.. rubric:: Basic Structure of **NXxraylens** - -.. code-block:: text - :linenos: - - NXxraylens (base class, version 1.0) - aperture:NX_FLOAT - curvature:NX_FLOAT - cylindrical:NX_BOOLEAN - focus_type:NX_CHAR - gas:NX_CHAR - gas_pressure:NX_FLOAT - lens_geometry:NX_CHAR - lens_length:NX_FLOAT - lens_material:NX_CHAR - lens_thickness:NX_FLOAT - number_of_lenses:NX_INT - symmetric:NX_BOOLEAN - cylinder_orientation:NXnote - - -.. rubric:: Symbols used in definition of **NXxraylens** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXxraylens** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/base_classes/index.rst b/_sphinx/source/volume2/NXDL/base_classes/index.rst deleted file mode 100644 index 451b6d975..000000000 --- a/_sphinx/source/volume2/NXDL/base_classes/index.rst +++ /dev/null @@ -1,14 +0,0 @@ -.. $Id$ - -################## -NeXus Base Classes -################## - -Contents: - -.. toctree:: - :maxdepth: 2 - :numbered: - :glob: - - NX* diff --git a/_sphinx/source/volume2/NXDL/contributed_definitions/NXbeamline.rst b/_sphinx/source/volume2/NXDL/contributed_definitions/NXbeamline.rst deleted file mode 100644 index caef6ae52..000000000 --- a/_sphinx/source/volume2/NXDL/contributed_definitions/NXbeamline.rst +++ /dev/null @@ -1,67 +0,0 @@ -.. _NXbeamline: - -########## -NXbeamline -########## - -.. index:: ! . NXDL contributed_definitions; NXbeamline - -category: - contributed_definitions - -NXDL source: - NXbeamline - - (http://svn.nexusformat.org/definitions/trunk/contributed_definitions/NXbeamline.nxdl.xml) - -version: - 1.0 - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - :ref:`NXaperture`, :ref:`NXbending_magnet`, :ref:`NXcollection`, :ref:`NXelectrostatic_kicker`, :ref:`NXmagnetic_kicker`, :ref:`NXquadrupole_magnet`, :ref:`NXseparator`, :ref:`NXsolenoid_magnet`, :ref:`NXspin_rotator` - -documentation: - container for elements describing beamline. - - - -.. rubric:: Basic Structure of **NXbeamline** - -.. code-block:: text - :linenos: - - NXbeamline (contributed definition, version 1.0) - (base class definition, NXentry or NXsubentry not found) - beamline:NX_CHAR - NXaperture - NXbending_magnet - diagnostics:NXcollection - NXelectrostatic_kicker - NXmagnetic_kicker - NXquadrupole_magnet - NXseparator - NXsolenoid_magnet - NXspin_rotator - - -.. rubric:: Symbols used in definition of **NXbeamline** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXbeamline** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/contributed_definitions/NXelectrostatic_kicker.rst b/_sphinx/source/volume2/NXDL/contributed_definitions/NXelectrostatic_kicker.rst deleted file mode 100644 index 521579cab..000000000 --- a/_sphinx/source/volume2/NXDL/contributed_definitions/NXelectrostatic_kicker.rst +++ /dev/null @@ -1,67 +0,0 @@ -.. _NXelectrostatic_kicker: - -###################### -NXelectrostatic_kicker -###################### - -.. index:: ! . NXDL contributed_definitions; NXelectrostatic_kicker - -category: - contributed_definitions - -NXDL source: - NXelectrostatic_kicker - - (http://svn.nexusformat.org/definitions/trunk/contributed_definitions/NXelectrostatic_kicker.nxdl.xml) - -version: - 1.0 - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - :ref:`NXlog` - -documentation: - definition for a electrostatic kicker. - - - -.. rubric:: Basic Structure of **NXelectrostatic_kicker** - -.. code-block:: text - :linenos: - - NXelectrostatic_kicker (contributed definition, version 1.0) - (base class definition, NXentry or NXsubentry not found) - beamline_distance:NX_FLOAT - description:NX_CHAR - set_current:NX_FLOAT - set_voltage:NX_FLOAT - timing:NX_FLOAT - @description - read_current:NXlog - value:NX_CHAR - read_voltage:NXlog - value:NX_CHAR - - -.. rubric:: Symbols used in definition of **NXelectrostatic_kicker** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXelectrostatic_kicker** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/contributed_definitions/NXmagnetic_kicker.rst b/_sphinx/source/volume2/NXDL/contributed_definitions/NXmagnetic_kicker.rst deleted file mode 100644 index ce23b844e..000000000 --- a/_sphinx/source/volume2/NXDL/contributed_definitions/NXmagnetic_kicker.rst +++ /dev/null @@ -1,67 +0,0 @@ -.. _NXmagnetic_kicker: - -################# -NXmagnetic_kicker -################# - -.. index:: ! . NXDL contributed_definitions; NXmagnetic_kicker - -category: - contributed_definitions - -NXDL source: - NXmagnetic_kicker - - (http://svn.nexusformat.org/definitions/trunk/contributed_definitions/NXmagnetic_kicker.nxdl.xml) - -version: - 1.0 - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - :ref:`NXlog` - -documentation: - definition for a magnetic kicker. - - - -.. rubric:: Basic Structure of **NXmagnetic_kicker** - -.. code-block:: text - :linenos: - - NXmagnetic_kicker (contributed definition, version 1.0) - (base class definition, NXentry or NXsubentry not found) - beamline_distance:NX_FLOAT - description:NX_CHAR - set_current:NX_FLOAT - set_voltage:NX_FLOAT - timing:NX_FLOAT - @description - read_current:NXlog - value:NX_CHAR - read_voltage:NXlog - value:NX_CHAR - - -.. rubric:: Symbols used in definition of **NXmagnetic_kicker** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXmagnetic_kicker** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/contributed_definitions/NXquadrupole_magnet.rst b/_sphinx/source/volume2/NXDL/contributed_definitions/NXquadrupole_magnet.rst deleted file mode 100644 index 8cbc9241c..000000000 --- a/_sphinx/source/volume2/NXDL/contributed_definitions/NXquadrupole_magnet.rst +++ /dev/null @@ -1,64 +0,0 @@ -.. _NXquadrupole_magnet: - -################### -NXquadrupole_magnet -################### - -.. index:: ! . NXDL contributed_definitions; NXquadrupole_magnet - -category: - contributed_definitions - -NXDL source: - NXquadrupole_magnet - - (http://svn.nexusformat.org/definitions/trunk/contributed_definitions/NXquadrupole_magnet.nxdl.xml) - -version: - 1.0 - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - :ref:`NXlog` - -documentation: - definition for a quadrupole magnet. - - - -.. rubric:: Basic Structure of **NXquadrupole_magnet** - -.. code-block:: text - :linenos: - - NXquadrupole_magnet (contributed definition, version 1.0) - (base class definition, NXentry or NXsubentry not found) - beamline_distance:NX_FLOAT - description:NX_CHAR - set_current:NX_FLOAT - read_current:NXlog - value:NX_CHAR - read_voltage:NXlog - value:NX_CHAR - - -.. rubric:: Symbols used in definition of **NXquadrupole_magnet** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXquadrupole_magnet** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/contributed_definitions/NXsai_controller.rst b/_sphinx/source/volume2/NXDL/contributed_definitions/NXsai_controller.rst deleted file mode 100644 index a73980a49..000000000 --- a/_sphinx/source/volume2/NXDL/contributed_definitions/NXsai_controller.rst +++ /dev/null @@ -1,62 +0,0 @@ -.. _NXsai_controller: - -################ -NXsai_controller -################ - -.. index:: ! . NXDL contributed_definitions; NXsai_controller - -category: - contributed_definitions - -NXDL source: - NXsai_controller - - (http://svn.nexusformat.org/definitions/trunk/contributed_definitions/NXsai_controller.nxdl.xml) - -version: - 1.0 - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - :ref:`NXtechnical_data` - -documentation: - (definition implied by usage) Subclass of NXinstrument used by Soleil. This class appears - in the example data files provided from Soleil. This class should be considered as a base - class (and relocated there, once approved by the NIAC). - - - -.. rubric:: Basic Structure of **NXsai_controller** - -.. code-block:: text - :linenos: - - NXsai_controller (contributed definition, version 1.0) - (base class definition, NXentry or NXsubentry not found) - Frequency:NXtechnical_data - IntegrationTime:NXtechnical_data - TriggerNumber:NXtechnical_data - - -.. rubric:: Symbols used in definition of **NXsai_controller** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXsai_controller** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/contributed_definitions/NXseparator.rst b/_sphinx/source/volume2/NXDL/contributed_definitions/NXseparator.rst deleted file mode 100644 index 7d5796a85..000000000 --- a/_sphinx/source/volume2/NXDL/contributed_definitions/NXseparator.rst +++ /dev/null @@ -1,69 +0,0 @@ -.. _NXseparator: - -########### -NXseparator -########### - -.. index:: ! . NXDL contributed_definitions; NXseparator - -category: - contributed_definitions - -NXDL source: - NXseparator - - (http://svn.nexusformat.org/definitions/trunk/contributed_definitions/NXseparator.nxdl.xml) - -version: - 1.0 - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - :ref:`NXlog` - -documentation: - definition for an electrostatic separator. - - - -.. rubric:: Basic Structure of **NXseparator** - -.. code-block:: text - :linenos: - - NXseparator (contributed definition, version 1.0) - (base class definition, NXentry or NXsubentry not found) - beamline_distance:NX_FLOAT - description:NX_CHAR - set_Bfield_current:NX_FLOAT - set_Efield_voltage:NX_FLOAT - read_Bfield_current:NXlog - value:NX_CHAR - read_Bfield_voltage:NXlog - value:NX_CHAR - read_Efield_current:NXlog - value:NX_CHAR - read_Efield_voltage:NXlog - value:NX_CHAR - - -.. rubric:: Symbols used in definition of **NXseparator** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXseparator** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/contributed_definitions/NXsnsevent.rst b/_sphinx/source/volume2/NXDL/contributed_definitions/NXsnsevent.rst deleted file mode 100644 index 4020bc250..000000000 --- a/_sphinx/source/volume2/NXDL/contributed_definitions/NXsnsevent.rst +++ /dev/null @@ -1,191 +0,0 @@ -.. _NXsnsevent: - -########## -NXsnsevent -########## - -.. index:: ! . NXDL contributed_definitions; NXsnsevent - -category: - contributed_definitions - -NXDL source: - NXsnsevent - - (http://svn.nexusformat.org/definitions/trunk/contributed_definitions/NXsnsevent.nxdl.xml) - -version: - 1.0 - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - :ref:`NXaperture`, :ref:`NXattenuator`, :ref:`NXcollection`, :ref:`NXcrystal`, :ref:`NXdata`, :ref:`NXdetector`, :ref:`NXdisk_chopper`, :ref:`NXentry`, :ref:`NXevent_data`, :ref:`NXgeometry`, :ref:`NXinstrument`, :ref:`NXlog`, :ref:`NXmoderator`, :ref:`NXmonitor`, :ref:`NXnote`, :ref:`NXorientation`, :ref:`NXpolarizer`, :ref:`NXpositioner`, :ref:`NXsample`, :ref:`NXshape`, :ref:`NXsource`, :ref:`NXtranslation`, :ref:`NXuser` - -documentation: - This is a definition for event data from Spallation Neutron Source (SNS) at ORNL. - - - -.. rubric:: Basic Structure of **NXsnsevent** - -.. code-block:: text - :linenos: - - NXsnsevent (contributed definition, version 1.0) - (overlays NXentry) - NXentry - collection_identifier:NX_CHAR - collection_title:NX_CHAR - definition:NX_CHAR - duration:NX_FLOAT - end_time:NX_DATE_TIME - entry_identifier:NX_CHAR - experiment_identifier:NX_CHAR - notes:NX_CHAR - proton_charge:NX_FLOAT - raw_frames:NX_INT - run_number:NX_CHAR - start_time:NX_DATE_TIME - title:NX_CHAR - total_counts:NX_UINT - total_uncounted_counts:NX_UINT - DASlogs:NXcollection - NXlog - average_value:NX_FLOAT - average_value_error:NX_FLOAT - description:NX_CHAR - duration:NX_FLOAT - maximum_value:NX_FLOAT - minimum_value:NX_FLOAT - time:NX_FLOAT[nvalue] - value:NX_FLOAT[nvalue] - NXpositioner - average_value:NX_FLOAT - average_value_error:NX_FLOAT - description:NX_CHAR - duration:NX_FLOAT - maximum_value:NX_FLOAT - minimum_value:NX_FLOAT - time:NX_FLOAT[numvalue] - value:NX_FLOAT[numvalue] - NXdata - data_x_y --> /NXentry/NXinstrument/NXdetector/data_x_y - x_pixel_offset --> /NXentry/NXinstrument/NXdetector/x_pixel_offset - y_pixel_offset --> /NXentry/NXinstrument/NXdetector/y_pixel_offset - NXevent_data - event_index --> /NXentry/NXinstrument/NXdetector/event_index - event_pixel_id --> /NXentry/NXinstrument/NXdetector/event_pixel_id - event_time_of_flight --> /NXentry/NXinstrument/NXdetector/event_time_of_flight - pulse_time --> /NXentry/NXinstrument/NXdetector/pulse_time - instrument:NXinstrument - SNSdetector_calibration_id:NX_CHAR - SNSgeometry_file_name:NX_CHAR - SNStranslation_service:NX_CHAR - beamline:NX_CHAR - name:NX_CHAR - NXaperture - x_pixel_offset:NX_FLOAT - origin:NXgeometry - orientation:NXorientation - value:NX_FLOAT[6] - shape:NXshape - description:NX_CHAR - shape:NX_CHAR - size:NX_FLOAT[3] - translation:NXtranslation - distance:NX_FLOAT[3] - NXattenuator - distance:NX_FLOAT - NXcrystal - type:NX_CHAR - wavelength:NX_FLOAT - origin:NXgeometry - description:NX_CHAR - orientation:NXorientation - value:NX_FLOAT[6] - shape:NXshape - description:NX_CHAR - shape:NX_CHAR - size:NX_FLOAT - translation:NXtranslation - distance:NX_FLOAT[3] - NXdetector - azimuthal_angle:NX_FLOAT[numx,numy] - data_x_y:NX_UINT[numx,numy] - distance:NX_FLOAT[numx,numy] - event_index:NX_UINT[numpulses] - event_pixel_id:NX_UINT[numevents] - event_time_of_flight:NX_FLOAT[numevents] - pixel_id:NX_UINT[numx,numy] - polar_angle:NX_FLOAT[numx,numy] - pulse_time:NX_FLOAT[numpulses] - total_counts:NX_UINT - x_pixel_offset:NX_FLOAT[numx] - y_pixel_offset:NX_FLOAT[numy] - origin:NXgeometry - orientation:NXorientation - value:NX_FLOAT[6] - shape:NXshape - description:NX_CHAR - shape:NX_CHAR - size:NX_FLOAT[3] - translation:NXtranslation - distance:NX_FLOAT[3] - NXdisk_chopper - distance:NX_FLOAT - moderator:NXmoderator - coupling_material:NX_CHAR - distance:NX_FLOAT - temperature:NX_FLOAT - type:NX_CHAR - NXpolarizer - SNS:NXsource - frequency:NX_FLOAT - name:NX_CHAR - probe:NX_CHAR - type:NX_CHAR - NXmonitor - data:NX_UINT[numtimechannels] - distance:NX_FLOAT - mode:NX_CHAR - time_of_flight:NX_FLOAT[numtimechannels + 1] - SNSHistoTool:NXnote - SNSbanking_file_name:NX_CHAR - SNSmapping_file_name:NX_CHAR - author:NX_CHAR - command1:NX_CHAR - date:NX_CHAR - description:NX_CHAR - version:NX_CHAR - sample:NXsample - changer_position:NX_CHAR - holder:NX_CHAR - identifier:NX_CHAR - name:NX_CHAR - nature:NX_CHAR - NXuser - facility_user_id:NX_CHAR - name:NX_CHAR - role:NX_CHAR - - -.. rubric:: Symbols used in definition of **NXsnsevent** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXsnsevent** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/contributed_definitions/NXsnshisto.rst b/_sphinx/source/volume2/NXDL/contributed_definitions/NXsnshisto.rst deleted file mode 100644 index ce514b939..000000000 --- a/_sphinx/source/volume2/NXDL/contributed_definitions/NXsnshisto.rst +++ /dev/null @@ -1,194 +0,0 @@ -.. _NXsnshisto: - -########## -NXsnshisto -########## - -.. index:: ! . NXDL contributed_definitions; NXsnshisto - -category: - contributed_definitions - -NXDL source: - NXsnshisto - - (http://svn.nexusformat.org/definitions/trunk/contributed_definitions/NXsnshisto.nxdl.xml) - -version: - 1.0 - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - :ref:`NXaperture`, :ref:`NXattenuator`, :ref:`NXcollection`, :ref:`NXcrystal`, :ref:`NXdata`, :ref:`NXdetector`, :ref:`NXdisk_chopper`, :ref:`NXentry`, :ref:`NXfermi_chopper`, :ref:`NXgeometry`, :ref:`NXinstrument`, :ref:`NXlog`, :ref:`NXmoderator`, :ref:`NXmonitor`, :ref:`NXnote`, :ref:`NXorientation`, :ref:`NXpolarizer`, :ref:`NXpositioner`, :ref:`NXsample`, :ref:`NXshape`, :ref:`NXsource`, :ref:`NXtranslation`, :ref:`NXuser` - -documentation: - This is a definition for histogram data from Spallation Neutron Source (SNS) at ORNL. - - - -.. rubric:: Basic Structure of **NXsnshisto** - -.. code-block:: text - :linenos: - - NXsnshisto (contributed definition, version 1.0) - (overlays NXentry) - NXentry - collection_identifier:NX_CHAR - collection_title:NX_CHAR - definition:NX_CHAR - duration:NX_FLOAT - end_time:NX_DATE_TIME - entry_identifier:NX_CHAR - experiment_identifier:NX_CHAR - notes:NX_CHAR - proton_charge:NX_FLOAT - raw_frames:NX_INT - run_number:NX_CHAR - start_time:NX_DATE_TIME - title:NX_CHAR - total_counts:NX_UINT - total_uncounted_counts:NX_UINT - DASlogs:NXcollection - NXlog - average_value:NX_FLOAT - average_value_error:NX_FLOAT - description:NX_CHAR - duration:NX_FLOAT - maximum_value:NX_FLOAT - minimum_value:NX_FLOAT - time:NX_FLOAT[nvalue] - value:NX_FLOAT[nvalue] - NXpositioner - average_value:NX_FLOAT - average_value_error:NX_FLOAT - description:NX_CHAR - duration:NX_FLOAT - maximum_value:NX_FLOAT - minimum_value:NX_FLOAT - time:NX_FLOAT[numvalue] - value:NX_FLOAT[numvalue] - NXdata - data --> /NXentry/NXinstrument/NXdetector/data - data_x_time_of_flight --> /NXentry/NXinstrument/NXdetector/data_x_time_of_flight - data_x_y --> /NXentry/NXinstrument/NXdetector/data_x_y - data_y_time_of_flight --> /NXentry/NXinstrument/NXdetector/data_y_time_of_flight - pixel_id --> /NXentry/NXinstrument/NXdetector/pixel_id - time_of_flight --> /NXentry/NXinstrument/NXdetector/time_of_flight - total_counts --> /NXentry/NXinstrument/NXdetector/total_counts - x_pixel_offset --> /NXentry/NXinstrument/NXdetector/x_pixel_offset - y_pixel_offset --> /NXentry/NXinstrument/NXdetector/y_pixel_offset - instrument:NXinstrument - SNSdetector_calibration_id:NX_CHAR - SNSgeometry_file_name:NX_CHAR - SNStranslation_service:NX_CHAR - beamline:NX_CHAR - name:NX_CHAR - NXaperture - x_pixel_offset:NX_FLOAT - origin:NXgeometry - orientation:NXorientation - value:NX_FLOAT[6] - shape:NXshape - description:NX_CHAR - shape:NX_CHAR - size:NX_FLOAT[3] - translation:NXtranslation - distance:NX_FLOAT[3] - NXattenuator - distance:NX_FLOAT - NXcrystal - type:NX_CHAR - wavelength:NX_FLOAT - origin:NXgeometry - description:NX_CHAR - orientation:NXorientation - value:NX_FLOAT[6] - shape:NXshape - description:NX_CHAR - shape:NX_CHAR - size:NX_FLOAT - translation:NXtranslation - distance:NX_FLOAT[3] - NXdetector - azimuthal_angle:NX_FLOAT[numx,numy] - data:NX_UINT[numx,numy,numtof] - data_x_time_of_flight:NX_UINT[numx,numtof] - data_x_y:NX_UINT[numx,numy] - data_y_time_of_flight:NX_UINT[numy,numtof] - distance:NX_FLOAT[numx,numy] - pixel_id:NX_UINT[numx,numy] - polar_angle:NX_FLOAT[numx,numy] - time_of_flight:NX_FLOAT[numtof + 1] - total_counts:NX_UINT - x_pixel_offset:NX_FLOAT[numx] - y_pixel_offset:NX_FLOAT[numy] - origin:NXgeometry - orientation:NXorientation - value:NX_FLOAT[6] - shape:NXshape - description:NX_CHAR - shape:NX_CHAR - size:NX_FLOAT[3] - translation:NXtranslation - distance:NX_FLOAT[3] - NXdisk_chopper - distance:NX_FLOAT - NXfermi_chopper - distance:NX_FLOAT - moderator:NXmoderator - coupling_material:NX_CHAR - distance:NX_FLOAT - temperature:NX_FLOAT - type:NX_CHAR - NXpolarizer - SNS:NXsource - frequency:NX_FLOAT - name:NX_CHAR - probe:NX_CHAR - type:NX_CHAR - NXmonitor - data:NX_UINT[numtimechannels] - distance:NX_FLOAT - mode:NX_CHAR - time_of_flight:NX_FLOAT[numtimechannels + 1] - SNSHistoTool:NXnote - SNSbanking_file_name:NX_CHAR - SNSmapping_file_name:NX_CHAR - author:NX_CHAR - command1:NX_CHAR - date:NX_CHAR - description:NX_CHAR - version:NX_CHAR - sample:NXsample - changer_position:NX_CHAR - holder:NX_CHAR - identifier:NX_CHAR - name:NX_CHAR - nature:NX_CHAR - NXuser - facility_user_id:NX_CHAR - name:NX_CHAR - role:NX_CHAR - - -.. rubric:: Symbols used in definition of **NXsnshisto** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXsnshisto** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/contributed_definitions/NXsolenoid_magnet.rst b/_sphinx/source/volume2/NXDL/contributed_definitions/NXsolenoid_magnet.rst deleted file mode 100644 index d52821bcd..000000000 --- a/_sphinx/source/volume2/NXDL/contributed_definitions/NXsolenoid_magnet.rst +++ /dev/null @@ -1,64 +0,0 @@ -.. _NXsolenoid_magnet: - -################# -NXsolenoid_magnet -################# - -.. index:: ! . NXDL contributed_definitions; NXsolenoid_magnet - -category: - contributed_definitions - -NXDL source: - NXsolenoid_magnet - - (http://svn.nexusformat.org/definitions/trunk/contributed_definitions/NXsolenoid_magnet.nxdl.xml) - -version: - 1.0 - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - :ref:`NXlog` - -documentation: - definition for a solenoid magnet. - - - -.. rubric:: Basic Structure of **NXsolenoid_magnet** - -.. code-block:: text - :linenos: - - NXsolenoid_magnet (contributed definition, version 1.0) - (base class definition, NXentry or NXsubentry not found) - beamline_distance:NX_FLOAT - description:NX_CHAR - set_current:NX_FLOAT - read_current:NXlog - value:NX_CHAR - read_voltage:NXlog - value:NX_CHAR - - -.. rubric:: Symbols used in definition of **NXsolenoid_magnet** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXsolenoid_magnet** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/contributed_definitions/NXspin_rotator.rst b/_sphinx/source/volume2/NXDL/contributed_definitions/NXspin_rotator.rst deleted file mode 100644 index 9249e3d27..000000000 --- a/_sphinx/source/volume2/NXDL/contributed_definitions/NXspin_rotator.rst +++ /dev/null @@ -1,69 +0,0 @@ -.. _NXspin_rotator: - -############## -NXspin_rotator -############## - -.. index:: ! . NXDL contributed_definitions; NXspin_rotator - -category: - contributed_definitions - -NXDL source: - NXspin_rotator - - (http://svn.nexusformat.org/definitions/trunk/contributed_definitions/NXspin_rotator.nxdl.xml) - -version: - 1.0 - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - :ref:`NXlog` - -documentation: - definition for a spin rotator. - - - -.. rubric:: Basic Structure of **NXspin_rotator** - -.. code-block:: text - :linenos: - - NXspin_rotator (contributed definition, version 1.0) - (base class definition, NXentry or NXsubentry not found) - beamline_distance:NX_FLOAT - description:NX_CHAR - set_Bfield_current:NX_FLOAT - set_Efield_voltage:NX_FLOAT - read_Bfield_current:NXlog - value:NX_CHAR - read_Bfield_voltage:NXlog - value:NX_CHAR - read_Efield_current:NXlog - value:NX_CHAR - read_Efield_voltage:NXlog - value:NX_CHAR - - -.. rubric:: Symbols used in definition of **NXspin_rotator** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXspin_rotator** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/contributed_definitions/NXtechnical_data.rst b/_sphinx/source/volume2/NXDL/contributed_definitions/NXtechnical_data.rst deleted file mode 100644 index 54e3e3dc9..000000000 --- a/_sphinx/source/volume2/NXDL/contributed_definitions/NXtechnical_data.rst +++ /dev/null @@ -1,67 +0,0 @@ -.. _NXtechnical_data: - -################ -NXtechnical_data -################ - -.. index:: ! . NXDL contributed_definitions; NXtechnical_data - -category: - contributed_definitions - -NXDL source: - NXtechnical_data - - (http://svn.nexusformat.org/definitions/trunk/contributed_definitions/NXtechnical_data.nxdl.xml) - -version: - 1.0 - -SVN Id: - $Id$ - -extends class: - :ref:`NXobject` - -other classes included: - none - -documentation: - (definition implied by usage) Some measure of metadata not already considered by the other - base classes. This class appears in the example data files provided from Soleil. This class - should be considered as a base class (and relocated there, once approved by the NIAC). This - class is used by Soleil as a child of (at least) these classes: NXsai_controller, - NXdetector, NXsource - - - -.. rubric:: Basic Structure of **NXtechnical_data** - -.. code-block:: text - :linenos: - - NXtechnical_data (contributed definition, version 1.0) - (base class definition, NXentry or NXsubentry not found) - data:NX_NUMBER - @units - @timestamp - @description - description:NX_CHAR - @description - - -.. rubric:: Symbols used in definition of **NXtechnical_data** - -No symbols are defined in this NXDL file - - - - - -.. rubric:: Comprehensive Structure of **NXtechnical_data** - -+---------------------+----------+-------+-------------------------------+ -| Name and Attributes | Type | Units | Description (and Occurrences) | -+=====================+==========+=======+===============================+ -| class | NX_FLOAT | .. | .. | -+---------------------+----------+-------+-------------------------------+ diff --git a/_sphinx/source/volume2/NXDL/contributed_definitions/index.rst b/_sphinx/source/volume2/NXDL/contributed_definitions/index.rst deleted file mode 100644 index 0fe1c14bb..000000000 --- a/_sphinx/source/volume2/NXDL/contributed_definitions/index.rst +++ /dev/null @@ -1,14 +0,0 @@ -.. $Id$ - -##################################### -NeXus Contributed Definitions Classes -##################################### - -Contents: - -.. toctree:: - :maxdepth: 2 - :numbered: - :glob: - - NX* diff --git a/_sphinx/source/volume2/NXDL/index.rst b/_sphinx/source/volume2/NXDL/index.rst deleted file mode 100644 index f43e795ac..000000000 --- a/_sphinx/source/volume2/NXDL/index.rst +++ /dev/null @@ -1,15 +0,0 @@ -.. $Id$ - -####################### -NXDL Class Descriptions -####################### - -Contents: - -.. toctree:: - :maxdepth: 2 - :numbered: - - base_classes/index - applications/index - contributed_definitions/index diff --git a/_sphinx/source/volume2/index.rst b/_sphinx/source/volume2/index.rst deleted file mode 100755 index 668fcf2b3..000000000 --- a/_sphinx/source/volume2/index.rst +++ /dev/null @@ -1,15 +0,0 @@ -.. $Id$ - -.. _volume2.NXDL.section: - -############################## -NeXus: Reference Documentation -############################## - -Contents: - -.. toctree:: - :maxdepth: 2 - :numbered: - - NXDL/index diff --git a/impatient-guide/conf.py b/impatient-guide/conf.py index 8e35f4bdb..ed3fb2bac 100644 --- a/impatient-guide/conf.py +++ b/impatient-guide/conf.py @@ -104,7 +104,7 @@ # The name for this set of Sphinx documents. If None, it defaults to # " v documentation". -html_title = None +html_title = 'NeXus for the Impatient' # A shorter title for the navigation bar. Default is the same as html_title. html_short_title = project diff --git a/impatient-guide/index.rst b/impatient-guide/index.rst index 178880e3e..680b9330a 100644 --- a/impatient-guide/index.rst +++ b/impatient-guide/index.rst @@ -7,18 +7,16 @@ NeXus for the Impatient ####################### -Why NeXus? -=========== +Why NeXus? +========== .. seealso:: - This document is available in different formats: - `HTML (online) `_ - or - :download:`PDF `. - - .. - http://download.nexusformat.org/doc/impatient/ + This document is available online in + `HTML `_ + and + `PDF `_ + formats. The NeXus data format [#NeXus]_ is a tool which has been designed to solve the problems of travelling scientists, @@ -62,22 +60,22 @@ flexible NeXus Concepts -=============== +============== NeXus uses `HDF-5 `_ [#HDF5]_ files as container files. HDF-5 is a popular scientific -data format which has been developed by the National Center for Supercomputing -Applications (NCSA), University of Illinois Urbana-Champaign and is currently -being maintained by the HDF Group. There is built-in support for HDF-5 in many scientific +data format developed by the National Center for Supercomputing +Applications (NCSA), University of Illinois Urbana-Champaign and currently +maintained by *The HDF Group*. There is built-in support for HDF-5 in many scientific packages. Other users of HDF-5 include NASA, Boeing, meteorological offices around the world and many more. NeXus is thus able to inherit many desirable properties for free from HDF-5, such as: extendable, self-describing, platform independent, public domain, and efficient. For historical reasons, NeXus supports two further -container file formats: HDF-4 and XML. The use of these formats is now deprecated. +container file formats: HDF-4 and XML. The NeXus use of these formats is now deprecated. -In order to understand NeXus it is important to know about some of the objects -which live in an HDF-5 file: +To understand NeXus, it is important to know about some of the objects +encountered in an HDF-5 file: groups Allow structuring of information in a file. Groups work pretty much like @@ -94,7 +92,7 @@ links like symbolic links in a UNIX file system. HDF-5 does not, however, know anything about the application domain of neutron, muon or -x-ray scattering. In order to remedy this, NeXus adds the following: +X-ray scattering. In order to remedy this, NeXus adds the following: A group hierarchy in the HDF-5 file A group hierarchy in the files helps with a couple of issues. If a full beamline @@ -126,7 +124,7 @@ Tools The NeXus File Hierarchy -------------------------- +------------------------ NeXus defines two main group hierarchy types: @@ -134,14 +132,14 @@ NeXus defines two main group hierarchy types: #. :ref:`processed_data_hierarchy` There are additional hierarchy variations for multi-method instruments and for a -general purpose dump structure. Documentation for these hierarchy types and be +general purpose dump structure. Documentation for these hierarchy types can be found in the NeXus manual. .. _raw_file_hierarchy: The NeXus Raw Data File Hierarchy -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This hierarchy is applicable to raw data files as written by some facility instrument: @@ -149,16 +147,17 @@ This hierarchy is applicable to raw data files as written by some facility instr :linenos: entry:NXentry - data:NXdata - data --> /entry/instrument/detector/data - instrument:NXinstrument - source:NXsource - .... - detector:NXdetector - data:NX_INT32[512,512] - @signal = 1 - sample:NXsample - control:NXmonitor + @default = data + data:NXdata + @signal = data + data --> /entry/instrument/detector/data + instrument:NXinstrument + source:NXsource + .... + detector:NXdetector + data:NX_INT32[512,512] + sample:NXsample + control:NXmonitor @@ -194,7 +193,7 @@ The following two groups are required for all NeXus data files: Therefore the data is linked here from the specific detector entry recording the data which is described below. Axis information is usually included here as well, the - details of which are covered in the full manual. + details of which are covered in the NeXus manual. The following additional groups are present in many NeXus data files: @@ -228,16 +227,20 @@ The following additional groups are present in many NeXus data files: This describes a dataset with a given numeric type and dimensions. In this example, the detector data is a 512 x 512 array of 32-bit integers. ``@name=value`` - This describes an attribute name and value. The attribute signal=1 indicates - to NeXus that this is the dependent data to be plotted. + This describes an attribute name and value. + Both groups and fields can have attributes. + The attribute ``signal=data`` indicates + to NeXus that the field in this group named ``data`` is the dependent data to be plotted. ``name --> path`` Describes a link from one location to another. This allows us to gather the most important data together in an ``NXdata`` group while leaving detailed metadata in the individual component definitions. + NeXus uses HDF5 hard links for pointing to other objects in the same file + and external links when pointing to objects in other HDF5 files. What goes into a NeXus File? ------------------------------- +---------------------------- Before starting to describe how to decide what goes into a NeXus file, some more details about NeXus groups and base classes need to be @@ -319,7 +322,7 @@ and begin with a letter. .. _processed_data_hierarchy: The NeXus Processed Data Hierarchy -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This is a simplified hierarchy style applicable to the results of data reduction or data analysis applications. Such results can consist of @@ -330,22 +333,27 @@ for storing such data: :linenos: entry:NXentry - reduction:NXprocess - program_name = "pyDataProc2010" - version = "1.0a" - input:NXparameter - filename = "sn2013287.nxs" - sample:NXsample - data:NXdata - data - @signal = 1 + @entry = data + reduction:NXprocess + program_name = "pyDataProc2010" + version = "1.0a" + input:NXparameter + filename = "sn2013287.nxs" + sample:NXsample + data:NXdata + @signal = data + data -Here the NXentry contains: +Here the ``NXentry`` contains: +``@entry = data`` + Attribute on the ``NXentry`` group pointing to the default ``NXdata`` + group to be plotted. ``data:NXdata`` Contains the result of the data reduction directly, together with - the axes required to use the data. + the axes required to use the data. The attribute ``@signal = data`` + indicates that the field named ``data`` is the default plottable data. ``sample:NXsample`` Contains the sample information. This may be a link to the sample information within a measurement entry elsewhere in the file. @@ -364,7 +372,7 @@ in order to describe the instrument if this matters at this stage. Scans in NeXus ---------------- +-------------- Scanning means to vary some variable in a certain, defined way and collect data as the variable progresses. Scans are a versatile experimental technique and are @@ -388,43 +396,61 @@ sample is rotated and data is collected in an area detector: :linenos: entry:NXentry - instrument:NXinstrument - detector:NXdetector - data:[NP,xsize,ysize] - @signal = 1 - sample:NXsample - rotation_angle[NP] - @axis = 1 - control:NXmonitor - data[NP] - data:NXdata - data --> /entry/instrument/detector/data - rotation_angle --> /entry/sample/rotation_angle + @entry = data + instrument:NXinstrument + detector:NXdetector + data:[NP,xsize,ysize] + sample:NXsample + rotation_angle[NP] + control:NXmonitor + data[NP] + data:NXdata + @signal = 1 + @axes = rotation_angle . . + @rotation_angle_indices = 0 + data --> /entry/instrument/detector/data + rotation_angle --> /entry/sample/rotation_angle + +The default data to be plotted has more dimensions and requires +additional description. The attribute ``@axes = rotation_angle . .`` +implies that the "signal data" (``data``) has three dimensions. +The first dimension is provided by the ``rotation_angle`` field, +while the ``.`` for the other two dimensions indicates they each +should be plotted as index number (starting from zero). +The attribute ``@rotation_angle_indices = 0`` declares that ``rotation_angle`` +is used as the first dimension of ``data``. The ``AXISNAME_indices`` +attribute becomes more useful when both the "signal data" and the dimension +scales are multi-dimensional. Finding the plottable data -------------------------- Any program whose aim is to identify plottable data should use the following procedure: -#. Open the first top level NeXus group with class NXentry. -#. Open the first NeXus group with class NXdata. -#. Loop through NeXus fields in this group searching for the item with - attribute ``signal=1`` indicating this field has the plottable data. -#. Check to see if this field has an attribute called axes. If so, the - attribute value contains a colon (or comma) delimited list (in the - C-language order of the data array) with the names of the dimension - scales associated with the plottable data. - And then you can skip the next two steps. -#. If the axes attribute is not defined, search for the - one-dimensional NeXus fields with attribute ``primary=1``. -#. These are the dimension scales to label the axes of each dimension of the data. -#. Link each dimension scale to the respective data dimension by the axis - attribute (``axis=1``, ``axis=2``, ... up to the rank of the data). -#. If necessary, close the NXdata group, open the next one and repeat steps 3 to 6. -#. If necessary, close the NXentry group, open the next one and repeat steps 2 to 7. +#. Start at the top level of the NeXus data file + (the *root* of the HDF5 hierarchy). + +#. Pick the default ``NXentry`` group, as designated by the ``default`` attribute. + +#. Pick the default ``NXdata`` group, as designated by the ``default`` attribute. + +#. Pick the default plottable field, as designated by the ``signal`` attribute. + + #. Pick the fields with the dimension scales (the ``axes`` attribute). + + #. Associate dimension scales with plottable data dimensions (the ``AXISNAME_indices`` attributes). + + #. Associate the dimension scales with each dimension of the plottable data. + +#. Plot the *signal* data, given *axes* and *AXISNAME_indices*. + +For details of this process, consult this +`section `_ +of the NeXus manual. [#v3]_ + NeXus Benefits -================ +============== When trying to establish a data standard, we encounter a few challenges, some of which can slow effort: @@ -470,7 +496,7 @@ Application definitions Reading NeXus Files -==================== +=================== The simplest way to read and plot a NeXus file is through the Python *PyTree* API: @@ -594,11 +620,26 @@ Reading the file using the HDF-5 C API is a little more involved: } +.. note:: To keep these examples short, we already learned the HDF addresses + of the "signal data" (such as ``/entry1/data1/counts``) + and its associated dimension scales (such as ``/entry1/data1/two_theta``) + for each example data file. + The examples above use those addresses directly, rather than using the + described method to find the plottable data. + + If you are writing specific + code to process a set of NeXus files where you already know the HDF5 addresses + of the items you need, feel welcome to use that knowledge, as you have seen above. + + If you are writing code to handle any NeXus data file, then you are advised + to implement the methods to find the plottable data, + as described in the manual. [#v3]_ + More examples of reading NeXus data files can be found in the *Examples* chapter of the NeXus Reference Documentation. [#RefDoc]_ Writing NeXus Files -==================== +=================== You can obviously skip this section if you only wish to read NeXus files. @@ -618,35 +659,37 @@ two_theta: #include "napi.h" - int main() - { - NXhandle fileID; - NXopen ("NXfile.nxs", NXACC_CREATE, &fileID); - NXmakegroup (fileID, "Scan", "NXentry"); - NXopengroup (fileID, "Scan", "NXentry"); - NXmakegroup (fileID, "data", "NXdata"); - NXopengroup (fileID, "data", "NXdata"); - /* somehow, we already have arrays tth and counts, each length n*/ - NXmakedata (fileID, "two_theta", NX_FLOAT32, 1, &n); - NXopendata (fileID, "two_theta"); - NXputdata (fileID, tth); - NXputattr (fileID, "units", "degrees", 7, NX_CHAR); - NXclosedata (fileID); /* two_theta */ - NXmakedata (fileID, "counts", NX_FLOAT32, 1, &n); - NXopendata (fileID, "counts"); - NXputdata (fileID, counts); - NXclosedata (fileID); /* counts */ - NXclosegroup (fileID); /* data */ - NXclosegroup (fileID); /* Scan */ - NXclose (&fileID); - return; + int writer(float *tth, float *counts, int n) + { + /* we receive two arrays: tth and counts, each length n*/ + NXhandle fileID; + NXopen ("NXfile.nxs", NXACC_CREATE, &fileID); + NXmakegroup (fileID, "Scan", "NXentry"); + NXopengroup (fileID, "Scan", "NXentry"); + NXmakegroup (fileID, "data", "NXdata"); + NXopengroup (fileID, "data", "NXdata"); + NXputattr (fileID, "signal", "counts", 6, NX_CHAR); + NXputattr (fileID, "axes", "two_theta", 9, NX_CHAR); + NXmakedata (fileID, "two_theta", NX_FLOAT32, 1, &n); + NXopendata (fileID, "two_theta"); + NXputdata (fileID, tth); + NXputattr (fileID, "units", "degrees", 7, NX_CHAR); + NXclosedata (fileID); /* two_theta */ + NXmakedata (fileID, "counts", NX_FLOAT32, 1, &n); + NXopendata (fileID, "counts"); + NXputdata (fileID, counts); + NXclosedata (fileID); /* counts */ + NXclosegroup (fileID); /* data */ + NXclosegroup (fileID); /* Scan */ + NXclose (&fileID); + return; } More examples of writing NeXus data files can be found in the *Examples* chapter of the NeXus Reference Documentation. [#RefDoc]_ More Information -================= +================ Did we get you interested? Here is where you can get more information. Our main entry point is the NeXus WWW-site at http://www.nexusformat.org @@ -663,7 +706,7 @@ to lend us a hand, you are more welcome to contact us via nexus-committee@nexusf Who is behind NeXus? ---------------------- +-------------------- NeXus was developed from three independent proposals from Jonathan Tischler, APS, Przemek Klosowski, NIST and Mark Koennecke, ISIS (now PSI) by an @@ -690,3 +733,6 @@ find on the NeXus WWW site. .. [#RefDoc] NeXus Reference Documentation: http://download.nexusformat.org/doc/html/ReferenceDocumentation.html + +.. [#v3] Finding the plottable data: + http://download.nexusformat.org/doc/html/datarules.html#version-3 diff --git a/manual/source/datarules.rst b/manual/source/datarules.rst index d82dd2e6d..c8ee1e99a 100644 --- a/manual/source/datarules.rst +++ b/manual/source/datarules.rst @@ -522,9 +522,29 @@ plottable data is as follows: #. Loop through the groups with class ``NXentry`` until the next step succeeds. + .. compound:: + + .. _fig.flowchart-v2-NXroot-default: + + .. figure:: img/flowchart-v2-NXroot-default.png + :alt: fig.flowchart-v2-NXroot-default + :width: 60% + + Find plottable data: pick a ``NXentry`` group + #. Open the NXentry group and loop through the subgroups with class ``NXdata`` until the next step succeeds. + .. compound:: + + .. _fig.flowchart-v2-NXentry-default: + + .. figure:: img/flowchart-v2-NXentry-default.png + :alt: fig.flowchart-v2-NXentry-default + :width: 60% + + Find plottable data: pick a ``NXdata`` group + #. Open the NXdata group and loop through the fields for the one field with attribute ``signal="1"``. Note: There should be *only one* field that matches. @@ -561,6 +581,16 @@ plottable data is as follows: #. Having found the default plottable data and its dimension scales: make the plot. + .. compound:: + + .. _fig.flowchart-v2-NXdata-signal: + + .. figure:: img/flowchart-v2-NXdata-signal.png + :alt: fig.flowchart-v2-NXdata-signal + :width: 98% + + Find plottable data: select the *signal* data + .. _Find-Plottable-Data-v1: @@ -575,26 +605,37 @@ plottable data is as follows: #. Open the first top level NeXus group with class ``NXentry``. + .. compound:: + + .. _fig.flowchart-v1-NXroot-default: + + .. figure:: img/flowchart-v1-NXroot-default.png + :alt: fig.flowchart-v1-NXroot-default + :width: 60% + + Find plottable data: pick the first ``NXentry`` group + #. Open the first NeXus group with class ``NXdata``. + .. compound:: + + .. _fig.flowchart-v1-NXentry-default: + + .. figure:: img/flowchart-v1-NXentry-default.png + :alt: fig.flowchart-v1-NXentry-default + :width: 60% + + Find plottable data: pick the first ``NXdata`` group + #. Loop through NeXus fields in this group searching for the item with attribute ``signal="1"`` indicating this field has the plottable data. -#. Check to see if this field has an attribute called - ``axes``. If so, the attribute value contains a colon (or comma) - delimited list (in the C-order of the data array) with the names - of the - :index:`dimension scales ` - associated with the plottable data. And - then you can skip the next two steps. - -#. If the ``axes`` attribute is not defined, search for the +#. Search for the one-dimensional NeXus fields with attribute ``primary=1``. - -#. These are the dimension scales to label + These are the dimension scales to label the axes of each dimension of the data. #. Link each dimension scale @@ -602,13 +643,23 @@ plottable data is as follows: the ``axis`` attribute (``axis=1``, ``axis=2``, ... up to the :index:`rank ` of the data). -#. If necessary, close the + .. compound:: + + .. _fig.flowchart-v1-NXdata-signal: + + .. figure:: img/flowchart-v1-NXdata-signal.png + :alt: fig.flowchart-v1-NXdata-signal + :width: 98% + + Find plottable data: select the *signal* data + +#. If necessary, close this ``NXdata`` - group, open the next one and repeat steps 3 to 6. + group, search the next ``NXdata`` group, repeating steps 3 to 5. #. If necessary, close the ``NXentry`` - group, open the next one and repeat steps 2 to 7. + group, search the next ``NXentry`` group, repeating steps 2 to 6. .. index:: dimension diff --git a/manual/source/img/flowchart-plottable-data.vsdx b/manual/source/img/flowchart-plottable-data.vsdx index e340a285d..75436f94c 100644 Binary files a/manual/source/img/flowchart-plottable-data.vsdx and b/manual/source/img/flowchart-plottable-data.vsdx differ diff --git a/manual/source/img/flowchart-v1-NXdata-signal.png b/manual/source/img/flowchart-v1-NXdata-signal.png new file mode 100644 index 000000000..df7145fb5 Binary files /dev/null and b/manual/source/img/flowchart-v1-NXdata-signal.png differ diff --git a/manual/source/img/flowchart-v1-NXentry-default.png b/manual/source/img/flowchart-v1-NXentry-default.png new file mode 100644 index 000000000..21d8923af Binary files /dev/null and b/manual/source/img/flowchart-v1-NXentry-default.png differ diff --git a/manual/source/img/flowchart-v1-NXroot-default.png b/manual/source/img/flowchart-v1-NXroot-default.png new file mode 100644 index 000000000..d977ab287 Binary files /dev/null and b/manual/source/img/flowchart-v1-NXroot-default.png differ diff --git a/manual/source/img/flowchart-v2-NXdata-signal.png b/manual/source/img/flowchart-v2-NXdata-signal.png new file mode 100644 index 000000000..c9b1d3f64 Binary files /dev/null and b/manual/source/img/flowchart-v2-NXdata-signal.png differ diff --git a/manual/source/img/flowchart-v2-NXentry-default.png b/manual/source/img/flowchart-v2-NXentry-default.png new file mode 100644 index 000000000..21d8923af Binary files /dev/null and b/manual/source/img/flowchart-v2-NXentry-default.png differ diff --git a/manual/source/img/flowchart-v2-NXroot-default.png b/manual/source/img/flowchart-v2-NXroot-default.png new file mode 100644 index 000000000..d977ab287 Binary files /dev/null and b/manual/source/img/flowchart-v2-NXroot-default.png differ diff --git a/manual/source/index.rst b/manual/source/index.rst index 8e693b676..67f339beb 100644 --- a/manual/source/index.rst +++ b/manual/source/index.rst @@ -29,19 +29,22 @@ This manual built |today|. .. seealso:: - This document is available in these formats: + This document is available in these formats online: - :online HTML: + :HTML: http://download.nexusformat.org/doc/html/index.html - .. 2015-05-29,prj: PDF available separately - :PDF: - :download:`nexus.pdf` (available via online HTML link above) + :PDF: + http://download.nexusformat.org/doc/NeXusManual.pdf - A very brief overview is also available (separate from the manual). + A very brief overview (title: *NeXus for the Impatient*) + is also available (separate from the manual). :HTML: - http://download.nexusformat.org/doc/impatient/ + http://download.nexusformat.org/doc/impatient + + :PDF: + http://download.nexusformat.org/doc/NXImpatient.pdf .. Suggestions for adding to this manual: diff --git a/manual/source/introduction.rst b/manual/source/introduction.rst index dd4e514fb..cf38e3c9f 100644 --- a/manual/source/introduction.rst +++ b/manual/source/introduction.rst @@ -166,14 +166,14 @@ Example of a NeXus File The following diagram shows an example of a NeXus data file represented as a tree structure. - .. compound:: - - .. _Figure.Example_NeXus_file: - - .. rubric:: Example of a NeXus Data File - - .. image:: img/Hierarchy.png - :width: 80% +.. compound:: + + .. _Figure.Example_NeXus_file: + + .. rubric:: Example of a NeXus Data File + + .. image:: img/Hierarchy.png + :width: 80% Note that each field is identified by a name, such as ``counts``, @@ -238,25 +238,25 @@ complete list can be found in the :ref:`Design` chapter. .. index:: NXinstrument (base class) :ref:`NXinstrument` - There might also be a group with - class ``NXinstrument``. This is designed to encapsulate all the - instrumental information that might be relevant to a - measurement, such as flight paths, collimation, chopper - frequencies, etc. - - .. compound:: - - .. _Figure.NXinstrument_excerpt: - - .. rubric:: ``NXinstrument`` excerpt - - .. image:: img/NXinstrument.png - :width: 50% - - Since an instrument can include several beamline components each - defined by several parameters, the components are each specified by a separate group. - This hides the complexity from generic file browsers, but makes the - information available in an intuitively obvious way if it is required. + There might also be a group with + class ``NXinstrument``. This is designed to encapsulate all the + instrumental information that might be relevant to a + measurement, such as flight paths, collimation, chopper + frequencies, etc. + + .. compound:: + + .. _Figure.NXinstrument_excerpt: + + .. rubric:: ``NXinstrument`` excerpt + + .. image:: img/NXinstrument.png + :width: 50% + + Since an instrument can include several beamline components each + defined by several parameters, the components are each specified by a separate group. + This hides the complexity from generic file browsers, but makes the + information available in an intuitively obvious way if it is required. .. _Introduction-SimpleExample: @@ -275,14 +275,14 @@ that could be used to transfer data between programs. (Later in this section, we show how to write and read this simple example.) - .. compound:: - - .. _fig.simple-example: - - .. rubric:: Example structure of a simple data file - - .. image:: img/Simple.png - :width: 60% +.. compound:: + + .. _fig.simple-example: + + .. rubric:: Example structure of a simple data file + + .. image:: img/Simple.png + :width: 60% This illustrates the fact that the structure of NeXus files is @@ -291,16 +291,16 @@ information, if required, but it can also be used to store very simple data sets. Here is the structure of a very simple NeXus data file (:download:`examples/verysimple.nx5`): - .. compound:: - - .. _fig.verysimple-structure: - - .. rubric:: Structure of a very simple NeXus Data file - - .. literalinclude:: examples/verysimple.txt - :tab-width: 4 - :linenos: - :language: text +.. compound:: + + .. _fig.verysimple-structure: + + .. rubric:: Structure of a very simple NeXus Data file + + .. literalinclude:: examples/verysimple.txt + :tab-width: 4 + :linenos: + :language: text .. index:: NeXpy @@ -308,28 +308,28 @@ sets. Here is the structure of a very simple NeXus data file NeXus files are easy to visualize. Here, this data is plotted using *NeXPy* simply by opening the NeXus data file and double-clicking the file name in the list: - .. compound:: - - .. _fig.verysimple-png: +.. compound:: + + .. _fig.verysimple-png: - .. rubric:: Plot of a very simple NeXus HDF5 Data file + .. rubric:: Plot of a very simple NeXus HDF5 Data file - .. image:: img/verysimple.png - :width: 60% + .. image:: img/verysimple.png + :width: 60% NeXus files are easy to create. This example NeXus file was created using a short Python program and the *h5py* package: - .. compound:: - - .. _fig.verysimple-py: - - .. rubric:: Using Python to write a very simple NeXus HDF5 Data file - - .. literalinclude:: examples/verysimple.py - :tab-width: 4 - :linenos: - :language: guess +.. compound:: + + .. _fig.verysimple-py: + + .. rubric:: Using Python to write a very simple NeXus HDF5 Data file + + .. literalinclude:: examples/verysimple.py + :tab-width: 4 + :linenos: + :language: guess .. _Introduction-DataStorageObjects: @@ -366,14 +366,14 @@ the simple NeXus file shown above. .. compound:: - .. _fig.verysimple.nxdl.xml: - - .. rubric:: A very simple NeXus Definition Language (NXDL) file - - .. literalinclude:: examples/verysimple.nxdl.xml - :tab-width: 4 - :linenos: - :language: guess + .. _fig.verysimple.nxdl.xml: + + .. rubric:: A very simple NeXus Definition Language (NXDL) file + + .. literalinclude:: examples/verysimple.nxdl.xml + :tab-width: 4 + :linenos: + :language: guess Complete examples of reading and writing NeXus data files are provided :ref:`later `. @@ -407,14 +407,14 @@ would contain lines similar to the following: .. compound:: - .. _fig.ex-simple.c: - - .. rubric:: Simple example of reading data using the NeXus API - - .. literalinclude:: examples/ex-simple.c - :tab-width: 4 - :linenos: - :language: guess + .. _fig.ex-simple.c: + + .. rubric:: Simple example of reading data using the NeXus API + + .. literalinclude:: examples/ex-simple.c + :tab-width: 4 + :linenos: + :language: guess In this example, the program requests the value of the data that has the label ``wavelength``, storing the result in the variable lambda. diff --git a/www/index.html b/www/index.html index 69230540f..9d6ff0fa4 100755 --- a/www/index.html +++ b/www/index.html @@ -27,7 +27,7 @@
Tutorial
Getting started with NeXus, - NeXus for the Impatient + NeXus for the Impatient
Support