diff --git a/doc/html/msr2data.html b/doc/html/msr2data.html
index a10d69c9e..610f4ff4a 100644
--- a/doc/html/msr2data.html
+++ b/doc/html/msr2data.html
@@ -6,14 +6,14 @@
- msr2data - A Program for Automatically Processing Multiple musrfit msr Files — musrfit 1.9.9 documentation
-
+ msr2data - A Program for Automatically Processing Multiple musrfit msr Files — musrfit V1.10.0
+
-
+
@@ -428,8 +428,8 @@ fit serves as template for the second and so on. The template field stays empty
diff --git a/doc/html/musr-root.html b/doc/html/musr-root.html
index 07b9a2db4..4822a835b 100644
--- a/doc/html/musr-root.html
+++ b/doc/html/musr-root.html
@@ -6,14 +6,14 @@
- MusrRoot - an Extensible Open File Format for μSR — musrfit 1.9.9 documentation
-
+ MusrRoot - an Extensible Open File Format for μSR — musrfit V1.10.0
+
-
+
@@ -134,13 +134,20 @@ which allows to inspect these files. This browser (TObject.
The MusrRoot file format to be described below is only using a small subset of possible ROOT objects, namely:
-
TFolder: this are the top level objects in the MusrRoot file.
+
TFolder/TDirectory: this are the top level objects in the MusrRoot file.
TH1F: Hold the μ-decay-histograms.
-
TObjArray: Holding collection of header information.
+
TObjArray/TDirectory: Holding collection of header information.
TObjString: Holding the content of any header information.
Since all these objects are deriving form TObject, they will be directly accessible via the TBrowser-object.
For instance, the μ-decay-histograms can be directly plotted, are even fitted, out of the box.
+
+
Note
+
Since TFolder has bee marked as deprecated from the ROOT team, we
+will gradually switch over to use TDirectory instead. This will have a minimal impact on
+the following, as you will see. In the description to follow, the term “folder” will be used
+synonymous with “directory”. Only if necessary it will be distinguished.
@@ -173,7 +180,7 @@ For instance, the μ-decay-histograms can be directly plotted, are even fitted,
in C/C++ notation, starting with ‘1’) is the histogram number. The title and name of the histogram (see description of the TH1F ROOT class) contains the label of the histogram, like ‘top’, ‘forward’, etc. How many of these histograms are present is accessible through the RunInfo folder in which the necessary header information are found (details see next sections). The folder SCAnaModule contains histograms of some of the slow-control parameters, as for instance the sample temperature versus time, the applied field versus time, etc. Again the label of the histogram will give more specific information about its content.
The RunHeader contains all needed meta-information to describe a μSR-run. The list of the minimal number of required “folders” of the RunHeader is given in the following structure:
+
The RunHeader contains all needed meta-information to describe a μSR-run. The list of the minimal number of required “folders” of the RunHeader is given in the following structure (deprecated):
RunHeader(TFolder)---||-RunInfo(TObjArray)|-DetectorInfo(TObjArray)
@@ -182,8 +189,24 @@ in C/C++|- BeamlineInfo(TObjArray)
+
In case it is already switched to TDirectory, it will look like this (default starting 2026):
In brackets the object type is given. RunInfo contains most information relevant for the user and will be itemized in RunInfo Overview and RunInfo Required. DetectorInfo contains detector specific information, like detector name, time zero bin, etc. (details is found under DetectorInfo Required). SampleEnvironmentInfo (details under SampleEnvironmentInfo Required), and MagneticFieldEnvironmentInfo (details under MagneticFieldEnvironmentInfo Required) store additional, more detailed information concerning the sample environment. BeamlineInfo stores beamline relevant information (details under BeamlineInfo Required).
-
Before elaborating more on the required items within this structure, a few words on the ROOT types used here: RunHeader is a TFolder object. All the “sub-directory” entries are of type TObjArray and collect items of type TObjString or other TObjArray (i.e. sub-directories and sub-sub-directories, etc.).
+
Before elaborating more on the required items within this structure, a few words on the ROOT types used here: RunHeader is a TFolder (deprecated) or a TDirectory object.
+
+
In case of the deprecatedTFolder RunHeader`, all the “sub-directory” entries are of type
+TObjArray and collect items of type TObjString or other TObjArray
+(i.e. sub-directories and sub-sub-directories, etc.).
+
In case the top entry RunHeader is a TDirectory object, all potential “sub-directories” are
+indeed TDirectory objects as well. In this case, the data are represented by TObjString objects.
@@ -306,8 +329,47 @@ is introduced to deal with physical quantities. They always can be represented i
-
Not all of these values are needed to be given and depending on which are given, the representation in the MusrRootvfilewillbedifferent(handledby``TMusrRunHeader). Examples are given in the comment column of the table above. For details see TMusrRunPhysicalQuantity - Possible Representations.
-
A mock-up TBrowser print-out would look like the one shown in the following figure. You might notice, that at the end of each entry you find a -@X, where X is a number. This is an encoding of the internal type of the entry and is the price to be payed not using derived types. The next section will explain this in much more detail.
+
Not all of these values are needed to be given and depending on which are given, the representation in the MusrRoot file will be different (handled by TMusrRunHeader). Examples are given in the comment column of the table above. For details see TMusrRunPhysicalQuantity - Possible Representations.
+
A mock-up TBrowser print-out would look like the one shown in the following figure. You might notice, that at the end of each entry you find a -@X, where X is a number. This is an encoding of the internal type of the entry and is the price to be payed not using derived types. Here is a table with the data representation
+
+
+
X
+
data type
+
comment
+
+
+
+
0
+
TString
+
default ROOT type
+
+
1
+
Int_t
+
+
+
2
+
Double_t
+
+
+
3
+
TMusrRunPhysicalQuantity
+
TMusrRunHeader type
+
+
4
+
TStringVector
+
type cast to vector<TString>
+
+
5
+
TIntVector
+
type cast to vector<Int_T>
+
+
6
+
TDoubleVector
+
type cast to vector<Double_t>
+
+
+
+
The next section will explain this in much more detail.
TMusrRunHeader mock up. The red shaded entries are of type TMusrRunPhysicalQuantity
@@ -338,11 +400,11 @@ is derived which is extending the base class to the needs of the instrument.
An example program write_musrRoot_runHeader which is writing a full run header is part of the musrfit package. Here I will concentrate just on the most essential parts. First one needs an instance of TMusrRunHeader
header is the instance of TMusrRunHeader. prop is an instance of TMusrRunPhysicalQuantity which will be needed further down in the description. In the next step some run header entries will be added
+
header is the instance of TMusrRunHeader. Here the concept of a unique pointer (std::unique_ptr) has been used to ensure that no memory leaks are present. prop is an instance of TMusrRunPhysicalQuantity which will be needed further down in the description. In the next step some run header entries will be added
header->Set("RunInfo/File Name","deltat_tdc_gps_2871.root");header->Set("RunInfo/Run Title","here comes the run title");header->Set("RunInfo/Run Number",2871);
@@ -364,18 +426,52 @@ is derived which is extending the base class to the needs of the instrument.
header->Set("DetectorInfo/Detector001/Time Zero Bin",3419.0);
-
To write the whole run header into a file would look something like this:
To write the whole run header into a file would look something like this (deprecatedTFolder version):
+
// create TMusrRunHeader object
+std::unique_ptr<TMusrRunHeader>header=std::make_unique<TMusrRunHeader>();
+
+// set some stuff
+header->Set("DetectorInfo/Detector001/Time Zero Bin",3419.0);
+header->Set("Something/Somewhere/Strange","Test String");
+// add more stuff in the header (not shown)
+
+// create TFile object. It is assumed the fileName is given
+std::unique_ptr<TFile>f=std::make_unique<TFile>(fileName,"RECREATE","write_musrRoot_runHeader");if(f->IsZombie()){
-deletef;return-1;}// create the needed TFolder object
-TFolder*runHeader=newTFolder("RunHeader","MusrRoot Run Header Info");
+std::unique_ptr<TFolder>runHeader=std::make_unique<TFolder>("RunHeader","MusrRoot Run Header Info");
+
+// create the "folder" structure
+if(header->FillFolder(runHeader)){
+runHeader->Write();// write run header to file
+}
+
+f->Close();
+
+
+
In the TDirectory version it will look like this:
+
// create TMusrRunHeader object
+std::unique_ptr<TMusrRunHeader>header=std::make_unique<TMusrRunHeader>();
+
+// set some stuff
+header->Set("DetectorInfo/Detector001/Time Zero Bin",3419.0);
+header->Set("Something/Somewhere/Strange","Test String");
+// add more stuff in the header (not shown)
+
+// create TFile object. It is assumed the fileName is given
+std::unique_ptr<TFile>f=std::make_unique<TFile>(fileName,"RECREATE","write_musrRoot_runHeader");
+if(f->IsZombie()){
+return-1;
+}
+
+// create the needed TDirectory object
+TDirectory*runHeader=f->mkdir("RunHeader");// create the "directory" structure
-if(header->FillFolder(runHeader)){
+if(header->FillDirectory(runHeader)){runHeader->Write();// write run header to file}
@@ -385,41 +481,69 @@ is derived which is extending the base class to the needs of the instrument.
The following code snippet shows how the extract the full run header from the MusrRoot file.
+First in the deprecateTFolder version:
+
// create TFile. It is assumed that fileName is present
+std::unique_ptr<TFile>f=std::make_unique<TFile>(fileName,"READ","read_musrRoot_runHeader");if(f->IsZombie()){
-deletef;return-1;}
-TFolder*runHeader=0;
+// get the TFolder object from the TFile
+TFolder*runHeader=nullptr;f->GetObject("RunHeader",runHeader);
-if(runHeader==0){
-cerr<<endl<<">> **ERROR** Couldn't get top folder RunHeader";
-closeFile(f);
+if(runHeader==nullptr){
+std::cerr<<std::endl<<">> **ERROR** Couldn't get top folder RunHeader";return-1;}
-TMusrRunHeader*header=newTMusrRunHeader(fileName);
+// create the TMusrRunHeader object
+std::unique_ptr<TMusrRunHeader>header=std::make_unique<TMusrRunHeader>(fileName);
+// fill the internal data structure of the TMusrRunHeader objectif(!header->ExtractAll(runHeader)){
-cerr<<endl<<">> **ERROR** couldn't extract all RunHeader information";
-closeFile(f);
+std::cerr<<std::endl<<">> **ERROR** couldn't extract all RunHeader information";return-1;}f->Close();
-deletef;
-
The routine ExtractAll(TFolder*runHeader) decodes all the TObjString objects and fills internal data structures. This means when reading a MusrRoot -file the above handling is always needed. After the ExtractAll call, parameters can be extracted via the getter routines available. For instance to read the Run Number, the code would look like
+
The same with the TDirectory version:
+
// create TFile. It is assumed that fileName is present
+std::unique_ptr<TFile>f=std::make_unique<TFile>(fileName,"READ","read_musrRoot_runHeader");
+if(f->IsZombie()){
+return-1;
+}
+
+// get the TDirectory object from the TFile. Note: Here on the top level a TDirectoryFile is needed
+TDirectoryFile*runHeader=nullptr;
+f->GetObject("RunHeader",runHeader);
+if(runHeader==nullptr){
+std::cerr<<std::endl<<">> **ERROR** Couldn't get top folder RunHeader";
+return-1;
+}
+
+// create the TMusrRunHeader object
+std::unique_ptr<TMusrRunHeader>header=std::make_unique<TMusrRunHeader>(fileName);
+
+// fill the internal data structure of the TMusrRunHeader object
+if(!header->ExtractAll(runHeader)){
+std::cerr<<std::endl<<">> **ERROR** couldn't extract all RunHeader information";
+return-1;
+}
+
+f->Close();
+
+
+
The overloaded routine ExtractAll(TFolder*runHeader) and ExtractAll(TDirectory*runHeader) decodes all the TObjString objects and fills internal data structures. This means when reading a MusrRoot -file the above handling is always needed. After the ExtractAll call, parameters can be extracted via the getter routines available. For instance to read the Run Number, the code would look like
Bool_tok;Int_tival;header->Get("RunInfo/Run Number",ival,ok);if(ok)
-cout<<endl<<"Run Number: "<<ival;
+std::cout<<std::endl<<"Run Number: "<<ival;else
-cout<<endl<<"**ERROR** Couldn't obtain the 'Run Number'.";
+std::cout<<std::endl<<"**ERROR** Couldn't obtain the 'Run Number'.";
Reading a TMusrRunPhysicalQuantity object, e.g. the sample temperature looks like this
@@ -427,11 +551,11 @@ is derived which is extending the base class to the needs of the instrument.
header->Get("RunInfo/Sample Temperature",prop,ok);if(ok){
-cout<<endl<<"Sample Temperature: "<<prop.GetValue()<<" +- ";
-cout<<prop.GetError()<<" "<<prop.GetUnit().Data();
-cout<<"; SP: "<<prop.GetDemand()<<"; "<<prop.GetDescription().Data();
+std::cout<<std::endl<<"Sample Temperature: "<<prop.GetValue()<<" +- ";
+std::cout<<prop.GetError()<<" "<<prop.GetUnit().Data();
+std::cout<<"; SP: "<<prop.GetDemand()<<"; "<<prop.GetDescription().Data();}else{
-cout<<endl<<"**ERROR** Couldn't obtain the 'Sample Temperature'.";
+std::cout<<std::endl<<"**ERROR** Couldn't obtain the 'Sample Temperature'.";}
@@ -887,8 +1011,8 @@ the entry has been added. The last token,
-
diff --git a/doc/html/musredit.html b/doc/html/musredit.html
index 6789b2dbd..4e10a0471 100644
--- a/doc/html/musredit.html
+++ b/doc/html/musredit.html
@@ -6,14 +6,14 @@
- musredit: the GUI Based Interface to musrfit — musrfit 1.9.9 documentation
-
+ musredit: the GUI Based Interface to musrfit — musrfit V1.10.0
+
-
+
@@ -569,8 +569,8 @@ the corresponding fit parameter value, except the phases where the step will be
Additionally, only if musrfit should support reading of data files in the NeXus format the following libraries are needed:
-
HDF4
A library and multi-object file format for storing and managing data (see HDF4). HDF4 is “outdated” and its support will soon be dropped. The single only reason why it is still required is that ISIS is not able to cope to implement HDF5 V2 of the NeXus muon instrument specification which has been agreed in 2012!
+
HDF4
A library and multi-object file format for storing and managing data (see HDF4). HDF4 is “outdated” but still in use.
@@ -174,23 +174,18 @@ their header packages:
-
minixml
A small XML library that can be used to read and write XML and XML-like data files. Required version ≥ 2.2 (see minixml).
-Currently the MXML support in NeXus is broken and hence you will not need to install minixml for the time being.
+
NeXus
A common data format for neutron, x-ray, and muon science. The NeXus library itself has been dropped by the muon community. Only the agreed ISIS IDF V1/2 documents are relevant.
+
If optionally the editor and graphical user interface musredit is going to be installed there is one further requirement:
-
NeXus
A common data format for neutron, x-ray, and muon science. Required version ≥ 4.4 (see NeXus).
-
-
-
If optionally the editor and graphical user interface musrgui / musredit is going to be installed there is one further requirement:
-
-
Qt
A cross-platform application and user interface framework. Required version ≥ 4.6 (musredit) (see Qt). Currently the Qt5 is still supported since some older distributions are not yet supporting Qt6. Qt6 is the main development part. Should be available on all new major distributions.
+
Qt
A cross-platform application and user interface framework. Required version ≥ 5.0 (musredit) (see Qt). Currently the Qt5 is still supported since some older distributions are not yet supporting Qt6. Qt6 is the main development part. Should be available on all new major distributions.
Each of the following sections focusing on the installation of musrfit on the different operating systems will also give a brief introduction on the installation of the requirements before the actual musrfit installation is described.
Depending on the GNU/Linux distribution chosen, the above mentioned software – except ROOT/CERN and NeXus – should be available from
@@ -251,14 +246,12 @@ the installation would look like:
the source code from the corresponding website, or to clone the git repo. If you need to follow this line, please check the install details of the corresponding package.
For any further information on the standard installation of software, please refer to the web search engine of choice and ask for “install software on linux”…
Only if musrfit should support reading/writing data files in the NeXus format the further required
software has to be set up. The required libraries and header files could either be available through the user’s
-GNU/Linux distribution or if this is not the case, the packages can be installed from the source code. In principle
-NeXus should support MXML, HDF4, and HDF5. At the time of this writing, the MXML support in the
-NeXus project is broken, and HDF4 is outdated on most platforms, yet since ISIS/RAL is still not up-to-date HDF4 still
-needs to be dragged on (comment: if you are a ISIS user, please complain about HDF4). Hence, the necessary packages to build NeXus are HDF4 and HDF5. This means, for a rpm-package based distro try something like:
+GNU/Linux distribution or if this is not the case, the packages can be installed from the source code. The necessary packages
+to build NeXus-support for musrfit are HDF4 and HDF5. This means, for a rpm-package based distro try something like:
$yuminstallhdf-develhdf5-devel
@@ -270,28 +263,10 @@ needs to be dragged on (comment: if you are a ISIS user, please complain about <
-
Only NeXus Version ≥ 4.4 is support!
-
Even though there might exist binary packages for the NeXus library, it is best to build and
-install it directly from the source code which can be found here.
-
A brief instruction how to get NeXus compiled from source (lines starting with ‘#’ are comments only):
-
$cdDownloads
-$# create a directory for the NeXus source code
-$mkdirnexus
-$cdnexus
-$# get the source code from the master repository
-$gitclonehttps://github.com/nexusformat/code.git
-$# next we will build NeXus out-of-source
-$mkdirbuild
-$cdbuild
-$cmake-DENABLE_HDF5=1-DENABLE_HDF4=1-DENABLE_MXML=0../code
-$cmake--build./--clean-first
-$# install needs either to be carried out as root or sudo depending on your linux flavour.
-$sudocmake--install./
-
-
+
How NeXus-support is enabled in musrfit is described in the musrfit setup sections below: musrfit build with cmake.
The ROOT framework may or may not be part of the GNU/Linux distribution. Some distributions are packing ROOT in a
manner incompatible with the way it is needed by musrfit, though the situation is improving. If you are
experienced enough you can try the packed ROOT version. Often ROOT is split in many sub-packages. Install the
@@ -364,7 +339,7 @@ $cmake--build
When all required software has been set up you can proceed with the musrfit installatio. First, the most
recent source code should be downloaded. The preferred way of doing so is to clone the musrfit repository via git.
Assuming the code should be located in $HOME/Apps this is achieved most easily calling from the terminal
@@ -390,20 +365,24 @@ will needed to switch branches first.
$gitpull
$cdbuild
$xargsrm<install_manifest.txt
+$cmake../
$cmake--build./--clean-first
$cmake--install./
As an alternative (if git is not available), the source code can also be downloaded from the following web-page: musrfit at bitbucket
Currently the following configuration switches for musrfit are available:
-DCMAKE_INSTALL_PREFIX=<prefix-path>
Specify the installation prefix, i.e. the place where musrfit shall be installed, e.g.$ROOTSYS if already defined (by default: /usr/local).
-
-Dnexus=<value>
enable/disable the support of NeXus data files (requires the HDF4, HDF5 and NeXus libraries to be installed).
+
-Dnexus=<value>
enable/disable the support of NeXus data files (requires at least the HDF5 library to be installed).
<value>=1 enables NeXus, <value>=0 disables NeXus. The default setting, i.e. the switch is not provided is NeXus support is disabled.
+
-DHAVE_HDF4=<value>
tell musrfit, whether NeXus-support should include HDF4 as well. <value>=1 notifies the presence of HDF4. This option is obviously
+only relevant if NeXus is enabled as well.
+
-DASlibs=<value>
enable/disable the ASlibs. <value>=1 enables the ASlibs, <value>=0 disables the ASlibs. The default setting, i.e. the
switch is not provided is ASlibs support is disabled. For details see Documentation of user libs.
@@ -424,11 +403,11 @@ If the value is set to -DCMAKE_INSTALL_PREFIX.
musrfit build with cmake takes the out-of-source approach. Therefore a typical configuration / make / install process including
-NeXus support would look like
+NeXus support (including HDF4) would look like
$cd$HOME/Apps/musrfit
$mkdirbuild
$cdbuild
-$cmake../-DCMAKE_INSTALL_PREFIX=$ROOTSYS-Dnexus=1
+$cmake../-DCMAKE_INSTALL_PREFIX=$ROOTSYS-Dnexus=1-DHAVE_HDF4=1# below it is assumed that multiple cores are present, hence the -j8 option
$cmake--build./--clean-first---j8
$cmake--install./
@@ -437,7 +416,7 @@ $/sbin/ldconfig
In the latest version of musrfit the configure script tries to determine automatically the highest available Qt version.
In case this is found, the editor musredit is built already together with musrfit.
macOS 15 alias Sequoia: musrfit is ready for Sequoia on Intel and Apple Silicon based macs, both running natively.
-The DKS version of musrfit for macOS Sequoia is ready as well.
-This is true for the Homebrew, MacPorts still has some issues (as of 23.09.24). Typically this should be fixed in a month.
+
macOS 26 alias Tahoe: musrfit is ready for Tahoe on Intel and Apple Silicon based macs, both running natively.
+The DKS version of musrfit for macOS Tahoe is ready as well.
+This is true for the Homebrew (tested on Apple Silicon and MacPorts on Intel).
Note
@@ -525,7 +504,7 @@ unistall musrfitMacPorts / Homebrew , ROOT, and musrfit from scratch!
Before proceeding with the usage of the MacPorts system first a few useful tools provided by Apple together
with OS X (on the installation DVD/CDs) should be installed:
@@ -581,34 +560,16 @@ add a new line pointing to your local copy, e.g.
With Qt6, musredit will be installed. If it happens that you used musrgui in the past,
please change over to musredit since there will be no further development for musrgui anymore!
Only if musrfit should support reading data files in the NeXus format the further required packages are set up:
$sudoport-vinstallhdf4hdf5
-
hdf4 is likely not available anymore.
-
Only NeXus Version ≥ 4.4 is support!
-
To get things compiled do:
-
$# get and install NeXus
-$cd$HOME/Applications
-$# get the source code from the master repository
-$gitclonehttps://github.com/nexusformat/code.gitnexus/code
-$# next we will build NeXus out-of-source
-$cdnexus
-$mkdirbuild
-$cdbuild
-$# in case hdf4 is present
-$cmake-DENABLE_HDF5=1-DENABLE_HDF4=1-DENABLE_MXML=0../code
-$# in case hdf4 is **not** present
-$cmake-DENABLE_HDF5=1-DENABLE_HDF4=0-DENABLE_MXML=0../code
-$cmake--build./
-$sudocmake--install./
-
-
+
How NeXus-support is enabled in musrfit is described in the musrfit setup sections below: musrfit build with cmake.
The best way to get ROOT exactly the way needed for musrfit is to install it from source.
Before describing it, please make sure that you have installed all required packages listed under
Requested Software (e.g.fftw, gsl, etc).
@@ -719,7 +680,7 @@ but no proper fix is available. The workaround to get it right is to install the
-
Before proceeding with the usage of Homebrew, first a few useful tools provided by Apple together with OS X (on the installation DVD/CDs) should be installed:
Xcode
Useful developer tools including for instance the GNU compiler collection. It can be installed via the Apple App store.
@@ -745,31 +706,23 @@ For example to install
Only if musrfit should support reading data files in the NeXus format the further required
-packages can be installed through Homebrew (Note: hdf4 is not supported anymore):
+packages can be installed through Homebrew (Note: hdf4 is not supported anymore, but you can install it from source):
$brewinstallhdf5
-
Unfortunately, the NeXus libraries have to be compiled and installed directly from
-the source code. Given the respective version number 4.4 (which are subject to change with time)
-this can be achieved for example by:
The best way to get ROOT exactly the way needed for musrfit is to install it from source.
Before describing it, please make sure that you have installed all required packages listed under
Requested Software (e.g.fftw, gsl, etc).
@@ -839,11 +792,6 @@ into the file ~/.Ma
exportMUSRFITPATH=$ROOTSYS/bin
exportPATH=$ROOTSYS/bin:$QTDIR/bin:$PATHexportDYLD_LIBRARY_PATH=$ROOTSYS/lib/root:/usr/local/lib:$DYLD_LIBRARY_PATH
-
-launchctlsetenvROOTSYS$ROOTSYS
-launchctlsetenvMUSRFITPATH$MUSRFITPATH
-launchctlsetenvPATH$PATH
-launchctlsetenvDYLD_LIBRARY_PATH$DYLD_LIBRARY_PATH
If ROOT has been installed via source/compilation:
First, the most recent source code should be downloaded. First, the most recent source code should be downloaded.
The preferred way of doing so is to clone the musrfit repository via git. Assuming the code should be located
in ~/Applications/musrfit this is achieved most easily calling from the termin
@@ -888,15 +869,18 @@ $gitpull
As an alternative (if git is not available), the source code can also be downloaded from the following
web-page: musrfit at bitbucket.
Currently the following configuration switches for musrfit are available:
-DCMAKE_INSTALL_PREFIX=<prefix-path>
Specify the installation prefix, i.e. the place where musrfit shall be installed, e.g.$ROOTSYS if already defined (by default: /usr/local).
-
-Dnexus=<value>
enable/disable the support of NeXus data files (requires the HDF4, HDF5 and NeXus libraries to be installed).
+
-Dnexus=<value>
enable/disable the support of NeXus data files (requires at least the HDF5 library to be installed).
<value>=1 enables NeXus, <value>=0 disables NeXus. The default setting, i.e. the switch is not provided is NeXus support is disabled.
+
-DHAVE_HDF4=<value>
tell musrfit, whether NeXus-support should include HDF4 as well. <value>=1 notifies the presence of HDF4. This option is obviously
+only relevant if NeXus is enabled as well.
+
-DASlibs=<value>
enable/disable the ASlibs. <value>=1 enables the ASlibs, <value>=0 disables the ASlibs. The default setting, i.e. the
switch is not provided is ASlibs support is disabled. For details see Documentation of user libs.
@@ -926,11 +910,11 @@ If the value is set to NeXus support would look like
+NeXus-support (including HDF4-support) would look like
$cd$HOME/Apps/musrfit
$mkdirbuild
$cdbuild
-$cmake../-DCMAKE_INSTALL_PREFIX=$ROOTSYS-Dnexus=1
+$cmake../-DCMAKE_INSTALL_PREFIX=$ROOTSYS-Dnexus=1-DHAVE_HDF4=1# below it is assumed that multiple cores are present, hence the -j8 option
$cmake--build./--clean-first---j8
$cmake--install./
@@ -947,7 +931,7 @@ The configuration, build, and install process might look like this:
$cd$HOME/Apps/musrfit
$mkdirbuild
$cdbuild
-$cmake../-DCMAKE_INSTALL_PREFIX=$ROOTSYS-Dnexus=1-DCMAKE_PREFIX_PATH="/opt/local/libexec/qt6/lib/cmake;/opt/local/include/libomp"
+$cmake../-DCMAKE_INSTALL_PREFIX=$ROOTSYS-Dnexus=1-DHAVE_HDF4=1-DCMAKE_PREFIX_PATH="/opt/local/libexec/qt6/lib/cmake;/opt/local/include/libomp"# below it is assumed that multiple cores are present, hence the -j8 option
$cmake--build./--clean-first---j8
$cmake--install./
@@ -972,8 +956,8 @@ detailed information on this XML file refer to the
-
-
In the latest version of musrfit the configure script tries to determine automatically the highest
available Qt version. In case this is found, the editor musredit is built already together with musrfit.
diff --git a/doc/html/tutorial.html b/doc/html/tutorial.html
index 6e3f69995..9b09c115e 100644
--- a/doc/html/tutorial.html
+++ b/doc/html/tutorial.html
@@ -6,14 +6,14 @@
- Tutorial for musrfit — musrfit 1.9.9 documentation
-
+ Tutorial for musrfit — musrfit V1.10.0
+
-
+
@@ -180,7 +180,7 @@ sample holder), each with an amplitude (parameters 10 and 13), a depolarization
The THEORY block is used to define a fit-parameter-dependent theory function used to model
-the decay asymmetry. Different predefined and user-defined
+the decay asymmetry. Different predefined and user-defined
functions can be combined here. Theory lines following each other are multiplied and the + sign
is used to add different (here: two) signal contributions. The numbers are the parameter numbers
according to the FITPARAMETERblock. map and fun are used to refer to
@@ -439,8 +439,8 @@ For a complete description please refer to the manuals of
-
libFitPofB is a collection of C++ classes using the musrfituser-functions
+
libFitPofB is a collection of C++ classes using the musrfituser-functions
interface in order to facilitate the usage in conjunction with musrfit. The classes contained in this
library generally implement calculations of one-dimensional static magnetic field distributions
\(p(B)\) which lead to the muon-spin depolarization functions
@@ -425,8 +425,8 @@ The expected name of the
-
-
Supeconducting Gap-Integrals to calculate \(1/\lambda^2\) vs \(T\)
+
+
Superconducting Gap-Integrals to calculate \(1/\lambda^2\) vs \(T\)
The details about the various superconducting gap-integrals are found in the
pdf-file GapIntegrals.pdf which can be found in the musrfit source under
<musrfit-dir>/src/external/libGapIntegrals/.
@@ -546,7 +546,7 @@ rge-files (muon stoppping profiles). For this the library reads at start-up the
This is a collection of C++ classes using the musrfituser-functions
+
This is a collection of C++ classes using the musrfituser-functions
interface in order to facilitate the usage in conjunction with musrfit. It consists of two libraries:
libBNMR contains functions to fit spin lattice relaxation (SLR) data.
\(\alpha \cos\left(2\pi\nu t + \frac{\pi \varphi}{180}\right) \exp(-\lambda_{\rm T}t) +\)
\(+ (1-\alpha) \exp(-\lambda_{\rm L} t)\)
@@ -1245,6 +1245,7 @@ Therefore, this block is only present to potentially shorten the msr file and to
data
t0
addt0
+
deadtime-cor 0, 1, 2, 3
fit
rrf_freq for fittype 1, 3
rrf_packing for fittype 1, 3
@@ -1594,6 +1595,14 @@ numbers or the name of the variables as given in the DB header.
+
deadtime-cor
Allows for pulsed sources (currently test with ISIS NeXus files) to perform a deadtime correction on the data.
+
deadtime-corfile
+
+
+
Allowed parameters are no, i.e. no deadtime correction; file, i.e. apply deadtime correction according to the
+parameters dead_time and good_frames read from the NeXus file; estimate will allow in the future to estimate
+the deadtime parameter directley (not yet implemented)
+
fit
The range of data that should be considered when the fitting is done. For the μSR fit types 0, 1, 2, 3, and 4 the
starting and end times are given in micro-seconds. For the non-μSR fit type 8 the starting and end points of the
fitting range are given in the units of the x data.
@@ -2764,8 +2773,8 @@ The syntax here is attribute driven