MLwiN system requirements
MLwiN is developed and tested on Windows 11. It may work on previous versions of Windows, however we are unable to test and therefore support this.
Other minimum requirements
32 Mb RAM; 250Mb hard disk.
The actual amount of memory and disk space required will depend on the data being analysed.
Non-Windows operating system compatibility
If you wish to use the MLwiN estimation engine through scripts (for example by running from R2MLwiN or runmlwin) we provide a command line version of the software (called mlnscript, available from here for existing users). This currently supports running on 64-bit versions of Linux, MacOS and FreeBSD.
As an alternative you can run the software within a virtual machine, although this requires a valid Windows license. Several companies provide software for creating and running virtual machines including Oracle Virtualbox, VMWare and Parallels.
See sections below for further details about running the MLwiN estimation engine under Linux, and under MacOS
Running under Linux or FreeBSD
As indicated above, you can use the MLwiN estimation engine through scripts on 64-bit versions of Linux, for example running it from R2MLwiN or runmlwin.
Installing mlnscript, and dependencies, with admin rights (root permissions)
It is relatively straightforward to install mlnscript on a Linux system if you have admin rights (root permissions).
First, download the version of mlnscript, appropriate for the Linux distribution you are using. You can find which distribution you are using by entering the following at the command line in Linux:
$ cat /etc/os-release
You can then request the appropriate version of mlnscript from here.
This will download an .rpm (Red Hat package manager) file if you are running Fedora or Rocky Linux (or .deb if you are running Debian / Ubuntu, or .pkg if you are running FreeBSD: e.g. see https://distrowatch.com/dwres.php?resource=package-management).
You can install the files, and their dependencies, via the following (for .rpm; or using the apt command for Debian-based packages, or the pkg command for FreeBSD):
$ dnf install <mlnscript-xxx.rpm>
Or, if you instead wish to use temporarily elevated privileges to do so:
$ sudo dnf install <mlnscript-xxx.rpm>
Installing mlnscript, and dependencies, without admin rights (root permissions)
If, instead, you do not have admin rights (root permissions), then you can still install mlnscript, but will need to follow some alternative steps. Note that this example assumes mlnscript is downloaded as .rpm (see above).
Download mlnscript
First, download the version of mlnscript , appropriate for the Linux distribution you are using, as detailed above.
Extract the.rpm file
The .rpm file is a package management system, which here contains a .cpio archive file. Assuming p7zip is installed and loaded into the current session, the following will confirm this:
$ 7z l <mlnscript-xxx.rpm>
The command below indicates what the .cpio archive contains, and the file paths into which these contents will be saved:
$ rpm -qlp <mlnscript-xxx.rpm>
We will need to convert the .rpm package into a .cpio archive, and then extract its contents. We can do so with one line of code, as follows:
$ rpm2cpio <mlnscript-xxx.rpm> | cpio -idv
This first converts the .rpm file into a cpio archive. The resulting file is then piped to the cpio command, which extracts files from this archive (i), creates leading directories where needed (d), and verbosely lists the files processed (v). It will extract the contents into the /usr subdirectory of the current directory (i.e. into ~/usr if you are in your home directory; it will list the paths to the files it has extracted).
From this, the mlnscript executable file, and the libmln.so library (a collection of pre-compiled code containing functions required by mlnscript) can be moved to whichever location you wish to store them.
E.g. the following would move mlnscript from the /usr/bin/mlnscript subdirectory of the home directory into the current directory:
$ mv ~/usr/bin/mlnscript mlnscript
Checking for any additional required libraries
Some additional libraries are required in order to run the mlnscript executable. You can find out what these are by listing the shared object files (designated as .so) that mlnscript requires. This can be done via the ldd command. It is helpful to pre-load the libmln.so library first, to ensure all required shared libraries are subsequently listed, as follows (this assumes it is in a subdirectory of the home directory):
$ LD_PRELOAD=~/usr/lib64/libmln.so ldd mlnscript
This will indicate whether any required libraries were “not found”, in which case these will need to be installed. Note that there is a distinction between the symbolic links (symlinks) which may be returned as location markers for the libraries, and the underlying value (full path) of that link. You can return the full path underlying a symlink as follows:
$ readlink -f <symlink>
Note that we have already extracted the mln library, from the .rpm file, as detailed above, so there is no need to install that.
You can use the dnf command (as non-root; i.e. even without admin permissions) to find and download (as .rpm files) any required libraries you do not already have:
$ dnf --resolve download <required_library>
If you download these libraries as .rpm files, you can extract them using the method described earlier, as in the following example (extracting the fmt library, required on some older Linux systems):
$ rpm2cpio fmt-6.2.1-1.el8.x86_64.rpm | cpio -idv
Ensuring mlnscript can find all required libraries
You may need to ensure that mlnscript can find all the libraries required when running under R. You can do this by specifying the following in an .Renviron file. This creates environmental variables for use in subsequent R sessions (e.g. see https://docs.posit.co/ide/user/ide/guide/environments/r/managing-r.html).
For example, if the relevant libraries are stored across two directories, in this example /user/home/user_name and a subdirectory of it, /user/home/user_name/usr/lib64 then these can be specified in an .Renviron file as follows:
LD_LIBRARY_PATH=/user/home/user_name:/user/home/user_name/usr/lib64
Note that if you have already set a value for LD_LIBRARY_PATH (e.g. in your .bashrc file), you can add to this previously set path as follows:
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/user/home/user_name
Here we have added /user/home/user_name/ to the previously set path which is indicated by $LD_LIBRARY_PATH.
In a subsequent R session, you can check the value of LD_LIBRARY_PATH by specifying the following:
R> Sys.getenv("LD_LIBRARY_PATH")
Alternatively you can specify these paths in your login script, if you wish the software to be available outside of R too.
In our case, we needed only to specify /user/home/user_name/usr/lib64 to point to the mln library. Other libraries, such as the blas and lapack, were already available on the system, as indicated by the output from:
$ dnf list --installed | grep lapack
lapack.x86_64 3.8.0-8.el8 @appstream
$dnf list --installed | grep blas
blas.x86_64 3.8.0-8.el8 @appstream
Using mlnscript in R, via library(R2MLwiN)
Next, to use R2MLwiN on Linux, we open R, and then load the R2MLwiN package (assuming you have already installed this, e.g. via install.packages(“R2MLwiN”)) and specify the path to the mlnscript executable; here we’re assuming it’s saved in /user/home/user_name):
R> library("R2MLwiN")
R> options(MLwiN_path="/user/home/user_name/mlnscript")
You can then try to fit an example model, e.g. as follows:
R> (VarCompModel <- runMLwiN( normexam ~ 1 + (1 | school) + (1 | student), data = tutorial))
After some initial output is printed to the console as the model is being estimated, a summary of the model fit should soon be returned as follows:
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
MLwiN (version: unknown or >3.09) multilevel model (Normal)
N min mean max N_complete min_complete mean_complete max_complete
school 65 2 62.44615 198 65 2 62.44615 198
Estimation algorithm: IGLS Elapsed time : 0.07s
Number of obs: 4059 (from total 4059) The model converged after 3 iterations.
Log likelihood: -5505.3
Deviance statistic: 11010.6
----------------------------------------------------------------------------------------------
The model formula:
normexam ~ 1 + (1 | school) + (1 | student)
Level 2: school Level 1: student
----------------------------------------------------------------------------------------------
The fixed part estimates:
Coef. Std. Err. z Pr(>|z|) [95% Conf. Interval]
Intercept -0.01317 0.05363 -0.25 0.806 -0.11827 0.09194
Signif. codes: 0 '***' 0.001 '**' 0.01 '*' 0.05 '.' 0.1 ' ' 1
----------------------------------------------------------------------------------------------
The random part estimates at the school level:
Coef. Std. Err.
var_Intercept 0.16863 0.03245
----------------------------------------------------------------------------------------------
The random part estimates at the student level:
Coef. Std. Err.
var_Intercept 0.84776 0.01897
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Using the MLwiN GUI under a compatibility layer
If, however, you wish to operate MLwiN via its Graphical User Interface (GUI), then our limited testing has shown that MLwiN runs well under the Wine (see http://www.winehq.org) compatibility layer. This is usually provided by the distribution's package manager, although you can build it yourself by following instructions given in the previous link. Depending on your distribution you may be able to install the setup program directly by double-clicking it and shortcuts may be added automatically your your application launcher. If this is not supported you can install MLwiN by putting the downloaded setup file in the current directory and running:
wine msiexec /i MLwiN.msi
You should then be able to run MLwiN with the command:
wine <full path to mlwin.exe>
If you want to avoid the wine prefix you can use the command as root (some distributions set this automatically when you install Wine):
echo ':DOSWin:M::MZ::/usr/bin/wine:' > /proc/sys/fs/binfmt_misc/register
Running under MacOS
As indicated above, you can use the MLwiN estimation engine through scripts on 64-bit versions of MacOS, for example running it from R2MLwiN or runmlwin. Tom Palmer has kindly provided a blog post on setting this up, which you may find useful.
If, however, you wish to operate MLwiN via its Graphical User Interface (GUI), then please see the MacOS version-specific guidance, below.
Running MLwiN (via GUI) under MacOS 10.8-10.14
If you are running a MacOS version between 10.8 and 10.14 you can run the 32-bit version of MLwiN using the Wine binary packages provided on https://wiki.winehq.org/MacOS. To do this simply follow the instuctions under the heading Installing Depreciated WineHQ packages. Once this is installed you need to place the 32-bit MLwiN setup files into a location of your choice, then open this location in a terminal and run:
wine msiexec /i MLwiN.msi
Once MLwiN is installed you can locate the mlwin.exe file in the directory where you installed MLwiN and double-click it to run MLwiN. You may want to create an alias to this so that you can find it more easily in future.
Running MLwiN (via GUI) under MacOS greater than version 10.14
MacOS 10.15 (Catalina) and higher dropped support for 32-bit appications, preventing the packages provided by http://www.winehq.org from working. We do not currently have a way to test MLwiN on these platforms, however you may have success installing a commercial version of Wine provided by https://www.codeweavers.com/crossover/. There are also some experimental free builds available at https://github.com/Gcenx/macOS_Wine_builds however we are unable to provide any advice or support for these. If you do have success with either of these we would be very interested in hearing about it.
Processor feature support
64 bit windows benefits
Since version 3.00 MLwiN has been available as a 64-bit application. This allows it to make full use of the memory installed on the system, as well as make use of some newer processor instructions.
Multi-core, multi-processor possible benefits
MLwiN has been designed for a single CPU and is single-threaded. In multi-processor environments the most benefit MLwiN would gain would be that it could have one of the CPUs to itself without having to fight with other applications and the operating system. If you run MLwiN via R2MLwiN or Stat-JR then you can take advantage of multiple cores by running parallel MCMC chains.
Redesigning MLwiN to take advantage of multiple processors would be a major undertaking, for which we have no immediate plans.
FAQ: Is it possible to run MLwiN on a Citrix-desktop?
Example question:
We are currently re-designing our network, which means that our MLwiN users will have to access the data MLwiN uses through a Citrix-"window" and they will not be allowed to put the data onto their local hard disk. This means that MLwiN cannot run on their computers but must reside in the secure network, and either be processed on the Citrix-server/Citrix-desktop, or running on a dedicated application-server
Answer:
We do not have a Citrix system here to test MLwiN on, so cannot give a definitive answer, however we have had reports of people using MLwiN successfully on this and similar systems. MLwiN 2.10 should have more success that previous versions as it no longer attempts to write files temporarily to its program directory.
One thing to note is that MLwiN loads the whole data set being analysed into memory, so if your users are running models on large data sets on the same machine you may run into memory issues.
Running more complex models can also be quite CPU intensive. Whether this is an issue for you will depend on the number of processors in your server machine and the number of simultaneous MLwiN users. Each instance of MLwiN can only make use of a single processor, so as long as the number of copies running a model is less than or equal to the number of processors in the machine there should be no slowdown compared with running it on the user's machine.