xref: /libCEED/README.md (revision 39b2de37682296be8460181179eb4e44de5cc3de)
1# libCEED: the CEED API Library
2
3[![Build Status](https://travis-ci.org/CEED/libCEED.svg?branch=master)](https://travis-ci.org/CEED/libCEED)
4[![Code Coverage](https://codecov.io/gh/CEED/libCEED/branch/master/graphs/badge.svg)](https://codecov.io/gh/CEED/libCEED/)
5[![License](https://img.shields.io/badge/License-BSD%202--Clause-orange.svg)](https://opensource.org/licenses/BSD-2-Clause)
6[![Doxygen](https://codedocs.xyz/CEED/libCEED.svg)](https://codedocs.xyz/CEED/libCEED/)
7
8## Code for Efficient Extensible Discretization
9
10This repository contains an initial low-level API library for the efficient
11high-order discretization methods developed by the ECP co-design [Center for
12Efficient Exascale Discretizations (CEED)](http://ceed.exascaleproject.org).
13While our focus is on high-order finite elements, the approach is mostly
14algebraic and thus applicable to other discretizations in factored form, as
15explained in the API documentation portion of the [Doxygen documentation](https://codedocs.xyz/CEED/libCEED/md_doc_libCEEDapi.html).
16
17One of the challenges with high-order methods is that a global sparse matrix is
18no longer a good representation of a high-order linear operator, both with
19respect to the FLOPs needed for its evaluation, as well as the memory transfer
20needed for a matvec.  Thus, high-order methods require a new "format" that still
21represents a linear (or more generally non-linear) operator, but not through a
22sparse matrix.
23
24The goal of libCEED is to propose such a format, as well as supporting
25implementations and data structures, that enable efficient operator evaluation
26on a variety of computational device types (CPUs, GPUs, etc.). This new operator
27description is based on algebraically [factored form](https://codedocs.xyz/CEED/libCEED/md_doc_libCEEDapi.html),
28which is easy to incorporate in a wide variety of applications, without significant
29refactoring of their own discretization infrastructure.
30
31The repository is part of the [CEED software suite][ceed-soft], a collection of
32software benchmarks, miniapps, libraries and APIs for efficient exascale
33discretizations based on high-order finite element and spectral element methods.
34See http://github.com/ceed for more information and source code availability.
35
36The CEED research is supported by the [Exascale Computing Project][ecp]
37(17-SC-20-SC), a collaborative effort of two U.S. Department of Energy
38organizations (Office of Science and the National Nuclear Security
39Administration) responsible for the planning and preparation of a [capable
40exascale ecosystem](https://exascaleproject.org/what-is-exascale), including
41software, applications, hardware, advanced system engineering and early testbed
42platforms, in support of the nation’s exascale computing imperative.
43
44For more details on the CEED API see http://ceed.exascaleproject.org/ceed-code/.
45
46## Building
47
48The CEED library, `libceed`, is a C99 library with no external dependencies.  It
49can be built using
50
51    make
52
53or, with optimization flags
54
55    make OPT='-O3 -march=skylake-avx512 -ffp-contract=fast'
56
57These optimization flags are used by all languages (C, C++, Fortran) and this
58makefile variable can also be set for testing and examples (below).
59
60The library attempts to automatically detect support for the AVX
61instruction set using gcc-style compiler options for the host.
62Support may need to be manually specified via
63
64    make AVX=1
65
66or
67
68    make AVX=0
69
70if your compiler does not support gcc-style options, if you are cross
71compiling, etc.
72
73## Testing
74
75The test suite produces [TAP](https://testanything.org) output and is run by:
76
77    make test
78
79or, using the `prove` tool distributed with Perl (recommended)
80
81    make prove
82
83## Backends
84
85There are multiple supported backends, which can be selected at runtime in the examples:
86
87|  CEED resource           | Backend                                           |
88| :----------------------- | :------------------------------------------------ |
89| `/cpu/self/ref/serial`   | Serial reference implementation                   |
90| `/cpu/self/ref/blocked`  | Blocked refrence implementation                   |
91| `/cpu/self/memcheck`     | Memcheck backend, undefined value checks          |
92| `/cpu/self/opt/serial`   | Serial optimized C implementation                 |
93| `/cpu/self/opt/blocked`  | Blocked optimized C implementation                |
94| `/cpu/self/avx/serial`   | Serial AVX implementation                         |
95| `/cpu/self/avx/blocked`  | Blocked AVX implementation                        |
96| `/cpu/self/xsmm/serial`  | Serial LIBXSMM implementation                     |
97| `/cpu/self/xsmm/blocked` | Blocked LIBXSMM implementation                    |
98| `/cpu/occa`              | Serial OCCA kernels                               |
99| `/gpu/occa`              | CUDA OCCA kernels                                 |
100| `/omp/occa`              | OpenMP OCCA kernels                               |
101| `/ocl/occa`              | OpenCL OCCA kernels                               |
102| `/gpu/cuda/ref`          | Reference pure CUDA kernels                       |
103| `/gpu/cuda/reg`          | Pure CUDA kernels using one thread per element    |
104| `/gpu/cuda/shared`       | Optimized pure CUDA kernels using shared memory   |
105| `/gpu/cuda/gen`          | Optimized pure CUDA kernels using code generation |
106| `/gpu/magma`             | CUDA MAGMA kernels                                |
107
108The `/cpu/self/*/serial` backends process one element at a time and are intended for meshes
109with a smaller number of high order elements. The `/cpu/self/*/blocked` backends process
110blocked batches of eight interlaced elements and are intended for meshes with higher numbers
111of elements.
112
113The `/cpu/self/ref/*` backends are written in pure C and provide basic functionality.
114
115The `/cpu/self/opt/*` backends are written in pure C and use partial e-vectors to improve performance.
116
117The `/cpu/self/avx/*` backends rely upon AVX instructions to provide vectorized CPU performance.
118
119The `/cpu/self/xsmm/*` backends rely upon the [LIBXSMM](http://github.com/hfp/libxsmm) package
120to provide vectorized CPU performance. If linking MKL and LIBXSMM is desired but
121the Makefile is not detecting `MKLROOT`, linking libCEED against MKL can be
122forced by setting the environment variable `MKL=1`.
123
124The `/cpu/self/memcheck/*` backends rely upon the [Valgrind](http://valgrind.org/) Memcheck tool
125to help verify that user QFunctions have no undefined values. To use, run your code with
126Valgrind and the Memcheck backends, e.g. `valgrind ./build/ex1 -ceed /cpu/self/ref/memcheck`. A
127'development' or 'debugging' version of Valgrind with headers is required to use this backend.
128This backend can be run in serial or blocked mode and defaults to running in the serial mode
129if `/cpu/self/memcheck` is selected at runtime.
130
131The `/*/occa` backends rely upon the [OCCA](http://github.com/libocca/occa) package to provide
132cross platform performance.
133
134The `/gpu/cuda/*` backends provide GPU performance strictly using CUDA.
135
136The `/gpu/magma` backend relies upon the [MAGMA](https://bitbucket.org/icl/magma) package.
137
138## Examples
139
140libCEED comes with several examples of its usage, ranging from standalone C
141codes in the `/examples/ceed` directory to examples based on external packages,
142such as MFEM, PETSc, and Nek5000. Nek5000 v18.0 or greater is required.
143
144To build the examples, set the `MFEM_DIR`, `PETSC_DIR` and `NEK5K_DIR` variables
145and run:
146
147```console
148# libCEED examples on CPU and GPU
149cd examples/ceed
150make
151./ex1 -ceed /cpu/self
152./ex1 -ceed /gpu/occa
153cd ../..
154
155# MFEM+libCEED examples on CPU and GPU
156cd examples/mfem
157make
158./bp1 -ceed /cpu/self -no-vis
159./bp3 -ceed /gpu/occa -no-vis
160cd ../..
161
162# Nek5000+libCEED examples on CPU and GPU
163cd examples/nek
164make
165./nek-examples.sh -e bp1 -ceed /cpu/self -b 3
166./nek-examples.sh -e bp3 -ceed /gpu/occa -b 3
167cd ../..
168
169# PETSc+libCEED examples on CPU and GPU
170cd examples/petsc
171make
172./bps -problem bp1 -ceed /cpu/self
173./bps -problem bp2 -ceed /gpu/occa
174./bps -problem bp3 -ceed /cpu/self
175./bps -problem bp4 -ceed /gpu/occa
176./bps -problem bp5 -ceed /cpu/self
177./bps -problem bp6 -ceed /gpu/occa
178cd ../..
179
180cd examples/navier-stokes
181make
182./navierstokes -ceed /cpu/self
183./navierstokes -ceed /gpu/occa
184cd ../..
185```
186
187The above code assumes a GPU-capable machine with the OCCA backend
188enabled. Depending on the available backends, other Ceed resource specifiers can
189be provided with the `-ceed` option.
190
191## Benchmarks
192
193A sequence of benchmarks for all enabled backends can be run using
194
195```console
196make benchmarks
197```
198
199The results from the benchmarks are stored inside the `benchmarks/` directory
200and they can be viewed using the commands (requires python with matplotlib):
201
202```console
203cd benchmarks
204python postprocess-plot.py petsc-bps-bp1-*-output.txt
205python postprocess-plot.py petsc-bps-bp3-*-output.txt
206```
207
208Using the `benchmarks` target runs a comprehensive set of benchmarks which may
209take some time to run. Subsets of the benchmarks can be run using the scripts in the `benchmarks` folder.
210
211For more details about the benchmarks, see
212[`benchmarks/README.md`](benchmarks/README.md)
213
214
215## Install
216
217To install libCEED, run
218
219    make install prefix=/usr/local
220
221or (e.g., if creating packages),
222
223    make install prefix=/usr DESTDIR=/packaging/path
224
225Note that along with the library, libCEED installs kernel sources, e.g. OCCA
226kernels are installed in `$prefix/lib/okl`. This allows the OCCA backend to
227build specialized kernels at run-time. In a normal setting, the kernel sources
228will be found automatically (relative to the library file `libceed.so`).
229However, if that fails (e.g. if `libceed.so` is moved), one can copy (cache) the
230kernel sources inside the user OCCA directory, `~/.occa` using
231
232    $(OCCA_DIR)/bin/occa cache ceed $(CEED_DIR)/lib/okl/*.okl
233
234This will allow OCCA to find the sources regardless of the location of the CEED
235library. One may occasionally need to clear the OCCA cache, which can be accomplished
236by removing the `~/.occa` directory or by calling `$(OCCA_DIR)/bin/occa clear -a`.
237
238### pkg-config
239
240In addition to library and header, libCEED provides a [pkg-config][pkg-config1]
241file that can be used to easily compile and link. [For example][pkg-config2], if
242`$prefix` is a standard location or you set the environment variable
243`PKG_CONFIG_PATH`,
244
245    cc `pkg-config --cflags --libs ceed` -o myapp myapp.c
246
247will build `myapp` with libCEED.  This can be used with the source or
248installed directories.  Most build systems have support for pkg-config.
249
250## Contact
251
252You can reach the libCEED team by emailing [ceed-users@llnl.gov](mailto:ceed-users@llnl.gov)
253or by leaving a comment in the [issue tracker](https://github.com/CEED/libCEED/issues).
254
255## Copyright
256
257The following copyright applies to each file in the CEED software suite, unless
258otherwise stated in the file:
259
260> Copyright (c) 2017, Lawrence Livermore National Security, LLC. Produced at the
261> Lawrence Livermore National Laboratory. LLNL-CODE-734707. All Rights reserved.
262
263See files LICENSE and NOTICE for details.
264
265[ceed-soft]:   http://ceed.exascaleproject.org/software/
266[ecp]:         https://exascaleproject.org/exascale-computing-project
267[pkg-config1]: https://en.wikipedia.org/wiki/Pkg-config
268[pkg-config2]: https://people.freedesktop.org/~dbn/pkg-config-guide.html#faq
269