diff --git a/doc/html/.buildinfo b/doc/html/.buildinfo
index 1a99ee12..615489fd 100644
--- a/doc/html/.buildinfo
+++ b/doc/html/.buildinfo
@@ -1,4 +1,4 @@
# Sphinx build info version 1
# This file hashes the configuration used when building these files. When it is not found, a full rebuild will be done.
-config: 1c72e3ac8764a6fbfdf66c0cdf797d3d
+config: fae482e1a3134e03efb428cbbe21a254
tags: 645f666f9bcd5a90fca523b33c5a78b7
diff --git a/doc/html/_downloads/Makefile.TMyLibrary b/doc/html/_downloads/c06f924ba301a43e83dbbdfcfaf54ada/Makefile.TMyLibrary
similarity index 100%
rename from doc/html/_downloads/Makefile.TMyLibrary
rename to doc/html/_downloads/c06f924ba301a43e83dbbdfcfaf54ada/Makefile.TMyLibrary
diff --git a/doc/html/_images/musredit-musrWiz.svg b/doc/html/_images/musredit-musrWiz.svg
index 848be6a9..4739c193 100644
--- a/doc/html/_images/musredit-musrWiz.svg
+++ b/doc/html/_images/musredit-musrWiz.svg
@@ -1,6 +1,4 @@
-
-
diff --git a/doc/html/_images/musrview2dat.svg b/doc/html/_images/musrview2dat.svg
new file mode 100644
index 00000000..88315c22
--- /dev/null
+++ b/doc/html/_images/musrview2dat.svg
@@ -0,0 +1,259 @@
+
+
diff --git a/doc/html/_sources/acknowledgement.rst.txt b/doc/html/_sources/acknowledgement.rst.txt
new file mode 100644
index 00000000..7e8c47fa
--- /dev/null
+++ b/doc/html/_sources/acknowledgement.rst.txt
@@ -0,0 +1,22 @@
+.. include::
+.. index:: acknowledgment
+
+.. _acknowledgment:
+
+Acknowledgements
+================
+
+
+**Bastian M. Wojek**
+ I am very much indebted to BMW for his rigorous testing of ``musrfit``, his many useful suggestions, contributions, and for the
+ largest part of the user manual of ``musrfit`` which makes it accessible to a broader audience! Many thanks Bastian!
+
+**Uldis Locans**
+ I am very much indebted to Uldis work on :ref:`DKS ` enabling the GPU support for ``musrfit``. His kind, calm, and
+ extremely competent way to deal with his projects as well as to deal with the chaos of physicists way to think is admirable. Many thanks Uldis!
+
+**Zaher Salman**
+ Thanks for his beta-NMR and web-interface contributions to ``musrfit``!
+
+**Robert Scheuermann**
+ Thanks for his constant contructive input on ``musrfit``!
diff --git a/doc/html/_sources/any2many.rst.txt b/doc/html/_sources/any2many.rst.txt
new file mode 100644
index 00000000..6b5fd201
--- /dev/null
+++ b/doc/html/_sources/any2many.rst.txt
@@ -0,0 +1,8 @@
+.. include::
+.. index:: any2many
+
+any2many - a Universal |mgr|\SR-file-format converter
+=====================================================
+
+``any2many`` allows to convert most |mgr|\SR-file-formats from one to the other.
+For a detailed description see :ref:`here `.
\ No newline at end of file
diff --git a/doc/html/_sources/bugtracking.rst.txt b/doc/html/_sources/bugtracking.rst.txt
new file mode 100644
index 00000000..55a5ff54
--- /dev/null
+++ b/doc/html/_sources/bugtracking.rst.txt
@@ -0,0 +1,9 @@
+.. index:: bugtracking
+.. _bugtracking:
+
+Bugtracking
+===========
+
+For reporting bugs or requesting new features and improvements please use
+the `bitbucket-repo `_ (preferred)
+or send an e-mail to A. Suter at PSI.
diff --git a/doc/html/_sources/cite.rst.txt b/doc/html/_sources/cite.rst.txt
new file mode 100644
index 00000000..5a71e6f1
--- /dev/null
+++ b/doc/html/_sources/cite.rst.txt
@@ -0,0 +1,18 @@
+.. include::
+.. index:: cite
+.. _cite:
+
+How to Cite ``musrfit``?
+========================
+
+Since quite some effort is going into the development and maintenance of the ``musrfit`` package, you should at least acknowledge it in your publication if you have used it to analyze your data. Even better of course is to cite it properly by the reference given beneath
+
+ * A.\ Suter, B.M. Wojek, "Musrfit: A Free Platform-Independent Framework for |mgr|\SR Data Analysis", Physics Procedia **30**, 69 (2012). ``_
+
+The GPU high speed ``musrfit`` version is utilizing ``DKS``. In case you are using this version, please also add the following citations
+
+ * A.\ Adelmann, U. Locans, A. Suter, "The Dynamic Kernel Scheduler—Part 1", Computer Physics Communications **207**, 83 (2016). ``_
+ * U.\ Locans, *et al.*, "Real-time computation of parameter fitting and image reconstruction using graphical processing units", Computer Physics Communications **215**, 71 (2017). ``_
+ * U.\ Locans and A.\ Suter, "Musrfit – Real Time Parameter Fitting Using GPUs", JPS Conf. Proc. *21*, 011051 (2018). ``_
+
+
diff --git a/doc/html/_sources/file-formats.rst.txt b/doc/html/_sources/file-formats.rst.txt
new file mode 100644
index 00000000..bc01bc33
--- /dev/null
+++ b/doc/html/_sources/file-formats.rst.txt
@@ -0,0 +1,389 @@
+.. include::
+.. index:: file-formats
+.. _file-formats:
+
+Short description and references to the supported file-formats
+==============================================================
+
+Currently the following |mgr|\SR and non-|mgr|\SR file formats are supported (in alphabetic order):
+
+* ascii (non-|mgr|\SR): :ref:`ASCII file format for non-u\SR `
+* db (non-|mgr|\SR): :ref:`DB (triumf) `
+* dat (non-|mgr|\SR): :ref:`DAT: CSV like data file `
+* mdu (|mgr|\SR): :ref:`MDU file format (PSI) `
+* mud (|mgr|\SR): :ref:`MUon Data access file format (TRIUMF) `
+* musr-root (|mgr|\SR): :ref:`MusrRoot - an Extensible Open File Format for uSR `
+* nexus (|mgr|\SR): used to read NeXus files from ISIS (HDF4 and HDF5): :ref:`NeXus `
+* psi-bin (|mgr|\SR): :ref:`PSI-BIN file format (PSI) `
+* root (|mgr|\SR): specific version for LEM before 2012 :ref:`LEM ROOT file format`
+* wkm (|mgr|\SR): special ascii file format used in the past by the TU Braunschweig (outdated): :ref:`WKM `
+
+.. index:: ascii-file-format
+.. _ascii-file-format:
+
+ASCII file format for non-|mgr|\SR
+----------------------------------
+
+This for instance can be used to fit :math:`1/\lambda^2 ~ \mathrm{vs} ~ T` to study gap properties of superconductors.
+Details about the gap-intergrals can be found in the memo *GapIntegrals.pdf* which can be found in the source code of musrfit
+under /src/external/libGapIntegrals.
+
+This primitive file format has the following structure:
+
+Comment lines start with a '#' or '%' character.
+The file can start with some header info. The header is optional, as all its tags, but
+if present it has the following format:
+
+::
+
+ HEADER
+ TITLE: title
+ X-AXIS-TITLE: x-axis title
+ Y-AXIS-TITLE: y-axis title
+ SETUP: setup
+ FIELD: field
+ TEMP: temperature
+ ENERGY: energy
+
+Field has to be given in (G), temperature in (K) and energy in (keV).
+
+The data are read column like and start with the data tag DATA, followed by the
+data columns, i.e.:
+
+::
+
+ DATA
+ x, y [, error y]
+
+where spaces, column, are a tab are possible separations.
+If no error in y is present, the weighting in the fit will be equal.
+
+A full example might look like this:
+
+::
+
+ # libGapIntegrals-test.dat
+ # This is a comment
+ % This as well
+ HEADER
+ TITLE: Test superconductor data
+ X-AXIS-TITLE: T (K)
+ Y-AXIS-TITLE: #lambda^{-2} (#mum^{-2})
+ SETUP: H #parallel c
+ FIELD: 100
+ TEMP: 0.0
+ ENERGY: 4200
+ # here the data will follow
+ DATA
+ # x, y, error y
+ 0.0318411, 7.77455, 0.2
+ 0.0629929, 7.9869, 0.15
+ 0.113914, 7.64209, 0.15
+ 0.202492, 7.37699, 0.15
+ 0.302725, 7.70893, 0.12
+ 0.447456, 7.77565, 0.12
+ 0.611685, 7.45768, 0.12
+ 0.813613, 7.19287, 0.12
+ 1.00822, 7.57813, 0.12
+ 1.24793, 7.31343, 0.12
+ 1.50635, 7.16818, 0.12
+ 1.74591, 6.99634, 0.12
+ 1.99795, 6.90414, 0.12
+ 2.25061, 6.41393, 0.12
+ 2.4958, 6.66666, 0.12
+ 2.75514, 5.93766, 0.12
+ 3.00753, 5.61992, 0.12
+ 3.26056, 4.89091, 0.12
+ 3.49414, 4.52005, 0.08
+ 3.75356, 3.73799, 0.08
+ 3.99425, 2.84974, 0.08
+ 4.30518, 1.35139, 0.08
+
+
+.. index:: db-file-format
+.. _db-file-format:
+
+DB file format for non-|mgr|\SR
+-------------------------------
+
+The DB file format is an *archaic* ascii file format from TRIUMF which is intended to be used to collect parameter summaries of various runs, which can be read directly by :ref:`mupp `.
+
+The DB file is organized in a couple of tags defining various properties, followed by the parameter data with its errors.
+Tags and is content are always separated by an empty line.
+The first tag is the **TITLE**. Followed by the title in the next line
+
+::
+
+ TITLE
+ This is the best data ever
+
+The next tag is the **ABSTRACT**, followed a potentially multi-line abstract, e.g.
+
+::
+
+ ABSTRACT
+ Here comes the detailed description ...
+
+The next tag, **LABELS**, are used to define human readable names for the data parameters to be followed:
+
+::
+
+ LABELS
+ T (K)
+ B (G)
+ ...
+
+The number of labels have to fit the number of parameters present!
+
+The next tag is **DATA**, which is a list of the parameter names as found in you msr-file.
+Unlike the other tags, here the list of names follow directly after the **DATA** tag
+
+::
+
+ DATA dataT dataB dataE dataTr ...
+
+Next there will be a line with the tag **\\\\-e**, followed by
+
+The parameters are afterwards listed as
+
+::
+
+ param-name = val, pos-err, neg-err,\
+
+After all the parameters listed of a specific run, the **run number** with the run title ends a run data set.
+This might look like this (be aware of the comma!):
+
+::
+
+ 11231,,, AgPlate 250nm (T5034), T=200.00 K, E=12.99 keV, B=~50(G)/8.65(A), Tr/Sa=12.00/-1.80 kV, SR=-10.00
+
+A full example might look like this:
+
+::
+
+ TITLE
+ Ag Plate 2023 runs, Tr12kV, E=13keV, TF B=50G
+
+ Abstract
+ Summary of the
+
+ LABELS
+ T (K)
+ B (G)
+ Implantation Energy (keV)
+ Transport (kV)
+ RAL-RAR (kV)
+ RAT-RAB (kV)
+ Spin Rotation Angle (degree)
+ Asy
+ Lambda
+ Ph
+ Field
+ RelPh_L
+ N0_L
+ N_bkg_L
+ RelPh_T
+ N0_T
+ N_bkg_T
+ RelPh_R
+ alpha_LR
+ N_bkg_R
+ RelPh_B
+ alpha_TB
+ N_bkg_B
+ maxLH
+ NDF
+ maxLHred
+ RUN
+
+ Data dataT dataB dataE dataTr dataRALRAR dataRATRAB dataSpinRot Asy Lambda Ph Field RelPh_L N0_L N_bkg_L RelPh_T N0_T N_bkg_T RelPh_R alpha_LR N_bkg_R RelPh_B alpha_TB N_bkg_B maxLH NDF maxLHred RUN
+ \-e
+ dataT = 200.001, 0.0009, 0.0009,\
+ dataB = 49.49, 0, 0,\
+ dataE = 12.9952, 0, 0,\
+ dataTr = 11.9993, 0, 0,\
+ dataRALRAR = -0.008, 0, 0,\
+ dataRATRAB = -0.009, 0, 0,\
+ dataSpinRot = -10, 0, 0,\
+ Asy = 0.22466, 0.00084, -0.00084,\
+ Lambda = 0.0081, 0.0014, -0.0014,\
+ Ph = 12.14, 0.32, -0.32,\
+ Field = 50.837, 0.017, -0.017,\
+ RelPh_L = 0, 0, 0,\
+ N0_L = 430.67, 0.39, -0.39,\
+ N_bkg_L = 6.81, 0.048, -0.048,\
+ RelPh_T = -89.95, 0.4, -0.4,\
+ N0_T = 422.6, 0.37, -0.37,\
+ N_bkg_T = 7.125, 0.047, -0.048,\
+ RelPh_R = -178.55, 0.39, -0.39,\
+ alpha_LR = 0.9729, 0.0012, -0.0012,\
+ N_bkg_R = 7.375, 0.048, -0.048,\
+ RelPh_B = 90.38, 0.4, -0.4,\
+ alpha_TB = 0.9522, 0.0012, -0.0012,\
+ N_bkg_B = 6.546, 0.047, -0.047,\
+ maxLH = 20303.3, 0, 0,\
+ NDF = 20361, 0, 0,\
+ maxLHred = 0.997166, 0, 0,\
+ 11231,,, AgPlate 250nm (T5034), T=200.00 K, E=12.99 keV, B=~50(G)/8.65(A), Tr/Sa=12.00/-1.80 kV, SR=-10.00
+ dataT = 153, 0.7, 0.7,\
+ dataB = 49.49, 0, 0,\
+ dataE = 12.9952, 0, 0,\
+ dataTr = 11.9993, 0, 0,\
+ dataRALRAR = -0.008, 0, 0,\
+ dataRATRAB = -0.009, 0, 0,\
+ dataSpinRot = -10, 0, 0,\
+ Asy = 0.22253, 0.00084, -0.00083,\
+ Lambda = 0.0055, 0.0014, -0.0014,\
+ Ph = 11.53, 0.32, -0.32,\
+ Field = 51.026, 0.017, -0.017,\
+ RelPh_L = 0, 0, 0,\
+ N0_L = 430.31, 0.39, -0.39,\
+ N_bkg_L = 6.762, 0.048, -0.048,\
+ RelPh_T = -89.3, 0.4, -0.4,\
+ N0_T = 422.31, 0.37, -0.37,\
+ N_bkg_T = 6.96, 0.047, -0.047,\
+ RelPh_R = -178.61, 0.4, -0.4,\
+ alpha_LR = 0.975, 0.0013, -0.0012,\
+ N_bkg_R = 7.361, 0.048, -0.048,\
+ RelPh_B = 90.24, 0.4, -0.4,\
+ alpha_TB = 0.9605, 0.0012, -0.0012,\
+ N_bkg_B = 6.623, 0.047, -0.047,\
+ maxLH = 20435.6, 0, 0,\
+ NDF = 20361, 0, 0,\
+ maxLHred = 1.00366, 0, 0,\
+ 11235,,, AgPlate 250nm (T5034), T=151.72 K, E=13.00 keV, B=~50(G)/8.65(A), Tr/Sa=12.00/-1.80 kV, SR=-10.00
+ >> here many more run data would follow ...
+
+.. index:: dat-file-format
+.. _dat-file-format:
+
+DAT: CSV like file format for non-|mgr|\SR
+------------------------------------------
+
+This is typically used when exporting the parameter data from **msr2data** to be used in **mupp**, gnuplot, origin, or whatever parameter plotter you might use.
+The first line defines the parameter tags separated by spaces or tabs. If errors are available there are labeled be the ending *Err*.
+This is followed by the parameter values and its errors if present. A fill example looks like this:
+
+::
+
+ dataT dataTErr dataB dataE dataTr dataRALRAR dataRATRAB dataSpinRot Asy AsyPosErr AsyNegErr Lambda LambdaPosErr LambdaNegErr Ph PhPosErr PhNegErr Field FieldPosErr FieldNegErr RelPh_L RelPh_LPosErr RelPh_LNegErr N0_L N0_LPosErr N0_LNegErr N_bkg_L N_bkg_LPosErr N_bkg_LNegErr RelPh_T RelPh_TPosErr RelPh_TNegErr N0_T N0_TPosErr N0_TNegErr N_bkg_T N_bkg_TPosErr N_bkg_TNegErr RelPh_R RelPh_RPosErr RelPh_RNegErr alpha_LR alpha_LRPosErr alpha_LRNegErr N_bkg_R N_bkg_RPosErr N_bkg_RNegErr RelPh_B RelPh_BPosErr RelPh_BNegErr alpha_TB alpha_TBPosErr alpha_TBNegErr N_bkg_B N_bkg_BPosErr N_bkg_BNegErr maxLH NDF maxLHred RUN
+ 200 0.007 99.48 1.11754 10.001 -0.008 -0.008 -10 0.1587 0.0012 0.0012 0.0263 0.003 0.003 29.85 0.64 0.64 101.179 0.035 0.035 0 0 0 219.27 0.27 0.27 2.676 0.033 0.033 -89.79 0.81 0.81 210.42 0.26 0.26 2.723 0.032 0.032 -179.73 0.81 0.81 0.9808 0.0017 0.0017 2.993 0.033 0.033 90.05 0.82 0.82 0.9755 0.0017 0.0017 2.501 0.032 0.032 20444.8 20361 1.00412 11400
+ 200 0.009 99.49 2.11668 10.001 -0.008 -0.008 -10 0.1732 0.0012 0.0012 0.0096 0.0025 0.0026 28.88 0.57 0.57 101.231 0.03 0.03 0 0 0 219.86 0.27 0.27 2.749 0.033 0.033 -88.87 0.71 0.71 211.47 0.26 0.26 2.791 0.032 0.032 -178.48 0.72 0.71 0.9678 0.0017 0.0017 2.969 0.033 0.033 90.94 0.73 0.73 0.9608 0.0017 0.0017 2.653 0.032 0.032 20182.5 20361 0.991233 11401
+
+
+.. index:: mdu-file-format
+.. _mdu-file-format:
+
+MDU file format (psi) for |mgr|\SR
+----------------------------------
+
+For details about the PSI-BIN/MDU file format from PSI see `Class_MuSR_PSI `_
+
+.. index:: mud-file-format
+.. _mud-file-format:
+
+MUD file format (triumf) for |mgr|\SR
+-------------------------------------
+
+For details about the MUD file format from triumf see `MUon Data access `_ .
+
+.. _musr-root-file-format:
+
+MusrRoot file format (PSI) for |mgr|\SR
+---------------------------------------
+
+For details see :ref:`MusrRoot - an Extensible Open File Format for uSR `.
+
+.. index:: nexus-file-format
+.. _nexus-file-format:
+
+NeXus file format (isis) for |mgr|\SR
+-------------------------------------
+
+For details about the NeXus file format from ISIS (UK) see `The application of the NeXus data format to ISIS muon data `_ . For a detailed list of available meta information and data see `NeXus Instrument Definitions for ISIS muon Data `_ .
+
+.. index:: psi-bin-file-format
+.. _psi-bin-file-format:
+
+PSI-BIN file format (psi) for |mgr|\SR
+--------------------------------------
+
+For details about the PSI-BIN/MDU file format from PSI see `Class_MuSR_PSI `_.
+
+
+.. index:: root-file-format
+.. _root-file-format:
+
+ROOT file format (psi/lem before 2012) for |mgr|\SR
+---------------------------------------------------
+
+For details about the API of ROOT files can be here: `ROOT files `_.
+The structure of the ROOT files (LEM, before 2012) looks like this:
+
+::
+
+ ROOT-file --|
+ |-- histos ---|
+ | |-- DecayAnaModule
+ | |-- PileUpAnaModule
+ | |-- ScalerSumRate
+ | |-- SCAnaModule
+ |
+ |-- RunInfo --|
+ |-- RunSummary
+
+``histos``, ``RunInfo``, ``DecayAnaModule``, ``PileUpAnaModule``, ``ScalerSumRate``, ``SCAnaModule`` are **TFolder** objects.
+
+The ``DecayAnaModule`` object holds the positron spectra
+
+::
+
+ DecayAnaModule --|
+ |-- hDecay00
+ |-- hDecay01
+ |-- hDecay02
+ |-- hDecay03
+ |-- hDecay20
+ |-- hDecay21
+ |-- hDecay22
+ |-- hDecay23
+
+The ``hDecayXX`` files or **TH1F** objects containing the positron spectra of the LEM detectors.
+
+The detectors (00, 01, 02, and 03) are the detectors (Left, Top, Right, Bottom). These are non-post-pileup (NPP) histograms.
+
+The detectors (20, 21, 22, and 23) are the detectors (Left, Top, Right, Bottom). These are post-pileup-corrected (PPC) histograms.
+
+The ``SCAnaModule`` contains various **TF1H** objects of slow control data of the run.
+
+The ``RunSummary`` is essentially an ascii dump, with summary information of the run.
+
+
+.. index:: wkm-file-format
+.. _wkm-file-format:
+
+WKM file format for |mgr|\SR
+----------------------------
+
+WKM is an obsolete ascii file format, originally introduced by people from the TU Braunschweig.
+It starts with a header which shows like this:
+
+::
+
+ - WKM data file converted with any2many
+ NEMU_Run: 2466
+ nemu_Run: ./2466.wkm
+ Date: 13:22:00 2012-06-03 / 14:04:38 2012-06-03
+ Title: LSCO x=0.02 (224-227), T=12.00 (K), E=5.57 keV, WEW B=~49(G)/8.62(A), Tr=15.02 (kV), Sample=8.70 (kV), SpinRot -10
+ Field: 49.11
+ Setup: Sample, WEW, LowTemp-2
+ Temp: 11.999
+ TOF(M3S1): nocut
+ Groups: 8
+ Channels: 66601
+ Resolution: 0.0001953125
+
+The header ends with an empty line.
+
+The data are stored as following: there are always 10 bin-counts per line.
+Between detectors, there will be an empty line.
diff --git a/doc/html/_sources/index.rst.txt b/doc/html/_sources/index.rst.txt
new file mode 100644
index 00000000..efa142dc
--- /dev/null
+++ b/doc/html/_sources/index.rst.txt
@@ -0,0 +1,32 @@
+.. musrfit docu documentation master file, created by
+ sphinx-quickstart on Sun Jun 17 11:00:32 2018.
+ You can adapt this file completely to your liking, but it should at least
+ contain the root `toctree` directive.
+
+Welcome to the musrfit documentation!
+=====================================
+
+.. toctree::
+ :maxdepth: 2
+
+ cite
+ tutorial
+ user-manual
+ user-libs
+ setup-standard
+ setup-dks
+ musredit
+ mupp
+ msr2data
+ any2many
+ file-formats
+ musr-root
+ acknowledgement
+ bugtracking
+
+
+Indices and tables
+==================
+
+* :ref:`genindex`
+* :ref:`search`
diff --git a/doc/html/_sources/msr2data.rst.txt b/doc/html/_sources/msr2data.rst.txt
new file mode 100644
index 00000000..8e77bbca
--- /dev/null
+++ b/doc/html/_sources/msr2data.rst.txt
@@ -0,0 +1,374 @@
+.. include::
+.. index:: msr2data
+
+.. _msr2data:
+
+msr2data - A Program for Automatically Processing Multiple ``musrfit`` msr Files
+================================================================================
+
+``msr2data`` (originally written by B. M. Wojek) is a program implemented in ``C++``. Its purpose is
+to process multiple msr files (input files for ``musrfit``) with the same parameters and summarize the fitting
+results either in a *TRIUMF DB* [#f1]_ or a *column ASCII* file. This allows essentially to
+
+#. Collect the fit parameters.
+#. Generate *new* input msr files based on old ones.
+
+.. [#f1] For an abridged description of this format see `here `_. The DB files
+ produced by ``msr2data`` can be viewed for instance with :ref:`mupp ` or |mgr|\View `see here `_, however,
+ they are not completely backward-compatible to the original ``db language`` since the parameter names can be longer than five or
+ six characters! In order to establish this backward compatibility (if needed) the user has to ensure the correct length of the
+ parameter names in the msr files!
+
+.. _msr2data-basic-usage:
+
+Basic Types of Usage
+--------------------
+
+Apart from numerous :ref:`optional parameters ` that might be set, in principle there are four different ways of calling ``msr2data``.
+These differ in how the list of runs which should be processed is supplied:
+
+**msr2data [optional parameters]**
+ A single run number.
+**msr2data [optional parameters]**
+ An interval of run numbers is specified through the first and the last run number. The condition ```` < ```` is not necessary.
+**msr2data \[ \] [optional parameters]**
+ Where ```` is one or a combination of the following:
+
+ #. ``, , , ... `` : run numbers, *e.g.* 123 124,
+ #. ``-`` : a range, *e.g.* 123-125 -> 123 124 125,
+ #. ``::`` : a sequence, *e.g.* 123:127:2 -> 123 125 127. ```` has to be a positive integer.
+ #. A ```` can also combine (1)-(3), *e.g.* 123 128-130 133, etc.
+
+**msr2data [optional parameters]**
+ An ASCII file containing a list of run numbers and optional external parameters is passed to ``msr2data``. For the structure of the ASCII file
+ see :ref:`below `.
+
+All four basic types of calling ``msr2data`` contain the *mandatory* file-name ```` passed right after the list of runs. The meaning of
+this ```` should become clear after giving examples for all four cases:
+
+.. code-block:: bash
+
+ $ msr2data 8472 _tf_h13
+
+generates the DB file ``out.db`` (can be changed by using the -o option) from ``8472_tf_h13.msr``.
+
+.. code-block:: bash
+
+ $ msr2data 8472 8474 _tf_h13
+
+generates the DB file ``out.db`` (can be changed by using the -o option) from ``8472_tf_h13.msr``, ``8473_tf_h13.msr``, and ``8474_tf_h13.msr``.
+
+.. code-block:: bash
+
+ $ msr2data [8472 8470] _tf_h13
+
+generates the DB file ``out.db`` (can be changed by using the -o option) from ``8472_tf_h13.msr`` and ``8470_tf_h13.msr``.
+
+.. code-block:: bash
+
+ $ msr2data [8470:8474:2] _tf_h13
+
+generates the DB file ``out.db`` (can be changed by using the -o option) from ``8470_tf_h13.msr``, ``8472_tf_h13.msr``, and ``8474_tf_h13.msr``.
+
+.. _run-list-file_structure:
+
+Run List File Structure
++++++++++++++++++++++++
+
+.. code-block:: bash
+
+ $ msr2data run.list _tf_h13
+
+generates the DB file ``out.db`` (can be changed by using the -o option) from all runs listed in the ASCII file ``run.list`` in the working directory.
+In this file it is also possible to include *external* parameters which should be put in the resulting DB file. The structure of the ``run.list`` is the following:
+
+::
+
+ RUN VAR1 VAR2 VAR3 ...
+ 8460 200 27.1 46.2 ...
+ 8472 205 27.1 46.3 ...
+ 8453 210 27.2 45.9 ...
+ · · · ·
+ · · · ·
+ · · · ·
+
+*The first not commented and not empty line determines the parameter names and labels and has to be present!*
+
+It is allowed to add comments (with a preceding '#') or empty lines to the run-list file.
+
+The following should be mentioned together with the above examples:
+
+* The output files in the examples above are only newly created if they did *not* exist before invoking ``msr2data``.
+ If the files were already present the msr file data would be appended!
+* If the files have been newly created, also the DB file header is written. If the files were present before, only
+ the data blocks are appended. The output of the header can either be forced or completely suppressed with the ``header``
+ and ``noheader`` options as shall be seen later.
+* If the ``musrfit`` output files do not have an ```` as specified above like ``8472.msr`` one has to call ``msr2data`` like in the following example:
+
+ .. code-block:: bash
+
+ $ msr2data 8472 8460 ""
+
+.. _msr2data-opt-param:
+
+Optional Parameters
+-------------------
+
+As mentioned already above there are some optional parameters which change the behavior of ``msr2data`` and can be passed in any order. Here is a complete list:
+
+**data**
+ The output file format is changed to a simple column ASCII file (default output file name: out.dat).
+**new**
+ An existing output file is deleted before new information is written to it.
+**header**
+ Force the output of the file header even if the output file was present before.
+**noheader**
+ The output of the file header is suppressed—also if the output file is newly created.
+ If either both or none of the header options are given, ``msr2data`` writes the file header only to new files
+ and it solely appends the data blocks to an existing output file assuming that the header is present already.
+**nosummary**
+ There will be no attempt to read additional information like the temperature or the applied magnetic field from
+ the data files even if these information were present there.
+**paramList **
+ option used to select the parameters which shall be exported. ```` is a list of parameter numbers to be exported.
+ Allowed lists are: ``-``, *e.g.* ``1-16`` will export parameters 1 to 16. Space separated numbers, *e.g.:* ``1 3 5``.
+ A combination of both is possible, *e.g.* ``1-16 19 31 62``, and so on.
+**-o, -o **
+ The processed data will be written to the file ```` instead of the default ``out.db`` or ``out.dat``.
+ If ```` is equal to none (case-insensitive) the parameter data are not appended to any output file.
+**fit**
+ Additionally to the final data collection ``msr2data`` will invoke ``musrfit`` to fit the specified runs.
+ All msr files are assumed to be present, none is newly generated!
+**fit-[!]**
+ Additionally to the final data collection ``msr2data`` will generate msr files for the runs specified in the list
+ of runs and invoke :ref:`musrfit ` for performing fits of the data. As template for the first run the file
+ ``.msr`` (or if not available: ``.mlog``) is used; the subsequent input
+ files will be created using the msr output of the last processed runs ("chain fit"). However, if for all runs only
+ the given template should be used one has to append an exclamation mark (**!**) to the ````.
+**msr-**
+ The same as ``fit-[!]``, *without* calling ``musrfit`` and the final data collection, *i.e.* only the msr files for the given runs are generated.
+**-k**
+ If specified together with the ``fit-`` option, the :ref:`- -keep-mn2-output ` option is passed to ``musrfit``.
+ In the case no fits should be done, this option is ignored.
+**-t**
+ In case this option is given additionally to the ``fit- option``, ``musrfit`` is called with
+ the :ref:`- -title-from-data-file ` option. If no fitting is done, this option is ignored.
+
+**Examples:**
+
+In order to illustrate the usage of these parameters a few examples with explanations are given below:
+
+.. code-block:: bash
+
+ $ msr2data 8400 8460 _tf_h13 -oABC.db fit-8472
+
+Using ``8472_tf_h13.msr`` as first template, ``msr2data`` generates subsequent msr input files ``8400_tf_h13.msr`` through ``8460_tf_h13.msr``,
+calls ``musrfit`` to perform a fit of these files and collects the results of the fits together with the DB header in the new file ``ABC.db``.
+Additionally, some information about external parameters like the temperature will be passed to ``ABC.db`` if it is present in the data files.
+
+.. code-block:: bash
+
+ $ msr2data [8500 8502-8504 8507] _zf fit-8472 noheader nosummary -o DEF.db
+
+Using ``8472_zf.msr`` as first template, ``msr2data`` generates subsequent msr input files ``8500_zf.msr``, ``8502_zf.msr``, ``8503_zf.msr``,
+``8504_zf.msr``, and ``8507_zf.msr``, calls ``musrfit`` to perform a fit of these files and collects the results of the fits in the file ``DEF.db``
+*without* writing the DB file header or attempting to read additional information from the data files.
+
+.. code-block:: bash
+
+ $ msr2data 8595 8585 "" noheader fit-8472! -oGHI.dat data nosummary -k
+
+Using ``8472.msr`` as template for all runs, ``msr2data`` generates the msr input files ``8595.msr`` through ``8585.msr``, calls ``musrfit`` with
+the option ``--keep-mn2-ouput`` to perform a fit of these files and collects the results of the fits in the column-structured ASCII file ``GHI.dat``
+*without* writing any file header or attempting to read additional information from the data files.
+
+.. code-block:: bash
+
+ $ msr2data 8472 8475 "" fit -o none
+
+Take the *given* msr files ``8472.msr`` through ``8475.msr`` and call ``musrfit`` *without* finally summarizing the results.
+
+.. code-block:: bash
+
+ $ msr2data 8472 8475 _tf_h13 msr-8471!
+
+Using ``8471_tf_h13.msr`` as template for all runs, ``msr2data`` generates the msr input files ``8472_tf_h13.msr`` through ``8475_tf_h13.msr``.
+*No fitting will be performed and no DB or ASCII output will be generated!*
+
+.. code-block:: bash
+
+ $ msr2data [8472 8475-8479] _tf_h13 paramList 1-16 data -o bestData.dat
+
+Will collect the parameters 1 to 16 from the msr-files ``8472_tf_h13.msr``, ``8475_tf_h13.msr``, ``8476_tf_h13.msr``, ``8477_tf_h13.msr``, ``8478_tf_h13.msr``,
+and ``8479_tf_h13.msr`` and write these parameters into a column like output file ``bestData.dat``.
+
+.. index:: msr2-data-global-mode
+
+The Global Mode
+---------------
+
+Apart from all the options described :ref:`above ` there is another program option: **global**.
+This option changes the general behavior of ``msr2data`` in that way that instead of processing one msr file for each
+run it combines all specified runs in *one single msr file* with the possibility to define common parameters for all
+runs as well as run-specific parameters. When writing the obtained parameters to a DB file or a column-structured
+ASCII file that single msr file is read and the parameters valid for each run are extracted. The global option can be
+used in conjunction with any of the described invocations of ``msr2data`` and together with all options stated :ref:`above `.
+
+File Generation
++++++++++++++++
+
+The general idea of this mode is to generate a global msr file on the basis of a working single-run msr file. For this
+purpose a single-run template containing information about common and run-specific parameters should be created. These
+parameters are identified through their parameter names:
+
+**run-specific parameters**
+ these parameters are tagged with the current run number in the format ``%0Xu``, *i.e.* ``X`` digits with leading zeros,
+ at the end of the parameter name, *e.g.* for a 4-digit-formatted run number ``alpha0123`` if the run number was 123 or
+ for a 8-digit-formatted run number ``alpha00123456`` if the run number was 123456. ``X`` has to be at least 4.
+**common parameters**
+ all parameters that are not run specific
+
+The :ref:`FITPARAMETER block ` of an exemplary template file ``8472_example.msr`` could therefore look like:
+
+::
+
+ FITPARAMETER
+ # No Name Value Step Pos_Error Boundaries
+ 1 Phase 35.8359 -3.94496 3.93749
+ 2 Asy8472 0.04501 -0.00208 0.00211 0 0.33
+ 3 Field 143.212 -0.27960 0.27885 100 200
+ 4 Rate8472 0.14245 -0.02501 0.02279 0 1
+
+Here the parameters **2** and **4** would be treated as *run-specific* whereas the parameters **1** and **3** would be *common* to the original and all newly added runs.
+
+Normally, within the template file there should *not* appear explicitly any run-specific parameters in the :ref:`THEORY ` and
+:ref:`FUNCTIONS ` blocks. If however, those parameters are met, ``msr2data`` will try to substitute them by mapped parameters
+and add them accordingly to the map contained in each :ref:`RUN block `.
+
+When ``msr2data`` is called to generate a global msr file, *e.g.*
+
+.. code-block:: bash
+
+ $ msr2data 8471 8470 _example msr-8472 global
+
+a new msr file ``8471+global_example.msr`` is created. As can be seen in the example, the name of the global msr file always starts with the
+first specified run number followed by the ``+global`` identifier and the template ````. The example's global FITPARAMETER block would be:
+
+::
+
+ FITPARAMETER
+ # No Name Value Step Pos_Error Boundaries
+
+ # Common parameters for all runs
+
+ 1 Phase 35.8359 -3.94496 3.93749
+ 2 Field 143.212 -0.27960 0.27885 100 200
+
+ # Specific parameters for run 8471
+
+ 3 Asy8471 0.04501 -0.00208 0.00211 0 0.33
+ 4 Rate8471 0.14245 -0.02501 0.02279 0 1
+
+ # Specific parameters for run 8470
+
+ 5 Asy8470 0.04501 -0.00208 0.00211 0 0.33
+ 6 Rate8470 0.14245 -0.02501 0.02279 0 1
+
+This shows that the fit parameters are reorganized in a way that the common parameters appear at the beginning of the parameter list and they are
+followed by copies of the parameters specific to each run (in the specified order!). Additionally, for each specified run new RUN blocks are
+created — for each run as many as found for the template run.
+
+During this reorganization all the affected parameter occurrences are changed accordingly!
+
+.. note::
+
+ Please be aware of the fact that comments in the template msr file are *not* propagated to the newly generated global msr file!
+
+.. index:: msr2data-global-param-extraction
+
+Parameter Extraction
+++++++++++++++++++++
+
+After fitting some model to the specified data the fit parameters can be extracted from the global msr file to a DB or column-structured ASCII file;
+as usual this includes also parameters stored in the run data files or externally specified parameters given in a :ref:`run-list file `.
+In order to reach this goal the global msr file has to obey certain rules:
+
+* The order of the parameters has to match the one described above, meaning the common parameters are listed first followed by
+ the same number of parameters specific to each run tagged by the according run numbers at the end of the parameter names and
+ having the same order as the specified list of runs.
+* The RUN blocks have to be ordered according to the list of runs to be processed.
+
+Following these rules -- which is achieved most easily by generating the global msr file using ``msr2data`` as shown above -- the parameters can be extracted *e.g.* like
+
+.. code-block:: bash
+
+ $ msr2data 8471 8470 _example global data -o globalFit.dat
+
+This will read in the file ``8471+global_example.msr``, extract for each run all relevant parameters from the msr file as well as
+from the according data files (if available) and append all of them in columns to the ASCII file ``globalFit.dat``.
+
+.. index:: msr2data-global-extended
+
+The Extended Global Mode
+++++++++++++++++++++++++
+
+If a new global input file is generated, it is also possible to do an automatic pre-analysis for each single run using the specified template first;
+afterwards the run-specific parameters of these single-run msr files are collected into the global msr file. In special cases this might be useful
+to obtain a better set of starting values for the parameters, however, in most cases it will not replace the "manual review" of the generated global
+input file. The option is activated by choosing the keyword **global+**. For example
+
+.. code-block:: bash
+
+ $ msr2data 8471 8470 _example global+ msr-8472
+
+Here, ``8472_example.msr`` is first used as template to generate the file ``8471-OneRunFit_example.msr``, then ``musrfit`` is called for it, the result
+is used to generate ``8470-OneRunFit_example.msr`` and ``musrfit`` is called for that file. Finally, the global fit file ``8471+global_example.msr`` is
+produced — including the fit results of the ``OneRunFit`` files for the run-specific parameters.
+
+By appending an exclamation mark **!** to the **global+** option, the given template will be used for every new file generation (similar to the fit option
+explained before). The **+[!]** extension will be ignored, if no new global input file is generated.
+The single run msr files are *not* deleted at the moment. The information contained in them might be useful for some people. Of course the data can also
+be collected by ``msr2data``. *E.g.* in order to produce a DB file ``OneRunFits.db`` one could call
+
+.. code-block:: bash
+
+ $ msr2data 8471 8470 -OneRunFit_example -o OneRunFits.db
+
+.. note::
+
+ Please be aware that the program in this mode *always* generates new single-run msr files and *always* calls ``musrfit`` for them. In case there are
+ already single-run fits present, these cannot be used in conjunction with this option. The program on purpose behaves in this way in order to ensure
+ the file integrity and correct parameter order within these files.
+
+Known Limitations
+-----------------
+
+* The indexing run number of the msr file has to be at the begin of every filename.
+* Within the data file name the ``RUN#`` has the format ``%0Xu``, *i.e.* ``X`` digits with leading zeros, and has to be the rightmost number given in this
+ format in the file name. ``X`` has to be at least 4. The highest treatable run number is :math:`2^{32}-1 = 4294967295`.
+* In order to keep ``msr2data`` working properly the msr files should only contain *one* STATISTIC block at the end of the file and *one* FITPARAMETER block
+ right after the TITLE — ``musrfit`` itself allows to have more creative msr files...
+* The msr-file generation from a template takes only care of runs given on the *first* line of a ``RUN block``. :ref:`ADDRUN ` statements are simply
+ copied! Since this is most probably *not* what one likes to do, it is suggested *not* to use the ``fit-`` and ``msr-`` options if
+ ADDRUN statements were present in the template file.
+* ``msr2data`` will write only up to two successive empty lines in newly generated msr files. In case more subsequent empty lines are encountered in a template file,
+ these are not copied! Actually, this measure is not a limitation but has been introduced to keep the msr files in a reasonable shape.
+
+The Graphical User Interface for msr2data Provided by musredit
+--------------------------------------------------------------
+
+:ref:`musredit `, designed especially for the manipulation of ``musrfit`` msr files and graphical front ends to ``musrfit``, offer an almost
+self-explanatory graphical user interface to ``msr2data`` depicted below:
+
+.. image:: ../images/msr2data-GUI.*
+
+1. and 2. Choose one of the ways to specify your list of runs as described under :ref:`basic usage `.
+
+3. Give the file extension here, *e.g.* ``_zf`` for files like ``8472_zf.msr``. If the files do not have an extension this
+ field stays empty. ``musredit`` takes care of passing the "" to ``msr2data`` as mentioned above.
+4. Activates the ``fit-`` option if ```` is entered. In case the option ``Chain Fit`` is *not* set the
+ given template will be used for the input-file generation for all runs to be fitted — otherwise the output of the first
+ fit serves as template for the second and so on. The template field stays empty if *no* fits should be performed!
+5. Activates the ``-o `` option if ```` is entered. If nothing is entered the default output file ``out.db`` or ``out.dat`` is used.
+
+The options tags correspond essentially to the description in :ref:`optional parameters `.
\ No newline at end of file
diff --git a/doc/html/_sources/mupp.rst.txt b/doc/html/_sources/mupp.rst.txt
new file mode 100644
index 00000000..c8156723
--- /dev/null
+++ b/doc/html/_sources/mupp.rst.txt
@@ -0,0 +1,238 @@
+.. include::
+.. index:: mupp
+.. _mupp:
+
+mupp - |mgr|\SR Parameter Plotter
+=================================
+
+``mupp`` is a little helper program which allows to quickly plot a collection of msr-file parameters,
+as for instance generated by :ref:`msr2data `. It can handle ``db``- and ``dat``-files.
+Also a collection of ``msr``-files can be invoked. ``mupp`` is heavily inspired by |mgr|\View (see
+`here `_).
+
+``mupp`` can be operated from within as graphical user interface or via a command line scripting interface.
+The ``mupp`` GUI can be invoked either directly from the command line or from within :ref:`musredit `.
+
+Each collection bundles a number of runs, where a run is a single |mgr|\SR measurement.
+A run is analyzed by a number of parameters (defined in the msr-files), and complemented by
+additional physical parameters as the temperature, magnetic field, implantation energy, etc.
+Hence parameters can be seen as vectors and can be plot against each other.
+
+.. index:: mupp-gui
+
+The Graphical User Interface
+----------------------------
+
+A typical setting could look like this
+
+.. image:: ../images/mupp-gui-0.*
+
+1. shows the list of loaded collections. A collection is defined as ``db``- or ``dat``-file (typically the
+ output from :ref:`msr2data `). If you call the open-dialog and select a collection of
+ ``msr``-files, ``mupp`` will call ``msr2data`` and tries to generate a collection on-the-fly.
+2. in this list, the data-tags of the currently selected collection is presented. The data-tags can be
+ directly dragged over to the ``x``- and ``y``-axis list. Another way is to select the data-tag
+ wished and click ``add X`` to add the selected data-tag to the ``x``-axis list. Analogous it is done
+ for the ``y``-axis.
+3. ``x``-axis list. The labels are followed by ``(-X-)`` where the number ``X`` corresponds to the
+ selection it corresponds to. The numbering of the collection is as given in the collection list.
+4. ``y``-axis list. The labels are followed by ``(-X-)`` where the number ``X`` corresponds to the
+ selection it corresponds to. The numbering of the collection is as given in the collection list.
+5. ``add X`` allows to add the currently selected data-tag to the ``x``-axis list.
+6. ``add Y`` allows to add the currently selected data-tag to the ``y``-axis list.
+7. ``remove X`` will remove the selected ``x``-axis tag.
+8. ``remove Y`` will remove the selected ``y``-axis tag.
+9. Often one would like to compare trends of different settings. In the above example each collections
+ holds an energy scans for a given temperature. Each collection is measured at a different temperature.
+ Now, instead of adding ``x``- and ``y``-axis tags for each collection, you can do the following:
+ you add ``x``- and ``y``-axis data-tags for the first collection. Afterwards you select all the other
+ collections of interest and click on ``Add Ditto``. ``mupp`` will then add the corresponding
+ ``x``- and ``y``-axis data-tags accordingly. This is less error prone and quicker!
+10. Clicking the ``Plot`` button will invoke ``mupp_plot`` (a ``ROOT`` based application) which will
+ present the data, as shown here
+
+ .. image:: ../images/mupp-plot-0.*
+ :height: 600px
+
+11. ``Remove Collection``: will remove the selected collection
+12. ``Refresh Collection``: will reload the collection (``db``- or ``dat``-file). This is often useful
+ during beamtime where the collection is growing run-by-run.
+13. Command history window.
+14. This is the script command line. Currently it allows to perform the tasks without mouse gambling.
+ In the future much more commands are planed. See the ``Help / Cmd's`` for the currently available
+ commands.
+
+Define Variable Dialog
+++++++++++++++++++++++
+
+.. image:: ../images/mupp-add-var.*
+
+1. Variable text edit window.
+2. Collection link window.
+3. Shows the parameters of the selected collection.
+4. Check if the variable/error variable from the edit window is valid.
+5. Add the variable to the selected collection(s) if the parsing is successful.
+
+A variable defined here is a mathematical expression defined by parameters of loaded collections.
+Since a parameter also has an associated error, also newly defined variables **always** need
+to be defined together with a corresponding error variable. If the name of a variable is defined
+as ``SigmaSC_10`` (see the above snapshot), the error variable need to be named as ``SigmaSC_10Err``.
+
+Currently the following mathematical functions are defined: ``max``, ``min``, ``abs``, ``sin``, ``cos``,
+``tan``, ``exp``, ``log``, ``ln``, ``pow``.
+
+.. index:: mupp-scripting
+
+The Scripting Interface
+-----------------------
+
+``mupp`` can also be operated in a scripting like manner. The use cases are plot updates during run time,
+or web-based interaction which requests figures. A script is invoked by the command line option ``-s`` (see
+:ref:`mupp command line summary `. Currently the following scripting commands are available:
+
+**loadPath **
+ set the load path to ````. Bash variables like $HOME are accepted. This is the path where to look for collection files (``db``- and ``dat``-files).
+
+**load **
+ will load the collection ````.
+
+**selectAll**
+ will select all loaded collections. This means every plot of variable x/y will be carried out to *ALL* collections.
+
+**select **
+ selects collection ````, where ```` is either the *number* of the collections, or its *name*, *e.g.*
+ select YBCO-40nm-T5K-FC150mT-Escan.db.
+
+**x