-
Notifications
You must be signed in to change notification settings - Fork 288
Installation
CLASS is distributed in two ways, via its homepage, http://class-code.net, and via this Github public repository (on this page, click the green button "clone or download"). The zipped archive that you will find on the homepage is the same that you can download here. If you know git, instead of dowloading a zipped archive, you probably want to checkout the code as a complete git repository, with
]$ git clone https://github.com/lesgourg/class_public.git class
In case you are interested in old versions: you can find all the releases of CLASS (since the conversion to git) on the page https://github.com/lesgourg/class_public/releases, with a choice between browsing the source code (designated with the hash code of the version), and downloading a zip or a tar.gz archive. By clicking on the three dots ...
next to a release, you can see the commit message. Due to the internal structure of the branches used for CLASS development, you can see all commits that lead to this point.
Whichever method you chose to download the code, the procedure does not change. After eventually unpacking the zipped archive, you get a directory called class/
, or class_public/
, or this name with a version number at the end. Whatever it is called, go there and just try to make
:
~]$ cd class/
class]$ make
The make
is set to create the class
executable, the library libclass.a
, and the Python wrapper classy
(For more details on the installation and use of the Python wrapper, please refer to the detailed explanation).
If you are a C++ developper, you may need to use our proposed C++ wrapper, located in the cpp/
directory. You still have to compile it on your own. But this wrapper is not necessary for a standard use of CLASS and of MontePython.
Usually, the compilation returns a few lines of warning. The important thing is that it should return no errors.
You can test whether the compilation of the class
executable was successful by trying
class]$ ./class explanatory.ini
The code should run quickly (the execution time depends on your machine, the order of magnitude is the second) and return a bit more than 20 lines of output. The first line should start with Running CLASS version ...
and the last line by Writing output files in ...
. If this worked, you can test that the Python wrapper was also compiled successfully by trying
class]$ python
>>> import classy
>>> exit()
If Python does not complain when your type import classy
, everything is in order. If one of these steps did not succeed, the next section is for you...
First, you must identify where the problem occurs:
-
If you cannot execute
./class explanatory.ini
, you had a problem compiling the C code, i.e. CLASS itself. Then, start reading the next paragraph C compilation issue. -
If you can execute
./class explanatory.ini
, but you got an error message at the end of the compilation, and/or the above testpython; import classy
fails, then you had a problem only with the compilation of the Python wrapperclassy
. In that case:- maybe you don't care, if you want to use only the C code in a terminal, and not Monte Python, nor CLASS from a Python notebook. Then, just ignore the problem, and in the future, just type
make class
instead ofmake
, in order to compile only the C code. - if you do care about the Python wrapper, and/or plan to use Monte Python, you must solve the wrapper compilation issue. Then you should look at the following paragraph Python compilation issue.
- maybe you don't care, if you want to use only the C code in a terminal, and not Monte Python, nor CLASS from a Python notebook. Then, just ignore the problem, and in the future, just type
Usually, the CLASS compilation fails when you use a C compiler that it too old, or not main stream, or incompatible with OpenMP like the default C compiler delivered with MAC OS 10.9 Mavericks and higher.
-
Linux users: the compilation error message probably says that your computer does not understand the command
gcc
or the compilation flagOMPFLAG = -fopenmp
. These are by far the most frequent issues. There are several ways to fix this. -
first check which version of C is installed on your computer. Type
gcc --version
in your terminal:- if the terminal answers that you have
gcc
, version 4.6 or lower, you must update it with a more recent version (4.9, 5.0, 5.1, 5.2, etc.). - if the terminal answers that you do not have
gcc
, you must download it, unless you already have another C compiler which you want to use, and which is called differently (e.g.icc
,pgcc
, etc.).
- if the terminal answers that you have
-
if you choose to download or update the GNU compiler
gcc
: proceed like for installing any other new package on your linux system. Once you are done, check that when you typegcc --version
you get indeed the number of the version you just installed. If you still get the old one, you might have to do something (create a symbolic link from/usr/bin/gcc
to the newgcc
executable, or change the order in your default path list) untilgcc --version
returns the correct version. Then do amake clean; make
, and at least the C code should compile normally. -
if you choose to use another recent C compiler (from Intel, Portland, etc.), there should be no problem, but first you might need to edit two lines in the file
Makefile
located in theclass/
directory. The lineCC = gcc
may need to be replaced with the name of another executable, e.g.CC = icc
orCC = pgcc
, and the lineOMPFLAG = -fopenmp
may need to be updated with the OpenMP flag compatible with the compiler, e.g.OMPFLAG = -openmp
orOMPFLAG = -mp -mp=nonuma -mp=allcores -g
. (If you are not sure, just google a bit to check what is the OpenMP flag name compatible with your compiler). Then do amake clean; make
, and at least the C code should compile normally. -
Mac users with OS 10.8 or earlier: the GNU compiler
gcc
is probably installed on your Mac by default, but in a too old version (version 4.6 and lower were not compatible with OpenMP, the library which allows CLASS to run in parallel on all the cores of your machine). Typegcc --version
to check your version number, and try to get a new one (we recommend 4.9 or higher) using your package manager. -
Mac users with OS 10.9 Mavericks and higher: these systems are based on a C compiler called
clang
which is very good, but unfortunately not supporting OpenMP (the library which allows CLASS to run in parallel on all the cores of your machine). You can check that you are in this case by typinggcc --version
. The second line of output will be something likeApple LLVM version 6.1.0 (clang-602.0.49)...
, maybe with different number, but the wordclang
appears. Then you have different options:-
if you don't want to bother; or if you don't have time to fix the problem; or if you expect to run CLASS only very few times, not caring whether it is fast or slow... then you can simply take the decision that CLASS will not parallelise. In other words, it will use only 1 core on your machine instead of N cores, and it will be approximately N times slower. In that case, you can keep
clang
as a C compiler for CLASS, but you must switch off the OpenMP compilation flag. For that, edit the fileMakefile
in theclass/
directory, locate the lineOMPFLAG = -fopenmp
, and comment it out by typing a#
first. Save and close the Makefile. Finally, typemake clean
andmake
. Now, at least the compilation of the C code should work. Check it with./class explanatory.ini
and then go to the Python compilation section if you have further issues with the Python wrapper compilation. -
the cleanest way is to install another compiler like GNU's
gcc
(recommended version: 4.9 or higher) so that the code can parallelise. After installinggcc
with a package manager like Homebrew, Macports, etc., typegcc --version
. In the best case, you will now get the name of the version of gcc that you just installed. Then just typemake clean; make
and the C code compilation will work. But most frequently,gcc --version
will return the same name as before, that of theclang
compiler. The reason is the following. Given the settings of your computer, the commandgcc
will be searched, first, in your directory/usr/bin/
. Their, there is a binary file called/usr/bin/gcc
, and this is nothing but theclang
compiler installed by default. When you dowloaded GNU'sgcc
, your package manager placed it in another directory, maybe/usr/bin/local/gcc
, or maybe some more complicated name. You need to identify the location of that other file. In the rest of this paragraph we will pretend that it is/usr/bin/local/gcc
. You can check that this is the version that you expect by typing the full path:/usr/bin/local/gcc --version
. Then you must do something so that the commandmake
calls this compiler instead of the default/usr/bin/gcc
. There are many ways to do it.- perhaps the most elegant is to edit the order of default paths on your Mac. This can be done e.g. by editing the file
/etc/paths
. You should place, in our example, the line/usr/local/bin
above the line/usr/bin
. Then, open a new terminal. Now, when you typegcc --version
in that terminal, it should grab the correct compiler. Then just typemake clean; make
and the C code compilation will work. - a simpler way, totally harmless for your computer, is to edit the file
Makefile
located in theclass/
directory. The lineCC = gcc
can then be replaced by the full path of the correct compiler, e.g.CC = /usr/bin/local/gcc
. Then the fix will work only for CLASS: this might be an advantage or an inconvenient for you, depending on what else you are doing on your Mac...
- perhaps the most elegant is to edit the order of default paths on your Mac. This can be done e.g. by editing the file
-
now that you have the C code CLASS compiled on your Mac OS 10.9 or higher, you might still have problems for compiling the Python wrapper (if needed). A classical problem is that upon installation, the Python packages might have been compiled with a C compiler incompatible with the one that you are using now... we give some hints on how to solve these problems in the next paragraph.
-
-
Linux users, or Mac users with OS 10.8 or earlier: if you could compile the C code but not the Python wrapper, you probably have a too old or too recent version of Python, or maybe you have some Python modules missing. You might have several versions of python installed on your computer (different versions from different sources). The compilation of the python wrapper will be done by default by the python version used when you type just the command
python
in a terminal. Try it. You will see the version number, and indications on the version of C used to compile it, e.g.:class]$ python Python 2.7.9 (default, Apr 27 2015, 18:58:46) [GCC 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.49)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>>
The version number should be in the 2.7 range (so 2.7.x). Things can work also with 2.6, provided you complement it with only a few missing packages - but the simplest is to have 2.7. Python 3 is not supposed to be compatible with Python 2 so it won't work at all with 3. If in the previous test you did not get 2.7, you should either install it, or if you already have it somewhere, tell your computer to use the right version. This can be done in various ways. For instance, you can edit the
Makefile
and change the linePYTHON = python
for a different name (e.g.PYTHON = python27
) and/or a different path (e.g.PYTHON = /usr/local/bin/python
). Or you can change the order of default pathes on your computer, so that the version you want is chosen in priority when you typepython
. It is also possible that you have the correct version of Python, but compiled with a C compiler incompatible with what you are now using for compiling CLASS. This is unusual on Linux and Mac <10.9, but it may happen, and you can get a hint of it by looking at the second line of output after typingpython
. If you are in that case, you should download a fresh version of Python, and let it compile with what is now your default C compiler.The other source of trouble is when you have a good python version but missing packages. Normally you will understand that you are in this situation by looking at the compilation error message: the computer will report
ImportError: No module named ...
Most frequently the missing modules arenumpy
and/orcython
. You can cross-check whether they are installed with a short session:class]$ python >>> import numpy >>> import cython >>> exit()
If some of these modules are missing, import them one after each other. The easiest is usually to type just:
class]$ pip install numpy class]$ pip install cython
If this does not work, use your browser to get some help on python modules installation. (Note: for using MontePython, a third module should be installed,
scipy
).With a correct Python version, compiled with a compatible C compiler, and the above 2 modules available, you should be able to compile everything with the command
make
. After installing new versions, compilers, etc., remember to typemake clean
beforemake
, to be sure that you are redoing the compilation from scratch. During the compilation of the Python wrapper, there are always several warnings in the compilation message. Don't be scared by them: as long as they are warnings and not errors, they are harmless. To be sure that everything compiled correctly, do the test mentioned at the top of this page:class]$ python >>> import classy >>> exit()
If this works, you are all set.
-
Mac users with OS 10.9 Mavericks or higher: when you compiled CLASS, you used one of the two options detailed above:
-
either you didn't want to bother and you used the default
gcc
(which is in factclang
) for compilation, eventually loosing parallelisation functionalities. Then, on top of commentingOMPFLAG = -fopenmp
in theMakefile
, you also need to comment the lineextra_link_args=['-lgomp'],
at the end of the filepyhton/setup.py
. Then you may wish to keep using the same logic, and use the default Python version shipped with your Mac... For some reason, this does not work from scratch, you will certainly encounter a stackoverflow error. But Eiichiro Komatsu digged a way to solve the problem. In a nutshell:- Remove all the
-mno-fused-madd
in/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/_sysconfigdata.py
- Remove
_sysconfigdata.pyc
and_sysconfigdata.pyo
in/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/
Note that you have to use root access to make those changes.
- Remove all the
-
or you did install another C compiler (GNU's
gcc
, Intel'sicc
, etc.). Then your remaining problems with Python should be the same as if you were using Linux, and you should go through the previous section, just after Python compilation issue. Pay a special attention to the compatibility between C and Python. This means that you should probably use the same package manager to download, first, the C compiler, and then, Python 2.7 (e.g Homebrew, MacPorts...). Mixing the two (e.g. getting C withbrew gcc
and Python with MacPorts) usually results in a big mess!
-
Please write us if you see a way to improve and expand this documentation, or if your experience contradicts what is written here.