Welcome to ARTS.

ARTS is free software. Please see the file COPYING for details.

If you use data generated by ARTS in a scientific
publication, then please mention this and cite the most
appropriate of the ARTS publications that are summarized on
http://www.radiativetransfer.org/docs/

For documentation, please see the files in the doc subdirectory.
For building and installation instructions please read below.


BUILDING ARTS
=============

Build Prerequisites:

gcc/g++ (or llvm/clang)
cmake (>=2.8.3)
zlib
blas
lapack
netcdf (optional)

To build the documentation you also need:

pdflatex (optional)
doxygen (optional)
graphviz (optional)


USING CMAKE
===========

Here are the steps to use cmake to build ARTS.

Go into the build directory in the arts directory and run:

cd build
cmake ..
make

If you only want to build the arts executable you can just run 'make arts'
instead of 'make'.

If you have a multi-core processor or multiprocessor machine, don't forget
to use the -j option to speed up the compilation:

make -jX

Where X is the number of parallel build processes.
X=(Number of Cores)+1 gives you usually the fastest compilation time.


BUILD TYPES
===========
To build a release version without assertions or debugging symbols use:

cmake -DCMAKE_BUILD_TYPE=Release ..
make clean
make

To switch back to the debug version use:

cmake -DCMAKE_BUILD_TYPE=RelWithDebInfo ..
make clean
make

This is also the default configuration if you run cmake without
options in an empty build directory.

NATIVE BUILD (EXPERIMENTAL)
===========================

Finally, an experimental build type for Native infrastructures exists on GCC:

cmake -DCMAKE_BUILD_TYPE=Native ..
make clean
make

This option should make the executable slightly faster, more so on better systems,
but not portable.  Note that since this build-mode is meant for fast-but-accurate
computations, some IEEE rules will be ignored.  For now only complex computations
are IEEE incompatible running this mode of build.

TESTS
=====

'make check' will run several test cases to ensure that ARTS is working
properly. Use 'make check-all' to run all available controlfiles, including
computation time-intensive ones.

Some tests depend on the arts-xml-data package. cmake automatically looks if it
is available in the same location as ARTS itself. If necessary, a custom path
can be specified:

cmake -DARTS_XML_DATA_PATH=/home/myname/arts-xml-data ..

If arts-xml-data cannot be found, those tests are ignored.

By default, the tests are executed serially.
If you want to run them concurrently, you can use:

cmake -DTEST_JOBS=X ..

X is the number of tests that should be started in parallel.

You can also use the ctest command directly to run the tests:

ctest -j4

To run specific tests, use the -R option and specify part of the test case
name you want to run. The following command will run all tests that have 'ppath'
in their name, e.g. arts.ctlfile.fast.ppath1d ...:

ctest -R ppath

To see the output of ARTS, use the -V option:

ctest -V -R fast.doit

By default, ctest will not print any output from ARTS to the screen. The option
--output-on-failure can be passed to ctest to see output in the case an error
occurs. If you want to always enable this, you can set the environment variable
CTEST_OUTPUT_ON_FAILURE:

export CTEST_OUTPUT_ON_FAILURE=1


HITRAN CATALOG SUPPORT
======================

By default, ARTS only supports the latest HITRAN 2012 catalog version. Because
isotopologues have been renamed between different catalog versions, ARTS needs
to be compiled for one specific HITRAN version. If you want to use HITRAN
2008, you have to recompile ARTS with:

cmake -DWITH_HITRAN2008=1 ..
make arts

To switch back to HITRAN 2012, run:

cmake -DWITH_HITRAN2008=0 ..
make arts


OPTIONAL FEATURES
=================

To compile features that rely on Fortran code located in the 3rdparty
subdirectory use:

cmake -DENABLE_FORTRAN=1 ..

This enables Disort, Fastem, Refice and Tmatrix.

If necessary, certain Fortran modules can be selectively disabled:

cmake -DENABLE_FORTRAN=1 -DNO_DISORT=1 ..
cmake -DENABLE_FORTRAN=1 -DNO_REFICE=1 ..

IMPORTANT: Only gfortran and Intel Fortran are currently supported.
Also, a 64-bit system is required (size of long type must be 8 bytes).


Enable C_API:
To be able to use the ARTS workspace interface in typhon, you need to enable
building the C API:

cmake -DENABLE_C_API=1 ..


Enable NetCDF:
The basic matpack types can be read from NetCDF files, if NetCDF support
is enabled:

cmake -DENABLE_NETCDF=1 ..


DISABLING FEATURES
==================

Disable assertions:
cmake -DNO_ASSERT=1 ..

Disable OpenMP:
cmake -DNO_OPENMP=1 ..

Disable the built-in documentation server:
cmake -DNO_DOCSERVER=1 ..

Treat warnings as errors:
cmake -DWERROR=1 ..


TMATRIX PRECISION
=================

By default, ARTS uses double-precision for the T-matrix calculations.
When using the Intel compiler, quad-precision can be enable with cmake:

cmake -DENABLE_FORTRAN=1 -DENABLE_TMATRIX_QUAD=1 ..

Note that quad-precision is software emulated. T-matrix calculations will
around 10x slower.


CCACHE SUPPORT
==============

To utilize ccache when available use:

cmake -DENABLE_CCACHE=1 ..

For details see https://ccache.samba.org/


INTEL COMPILER
==============

If you want to compile with the Intel compiler[1], start with an empty build
directory and run:

CC=icc CXX=icpc cmake ..

[1] http://software.intel.com/c-compilers


LLVM/CLANG COMPILER
===================

If you want to compile with the LLVM/Clang compiler[1], start with an empty build
directory and run:

CC=clang CXX=clang++ cmake ..

Optionally, you can enable C++11 support and the new implementation of the standard
C++ library[2] (if available):

CC=clang CXX=clang++ CXXFLAGS="-std=c++11 -stdlib=libc++" cmake ..

Note that at this point, clang does not support OpenMP.

[1] http://clang.llvm.org
[2] http://libcxx.llvm.org


MAC OS X / XCODE
================

If you're on a Mac and have the Apple Xcode development environment installed,
you can generate a project file and use Xcode to build ARTS:

cmake -G Xcode ..
open ARTS.xcodeproj


EXPERIMENTAL FEATURES (ONLY USE IF YOU KNOW WHAT YOU'RE DOING)
==============================================================

Use C++11 and the new libc++ (currently only supported in Xcode builds):

cmake -G Xcode -DWITH_XCODE_LIBCPP=1 ..


VALGRIND PROFILING
==================

The callgrind plugin included in valgrind is the recommended profiling method
for ARTS.

Certain things should be taken into account when calling ARTS with valgrind.
Since recursion (cycles) will lead to wrong profiling results it is
important to use the following settings to obtain profile data for ARTS:

valgrind --tool=callgrind --separate-callers=10 --separate-recs=3 arts -n1 ...

For detail on these options consult the valgrind manual:

http://valgrind.org/docs/manual/cl-manual.html#cl-manual.cycles

-n1 should be passed to ARTS because parallelisation can further scew the
results. Since executing a program in valgrind can lead to 50x slower
execution, it is recommended to create a dedicated, minimal controlfile for
profiling.

After execution with valgrind, the resulting callgrind.out.* file can be
opened in kcachegrind[1] for visualization. It is available as a package for
most Linux distributions.

Note that you don't have to do a full ARTS run. You can cancel the program
after some time when you think you have gathered enough statistics.

[1] https://kcachegrind.github.io/


GPROF PROFILING
===============

To utilize gprof to obtain profiling information, you can configure ARTS
in the following way:

1. Create an new build directory:
cd arts
mkdir build_profile
cd build_profile

2. Compile ARTS with profiling information:
CFLAGS="-pg" CXXFLAGS="-pg" FFLAGS="-pg" cmake ..
make arts

If your gprof version does not support GCC's latest dwarf format, you have
to force a compatible format:
CFLAGS="-pg -gdwarf-3" CXXFLAGS="-pg -gdwarf-3" FFLAGS="-pg -gdwarf-3" cmake ..

3. Run ARTS in the configuration you want to analyze:
src/arts MYCONTROLFILE.arts

4. Step 3 created a file gmon.out with timing information. Use gprof to
analyze it:
gprof src/arts

As gprof adds code overhead into the produced binary, using a sampling profiler
such as 'Instruments' on Mac OS X or callgrind on Linux is recommended to obtain
more realistic timing results.