.. _sec-getting-started:

Getting Started
---------------

PETSc consists of a collection of classes,
which are discussed in detail in later parts of the manual (:doc:`programming` and :doc:`additional`).
The important PETSc classes include

-  index sets (``IS``),  for indexing into
   vectors, renumbering, permuting, etc;

-  vectors (``Vec``); :any:`chapter_vectors`

-  matrices (``Mat``) (generally sparse); :any:`chapter_matrices`

-  Krylov subspace methods (``KSP``); :any:`chapter_ksp`

-  preconditioners, including multigrid, block solvers, patch solvers, and
   sparse direct solvers (``PC``);

-  nonlinear solvers (``SNES``); :any:`chapter_snes`

-  timesteppers for solving time-dependent (nonlinear) PDEs, including
   support for differential algebraic equations, and the computation of
   adjoints (sensitivities/gradients of the solutions) (``TS``); :any:`chapter_ts`

-  scalable optimization algorithms including a rich set of gradient-based optimizers,
   Newton-based optimizers and optimization with constraints (``Tao``). :any:`chapter_tao`

-  code for managing interactions between mesh data structures and vectors,
   matrices, and solvers (``DM``); :any:`chapter_dmbase`

Each class consist of an abstract interface (simply a set of calling
sequences; an abstract base class in C++) and an implementation for each algorithm and data structure.
This design enables easy comparison and use of different
algorithms (for example, to experiment with different Krylov subspace
methods, preconditioners, or truncated Newton methods). Hence, PETSc
provides a rich environment for modeling scientific applications as well
as for rapid algorithm design and prototyping.

The classes enable easy customization and extension of both algorithms
and implementations. This approach promotes code reuse and flexibility,
and also separates the issues of parallelism from the choice of algorithms.
The PETSc infrastructure creates a foundation for building large-scale
applications.

It is useful to consider the interrelationships among different pieces
of PETSc. :any:`fig_library` is a diagram of some
of these pieces. The figure illustrates the library’s hierarchical
organization, which enables users to employ the solvers that are most
appropriate for a particular problem.

.. figure:: /images/docs/manual/library_structure.svg
  :alt: PETSc numerical libraries
  :name: fig_library

  Numerical Libraries in PETSc

Suggested Reading
~~~~~~~~~~~~~~~~~

The manual is divided into four parts:

-  :doc:`introduction`

-  :doc:`programming`

-  :doc:`dm`

-  :doc:`additional`

:doc:`introduction` describes the basic procedure for using the PETSc library and
presents simple examples of solving linear systems with PETSc. This
section conveys the typical style used throughout the library and
enables the application programmer to begin using the software
immediately.

:doc:`programming` explains in detail the use of the various PETSc algebraic objects, such
as vectors, matrices, index sets and the PETSc solvers including linear and nonlinear solvers, time integrators,
and optimization support. :doc:`dm` details how a user's models and discretizations can easily be interfaced with the
solvers by using the `DM` construct. The :doc:`additional` describes a variety of useful information, including
profiling, the options database, viewers, error handling, and some
details of PETSc design.

PETSc has evolved to become quite a comprehensive package, and therefore
this manual can be rather intimidating for new users. Bear in mind that PETSc can be used
efficiently before one understands all of the material presented here.
Furthermore, the definitive reference for any PETSc function is always
the online manual page.
Manual pages for all PETSc functions can be accessed `here <docs/index.html>`__.
The manual pages provide hyperlinked indices (organized by both concept
and routine name) to the tutorial examples and enable easy movement
among related topics.

`Visual Studio Code <https://code.visualstudio.com/>`__, Eclipse, Emacs, and Vim users may find their development environment's options for
searching in the source code are
useful for exploring the PETSc source code. Details of these
feature are provided in :any:`sec-developer-environments`.

The complete PETSc distribution, manual pages, and additional information are available via the
`PETSc home page <https://petsc.org/>`__. The PETSc
home page also contains details regarding installation, new features and
changes in recent versions of PETSc, machines that we currently support,
and a frequently asked questions (FAQ) list.

**Note to Fortran Programmers**: In most of the manual, the examples and calling sequences are given
for the C/C++ family of programming languages. However, Fortran
programmers can use all of the functionality of PETSc from Fortran,
with only minor differences in the user interface.
:any:`chapter_fortran` provides a discussion of the differences between
using PETSc from Fortran and C, as well as several complete Fortran
examples. 

**Note to Python Programmers**: To program with PETSc in Python you need to enable Python bindings
(i.e petsc4py) with the configure option ``--with-petsc4py=1``. See the
:doc:`PETSc installation guide </install/index>`
for more details.

.. _sec-running:

Running PETSc Programs
~~~~~~~~~~~~~~~~~~~~~~

Before using PETSc, the user must first set the environmental variable
``$PETSC_DIR``, indicating the full path of the PETSc home directory. For
example, under the Unix bash shell a command of the form

.. code-block:: console

   $ export PETSC_DIR=$HOME/petsc

can be placed in the user’s ``.bashrc`` or other startup file. In
addition, the user may need to set the environment variable
``$PETSC_ARCH`` to specify a particular configuration of the PETSc
libraries. Note that ``$PETSC_ARCH`` is just a name selected by the
installer to refer to the libraries compiled for a particular set of
compiler options and machine type. Using different values of
``$PETSC_ARCH`` allows one to switch between several different sets (say
debug and optimized) of libraries easily. To determine if you need to
set ``$PETSC_ARCH``, look in the directory indicated by ``$PETSC_DIR``, if
there are subdirectories beginning with ``arch`` then those
subdirectories give the possible values for ``$PETSC_ARCH``.

All PETSc programs use the MPI (Message Passing Interface) standard for
message-passing communication :cite:`MPI-final`. Thus, to
execute PETSc programs, users must know the procedure for beginning MPI
jobs on their selected computer system(s). For instance, when using the
`MPICH <https://www.mpich.org/>`__ implementation of MPI and many
others, the following command initiates a program that uses eight
processors:

.. code-block:: console

   $ mpiexec -n 8 ./petsc_program_name petsc_options

PETSc also comes with a script that automatically uses the correct
``mpiexec`` for your configuration.

.. code-block:: console

   $ $PETSC_DIR/lib/petsc/bin/petscmpiexec -n 8 ./petsc_program_name petsc_options

All PETSc-compliant programs support the use of the ``-help``
option as well as the ``-version`` option.

Certain options are supported by all PETSc programs. We list a few
particularly useful ones below; a complete list can be obtained by
running any PETSc program with the option ``-help``.

-  ``-log_view`` - summarize the program’s performance (see :any:`ch_profiling`)

-  ``-fp_trap`` - stop on floating-point exceptions; for example divide
   by zero

-  ``-malloc_dump`` - enable memory tracing; dump list of unfreed memory
   at conclusion of the run, see
   :any:`detecting-memory-problems`,

-  ``-malloc_debug`` - enable memory debugging (by default this is
   activated for the debugging version of PETSc), see
   :any:`detecting-memory-problems`,

-  ``-start_in_debugger`` ``[noxterm,gdb,lldb]``
   ``[-display name]`` - start all processes in debugger. See
   :any:`sec-debugging`, for more information on
   debugging PETSc programs.

-  ``-on_error_attach_debugger`` ``[noxterm,gdb,lldb]``
   ``[-display name]`` - start debugger only on encountering an error

-  ``-info`` - print a great deal of information about what the program
   is doing as it runs


.. _sec_writing:

Writing PETSc Programs
~~~~~~~~~~~~~~~~~~~~~~

Most PETSc programs begin with a call to

.. code-block::

   PetscInitialize(int *argc,char ***argv,char *file,char *help);

which initializes PETSc and MPI. The arguments ``argc`` and ``argv`` are
the command line arguments delivered in all C and C++ programs. The
argument ``file`` optionally indicates an alternative name for the PETSc
options file, ``.petscrc``, which resides by default in the user’s home
directory. :any:`sec_options` provides details
regarding this file and the PETSc options database, which can be used
for runtime customization. The final argument, ``help``, is an optional
character string that will be printed if the program is run with the
``-help`` option. In Fortran the initialization command has the form

.. code-block:: fortran

   call PetscInitialize(character(*) file,integer ierr)

Where the file argument is optional. ``PetscInitialize()`` automatically calls ``MPI_Init()`` if MPI has not
been not previously initialized. In certain circumstances in which MPI
needs to be initialized directly (or is initialized by some other
library), the user can first call ``MPI_Init()`` (or have the other
library do it), and then call ``PetscInitialize()``. By default,
``PetscInitialize()`` sets the PETSc “world” communicator
``PETSC_COMM_WORLD`` to ``MPI_COMM_WORLD``.

For those not familiar with MPI, a *communicator* is a way of indicating
a collection of processes that will be involved together in a
calculation or communication. Communicators have the variable type
``MPI_Comm``. In most cases users can employ the communicator
``PETSC_COMM_WORLD`` to indicate all processes in a given run and
``PETSC_COMM_SELF`` to indicate a single process.

MPI provides routines for generating new communicators consisting of
subsets of processors, though most users rarely need to use these. The
book *Using MPI*, by Lusk, Gropp, and Skjellum
:cite:`using-mpi` provides an excellent introduction to the
concepts in MPI. See also the `MPI homepage <https://www.mcs.anl.gov/research/projects/mpi/>`__. 
Note that PETSc users
need not program much message passing directly with MPI, but they must
be familiar with the basic concepts of message passing and distributed
memory computing.

All PETSc programs should call ``PetscFinalize()`` as their final (or
nearly final) statement. This routine handles options to be called at the conclusion of the
program, and calls ``MPI_Finalize()`` if ``PetscInitialize()`` began
MPI. If MPI was initiated externally from PETSc (by either the user or
another software package), the user is responsible for calling
``MPI_Finalize()``.

Error Checking
^^^^^^^^^^^^^^

Most PETSc functions return a ``PetscErrorCode``, which is an integer
indicating whether an error has occurred during the call. The error code
is set to be nonzero if an error has been detected; otherwise, it is
zero. For the C/C++ interface, the error variable is the routine’s
return value, while for the Fortran version, each PETSc routine has as
its final argument an integer error variable.

One should always check these routine values as given below in the C/C++ and Fortran
formats, respectively:

.. code-block:: c

   PetscCall(PetscFunction(Args));

or

.. code-block:: fortran

   ! within the main program
   PetscCallA(PetscFunction(Args,ierr))

.. code-block:: fortran

   ! within any subroutine
   PetscCall(PetscFunction(Args,ierr))


These macros check the returned error code and if it is nonzero they call the PETSc error
handler and then return from the function with the error code. ``` PetscCallA()``` calls abort
after calling the error handler because it is not possible to return from a Fortran main
program. The above macros should be used in all subroutines to enable
a complete error traceback. See :any:`sec_error2` for more details on PETSc error handling.

.. _sec_simple:

Simple PETSc Examples
~~~~~~~~~~~~~~~~~~~~~

To help the user start using PETSc immediately, we begin with a simple
uniprocessor example that
solves the one-dimensional Laplacian problem with finite differences.
This sequential code, which can be found in
``$PETSC_DIR/src/ksp/ksp/tutorials/ex1.c``, illustrates the solution of
a linear system with ``KSP``, the interface to the preconditioners,
Krylov subspace methods, and direct linear solvers of PETSc. Following
the code we highlight a few of the most important parts of this example.

.. admonition:: Listing: `KSP Tutorial src/ksp/ksp/tutorials/ex1.c <PETSC_DOC_OUT_ROOT_PLACEHOLDER/src/ksp/ksp/tutorials/ex1.c.html>`__
   :name: ksp-ex1

   .. literalinclude:: /../src/ksp/ksp/tutorials/ex1.c
      :end-before: /*TEST

Include Files
^^^^^^^^^^^^^

The C/C++ include files for PETSc should be used via statements such as

.. code-block::

   #include <petscksp.h>

where ``petscksp.h`` is the include file for the linear solver library.
Each PETSc program must specify an include file that corresponds to the
highest level PETSc objects needed within the program; all of the
required lower level include files are automatically included within the
higher level files. For example, ``petscksp.h`` includes ``petscmat.h``
(matrices), ``petscvec.h`` (vectors), and ``petscsys.h`` (base PETSc
file). The PETSc include files are located in the directory
``$PETSC_DIR/include``. See :any:`sec_fortran_includes`
for a discussion of PETSc include files in Fortran programs.

The Options Database
^^^^^^^^^^^^^^^^^^^^

As shown in :any:`sec_simple`, the user can
input control data at run time using the options database. In this
example the command ``PetscOptionsGetInt(NULL,NULL,"-n",&n,&flg);``
checks whether the user has provided a command line option to set the
value of ``n``, the problem dimension. If so, the variable ``n`` is set
accordingly; otherwise, ``n`` remains unchanged. A complete description
of the options database may be found in :any:`sec_options`.

.. _sec_vecintro:

Vectors
^^^^^^^

One creates a new parallel or sequential vector, ``x``, of global
dimension ``M`` with the commands

.. code-block::

   VecCreate(MPI_Comm comm,Vec *x);
   VecSetSizes(Vec x, PetscInt m, PetscInt M);

where ``comm`` denotes the MPI communicator and ``m`` is the optional
local size which may be ``PETSC_DECIDE``. The type of storage for the
vector may be set with either calls to ``VecSetType()`` or
``VecSetFromOptions()``. Additional vectors of the same type can be
formed with

.. code-block::

   VecDuplicate(Vec old,Vec *new);

The commands

.. code-block::

   VecSet(Vec x,PetscScalar value);
   VecSetValues(Vec x,PetscInt n,PetscInt *indices,PetscScalar *values,INSERT_VALUES);

respectively set all the components of a vector to a particular scalar
value and assign a different value to each component. More detailed
information about PETSc vectors, including their basic operations,
scattering/gathering, index sets, and distributed arrays, is discussed
in Chapter :any:`chapter_vectors`.

Note the use of the PETSc variable type ``PetscScalar`` in this example.
The ``PetscScalar`` is simply defined to be ``double`` in C/C++ (or
correspondingly ``double precision`` in Fortran) for versions of PETSc
that have *not* been compiled for use with complex numbers. The
``PetscScalar`` data type enables identical code to be used when the
PETSc libraries have been compiled for use with complex numbers.
:any:`sec_complex` discusses the use of complex
numbers in PETSc programs.

.. _sec_matintro:

Matrices
^^^^^^^^

Usage of PETSc matrices and vectors is similar. The user can create a
new parallel or sequential matrix, ``A``, which has ``M`` global rows
and ``N`` global columns, with the routines

.. code-block::

   MatCreate(MPI_Comm comm,Mat *A);
   MatSetSizes(Mat A,PETSC_DECIDE,PETSC_DECIDE,PetscInt M,PetscInt N);

where the matrix format can be specified at runtime via the options
database. The user could alternatively specify each processes’ number of
local rows and columns using ``m`` and ``n``.

.. code-block::

   MatSetSizes(Mat A,PetscInt m,PetscInt n,PETSC_DETERMINE,PETSC_DETERMINE);

Generally one then sets the “type” of the matrix, with, for example,

.. code-block::

   MatSetType(A,MATAIJ);

This causes the matrix ``A`` to used the compressed sparse row storage
format to store the matrix entries. See ``MatType`` for a list of all
matrix types. Values can then be set with the command

.. code-block::

   MatSetValues(Mat A,PetscInt m,PetscInt *im,PetscInt n,PetscInt *in,PetscScalar *values,INSERT_VALUES);

After all elements have been inserted into the matrix, it must be
processed with the pair of commands

.. code-block::

   MatAssemblyBegin(A,MAT_FINAL_ASSEMBLY);
   MatAssemblyEnd(A,MAT_FINAL_ASSEMBLY);

:any:`chapter_matrices` discusses various matrix formats as
well as the details of some basic matrix manipulation routines.

Linear Solvers
^^^^^^^^^^^^^^

After creating the matrix and vectors that define a linear system,
``Ax`` :math:`=` ``b``, the user can then use ``KSP`` to solve the
system with the following sequence of commands:

.. code-block::

   KSPCreate(MPI_Comm comm,KSP *ksp);
   KSPSetOperators(KSP ksp,Mat Amat,Mat Pmat);
   KSPSetFromOptions(KSP ksp);
   KSPSolve(KSP ksp,Vec b,Vec x);
   KSPDestroy(KSP ksp);

The user first creates the ``KSP`` context and sets the operators
associated with the system (matrix that defines the linear system,
``Amat`` and matrix from which the preconditioner is constructed,
``Pmat``). The user then sets various options for customized solution,
solves the linear system, and finally destroys the ``KSP`` context. We
emphasize the command ``KSPSetFromOptions()``, which enables the user to
customize the linear solution method at runtime by using the options
database, which is discussed in :any:`sec_options`. Through this database, the
user not only can select an iterative method and preconditioner, but
also can prescribe the convergence tolerance, set various monitoring
routines, etc. (see, e.g., :any:`sec_profiling_programs`).

:any:`chapter_ksp` describes in detail the ``KSP`` package,
including the ``PC`` and ``KSP`` packages for preconditioners and Krylov
subspace methods.

Nonlinear Solvers
^^^^^^^^^^^^^^^^^

Most PDE problems of interest are inherently nonlinear. PETSc provides
an interface to tackle the nonlinear problems directly called ``SNES``.
:any:`chapter_snes` describes the nonlinear
solvers in detail. We highly recommend most PETSc users work directly with
``SNES``, rather than using PETSc for the linear problem and writing their own
nonlinear solver.

.. _sec_error2:

Error Checking
^^^^^^^^^^^^^^

As noted above PETSc functions return a ``PetscErrorCode``, which is an integer
indicating whether an error has occurred during the call. Below, we indicate a traceback
generated by error detection within a sample PETSc program. The error
occurred on line 3618 of the file
``$PETSC_DIR/src/mat/impls/aij/seq/aij.c`` and was caused by trying to
allocate too large an array in memory. The routine was called in the
program ``ex3.c`` on line 66. See
:any:`sec_fortran_errors` for details regarding error checking
when using the PETSc Fortran interface.

.. code-block:: none

    $ cd $PETSC_DIR/src/ksp/ksp/tutorials
    $ make ex3
    $ mpiexec -n 1 ./ex3 -m 100000
    [0]PETSC ERROR: --------------------- Error Message --------------------------------
    [0]PETSC ERROR: Out of memory. This could be due to allocating
    [0]PETSC ERROR: too large an object or bleeding by not properly
    [0]PETSC ERROR: destroying unneeded objects.
    [0]PETSC ERROR: Memory allocated 11282182704 Memory used by process 7075897344
    [0]PETSC ERROR: Try running with -malloc_dump or -malloc_view for info.
    [0]PETSC ERROR: Memory requested 18446744072169447424
    [0]PETSC ERROR: See https://www.mcs.anl.gov/petsc/documentation/faq.html for trouble shooting.
    [0]PETSC ERROR: Petsc Development GIT revision: v3.7.1-224-g9c9a9c5  GIT Date: 2016-05-18 22:43:00 -0500
    [0]PETSC ERROR: ./ex3 on a arch-darwin-double-debug named Patricks-MacBook-Pro-2.local by patrick Mon Jun 27 18:04:03 2016
    [0]PETSC ERROR: Configure options PETSC_DIR=/Users/patrick/petsc PETSC_ARCH=arch-darwin-double-debug --download-mpich --download-f2cblaslapack --with-cc=clang --with-cxx=clang++ --with-fc=gfortran --with-debugging=1 --with-precision=double --with-scalar-type=real --with-viennacl=0 --download-c2html -download-sowing
    [0]PETSC ERROR: #1 MatSeqAIJSetPreallocation_SeqAIJ() line 3618 in /Users/patrick/petsc/src/mat/impls/aij/seq/aij.c
    [0]PETSC ERROR: #2 PetscTrMallocDefault() line 188 in /Users/patrick/petsc/src/sys/memory/mtr.c
    [0]PETSC ERROR: #3 MatSeqAIJSetPreallocation_SeqAIJ() line 3618 in /Users/patrick/petsc/src/mat/impls/aij/seq/aij.c
    [0]PETSC ERROR: #4 MatSeqAIJSetPreallocation() line 3562 in /Users/patrick/petsc/src/mat/impls/aij/seq/aij.c
    [0]PETSC ERROR: #5 main() line 66 in /Users/patrick/petsc/src/ksp/ksp/tutorials/ex3.c
    [0]PETSC ERROR: PETSc Option Table entries:
    [0]PETSC ERROR: -m 100000
    [0]PETSC ERROR: ----------------End of Error Message ------- send entire error message to petsc-maint@mcs.anl.gov----------

When running the debug version of the PETSc libraries, it does a great
deal of checking for memory corruption (writing outside of array bounds
etc). The macro ``CHKMEMQ`` can be called anywhere in the code to check
the current status of the memory for corruption. By putting several (or
many) of these macros into your code you can usually easily track down
in what small segment of your code the corruption has occurred. One can
also use Valgrind to track down memory errors; see the `FAQ <https://petsc.org/release/faq/>`__.

For complete error handling, calls to MPI functions should be made with ``PetscCallMPI(MPI_Function(Args))``.
In the main Fortran program the calls should be ``PetscCallMPIA(MPI_Function(Args))``.

PETSc has a small number of C/C++ only macros that do not explicitly return error codes. These are used in the style

.. code-block:: c

   XXXBegin(Args);
   other code
   XXXEnd();

and include ``PetscOptionsBegin()``, ``PetscOptionsEnd()``, ``PetscObjectOptionsBegin()``, 
``PetscOptionsHeadBegin()``, ``PetscOptionsHeadEnd()``, ``PetscDrawCollectiveBegin()``, ``PetscDrawCollectiveEnd()``,
``MatPreallocateEnd()``, and ``MatPreallocateBegin()``. These should not be checked for error codes.
Another class of functions with the ``Begin()`` and ``End()`` paradigm
including ``PetscLogBegin()``, ``PetscLogEnd()``, ``MatAssemblyBegin()``, and ``MatAssemblyEnd()`` do return error codes that should be checked.

PETSc also has a set of C/C++ only macros that return an object, or ``NULL`` if an error has been detected. These include
``PETSC_VIEWER_STDOUT_WORLD``, ``PETSC_VIEWER_DRAW_WORLD``, ``PETSC_VIEWER_STDOUT_(MPI_Comm)``, and ``PETSC_VIEWER_DRAW_(MPI_Comm)``.

Finally ``PetscObjectComm((PetscObject)x)`` returns the communicator associated with the object ``x`` or ``MPI_COMM_NULL`` if an
error was detected.



.. _sec_parallel:

Parallel and GPU Programming
----------------------------

Numerical computing today has multiple levels of parallelism (concurrency).

- Low-level, single instruction multiple data (SIMD) parallelism or, somewhat similar, on-GPU parallelism,

- Medium-level, multiple instruction shared memory parallelism (thread parallelism), and

- High-level, distributed memory parallelism

Traditional CPUs support the lower two levels via, for example, Intel AVX-like instructions (:any:`sec_cpu_simd`) and Unix threads, often managed by using OpenMP pragmas (:any:`sec_cpu_openmp`),
(or multiple processes). GPUs also support the lower two levels via kernel functions (:any:`sec_gpu_kernels`) and streams (:any:`sec_gpu_streams`).
Distributed memory parallelism is created by combining multiple
CPUs and/or GPUs and using MPI for communication (:any:`sec_mpi`).

In addition there is also concurrency between computations (floating point operations) and data movement (from memory to caches and registers
and via MPI between distinct memory nodes).

PETSc provides support for all these levels of parallelism but its strongest support is for MPI-based distributed memory parallelism.

.. _sec_mpi:

MPI Parallelism
~~~~~~~~~~~~~~~

Since PETSc uses the message-passing model for parallel programming and
employs MPI for all interprocessor communication, the user is free to
employ MPI routines as needed throughout an application code. However,
by default the user is shielded from many of the details of message
passing within PETSc, since these are hidden within parallel objects,
such as vectors, matrices, and solvers. In addition, PETSc provides
tools such as generalized vector scatters/gathers to assist in the
management of parallel data.

Recall that the user must specify a communicator upon creation of any
PETSc object (such as a vector, matrix, or solver) to indicate the
processors over which the object is to be distributed. For example, as
mentioned above, some commands for matrix, vector, and linear solver
creation are:

.. code-block::

   MatCreate(MPI_Comm comm,Mat *A);
   VecCreate(MPI_Comm comm,Vec *x);
   KSPCreate(MPI_Comm comm,KSP *ksp);

The creation routines are collective over all processors in the
communicator; thus, all processors in the communicator *must* call the
creation routine. In addition, if a sequence of collective routines is
being used, they *must* be called in the same order on each processor.

The next example, given below,
illustrates the solution of a linear system in parallel. This code,
corresponding to
`KSP Tutorial ex2 <PETSC_DOC_OUT_ROOT_PLACEHOLDER/src/ksp/ksp/tutorials/ex2.c.html>`__,
handles the two-dimensional Laplacian discretized with finite
differences, where the linear system is again solved with KSP. The code
performs the same tasks as the sequential version within
:any:`sec_simple`. Note that the user interface
for initiating the program, creating vectors and matrices, and solving
the linear system is *exactly* the same for the uniprocessor and
multiprocessor examples. The primary difference between the examples in
:any:`sec_simple` and
here is that each processor forms only its
local part of the matrix and vectors in the parallel case.

.. admonition:: Listing: `KSP Tutorial src/ksp/ksp/tutorials/ex2.c <PETSC_DOC_OUT_ROOT_PLACEHOLDER/src/ksp/ksp/tutorials/ex2.c.html>`__
   :name: ksp-ex2

   .. literalinclude:: /../src/ksp/ksp/tutorials/ex2.c
      :end-before: /*TEST

.. _sec_cpu_simd:

CPU SIMD parallelism
~~~~~~~~~~~~~~~~~~~~

SIMD parallelism occurs most commonly in the Intel advanced vector extensions (AVX) `Wikipedia https://en.wikipedia.org/wiki/Advanced_Vector_Extensions`
families of instructions. It may be automatically used by the optimizing compiler, or in low-level libraries that PETSc uses such as BLAS
(see `BLIS https://github.com/flame/blis`, or rarely,
directly in PETSc C/C++ code, as in `MatMult_SeqSELL https://petsc.org/main/src/mat/impls/sell/seq/sell.c.html#MatMult_SeqSELL`.

.. _sec_cpu_openmp:

CPU OpenMP parallelism
~~~~~~~~~~~~~~~~~~~~~~

OpenMP parallelism is thread parallelism. Multiple threads (independent streams of instructions) process data and perform computations on different
parts of memory that is
shared (accessible) to all of the threads. The OpenMP model is most-often based on inserting pragmas into code indicating that a series of instructions
(often within a loop) can be run in parallel. This is also called a fork-join model of parallelism, since much of the code remains sequential and only the
computationally expensive parts in the 'parallel region' are parallel. OpenMP thus makes it relatively easy to add some degree of
parallelism to a conventional sequential code in a shared memory environment.

POSIX threads (pthreads) is a library that may be called from C/C++. The library contains routines to create, join, and remove threads plus manage communications and
synchronizations between threads. Pthreads is rarely used directly in numerical libraries and applications. Sometimes OpenMP is implemented on top of pthreads.

If one adds
OpenMP parallelism to an MPI code one must make sure not to over-subscribe the hardware resources. For example, if MPI already has one rank per hardware core then
using four OpenMP threads per MPI rank will slow the code down since now one core will need to switch back and forth between four OpenMP threads.
There are limited practical advantages to a combined MPI and OpenMP model in PETSc, but it is possible.

For application codes that uses certain external packages including BLAS/LAPACK, SuperLU_DIST, MUMPS, MKL, and SuiteSparse one can build PETSc and these
packages to take advantage of OpenMP by using the configure option ``--with-openmp``.  The number of OpenMP threads used in the application can be controlled with
the PETSc command line option ``-omp_num_threads <num>`` or the environmental variable ``OMP_NUM_THREADS``. Running a PETSc program with ``-omp_view`` will display the
number of threads being used. The default number is often absurdly high for the given hardware so we recommend always setting it appropriately.
Users can also put OpenMP pragmas into their own code. However since standard PETSc is not thread-safe, they should not, in general,
call PETSc routines from inside the parallel regions.

PETSc MPI based linear solvers may be accessed from a sequential or OpenMP program with the ``PCMPI`` solver wrapper, see :any:`sec_pcmpi`.


There is an OpenMP thread-safe subset of PETSc that may be configured for using ``--with-threadsafety --with-log=0 [--with-openmp or
--download-concurrencykit]``. `KSP Tutorial ex61f <PETSC_DOC_OUT_ROOT_PLACEHOLDER/src/ksp/ksp/tutorials/ex61f.F90.html>`__ demonstrates
how this may be used with OpenMP. In this mode one may have individual OpenMP threads that each manage their own
(sequential) PETSc objects (each thread can interact only with its own objects). This
is useful when one has many small systems (or sets of ODEs) that must be integrated in an
"embarrassingly parallel" fashion on multicore systems.

.. seealso::

   Edward A. Lee, `The Problem with Threads <https://digitalassets.lib.berkeley.edu/techreports/ucb/text/EECS-2006-1.pdf>`__,  Technical Report No. UCB/EECS-2006-1 January `[DOI] <https://doi.org/10.1109/MC.2006.180>`__
   10, 2006

.. _sec_gpu_kernels:


GPU kernel parallelism
~~~~~~~~~~~~~~~~~~~~~~


GPUs offer at least two levels of clearly defined parallelism. Kernel level parallelism is much like SIMD parallelism applied to loops;
many different "iterations" of the loop index run on different hardware but in "lock-step"
at the same time. PETSc utilizes this parallelism with three similar, but slightly different models:

- CUDA, which is provided by NVIDIA and runs on NVIDIA GPUs

- HIP, provided by AMD, which can, in theory, run on both AMD and NVIDIA GPUs

- and Kokkos, an open-source package that provides a slightly higher level programming model to utilize GPU kernels.

To utilize this one configures PETSc with either `--with-cuda` or `--with-hip` and, if they plan to use Kokkos, also `--with-kokkos --with-kokkos-kernels`.

In the GPU programming model that PETSc uses the GPU memory is distinct from the CPU memory. This means that data that resides on the CPU
memory must be copied to the GPU (often this copy is done automatically by the libraries and the user does not need to manage it)
if one wishes to use the GPU computational power on it. This memory copy is slow compared to the GPU speed hence it is crucial to minimize these copies. This often
translates to trying to do almost all the computation on the GPU and not constantly switching between computations on the CPU and the GPU on the same data.

PETSc utilizes GPUs by providing vector and matrix classes (Vec and Mat) that are specifically written to run fast on the GPU. However, since it is difficult to
write an entire PETSc code that runs only on the GPU one can also access and work with (for example, put entries into) the vectors and matrices
on the CPU. The vector classes
are `VECCUDA`, `MATAIJCUSPARSE`, `VECKOKKOS`, `MATAIJKOKKOS`, and `VECHIP` (matrices are not yet supported from PETSc with HIP).

More details on using GPUs from PETSc will follow in this document.

.. _sec_gpu_streams:

GPU stream parallelism
~~~~~~~~~~~~~~~~~~~~~~

Incomplete


.. raw:: latex

  \newpage

Compiling and Running Programs
------------------------------

The output below illustrates compiling and running a
PETSc program using MPICH on a macOS laptop. Note that different
machines will have compilation commands as determined by the
configuration process. See :any:`sec_writing_application_codes` for
a discussion about how to compile your PETSc programs. Users who are
experiencing difficulties linking PETSc programs should refer to the FAQ
on the PETSc website https://petsc.org/ or given in the file
``$PETSC_DIR/docs/faq.html``.

.. code-block:: none

   $ cd $PETSC_DIR/src/ksp/ksp/tutorials
   $ make ex2
   /Users/patrick/petsc/arch-darwin-double-debug/bin/mpicc -o ex2.o -c -g3   -I/Users/patrick/petsc/include -I/Users/patrick/petsc/arch-darwin-double-debug/include -I/opt/X11/include -I/opt/local/include    `pwd`/ex2.c
   /Users/patrick/petsc/arch-darwin-double-debug/bin/mpicc -g3  -o ex2 ex2.o  -Wl,-rpath,/Users/patrick/petsc/arch-darwin-double-debug/lib -L/Users/patrick/petsc/arch-darwin-double-debug/lib  -lpetsc -lf2clapack -lf2cblas -lmpifort -lgfortran -lgcc_ext.10.5 -lquadmath -lm -lclang_rt.osx -lmpicxx -lc++ -ldl -lmpi -lpmpi -lSystem
   /bin/rm -f ex2.o
   $ $PETSC_DIR/lib/petsc/bin/petscmpiexec -n 1 ./ex2
   Norm of error 0.000156044 iterations 6
   $ $PETSC_DIR/lib/petsc/bin/petscmpiexec -n 2 ./ex2
   Norm of error 0.000411674 iterations 7

.. _sec_profiling_programs:

Profiling Programs
------------------

The option
``-log_view`` activates printing of a performance summary, including
times, floating point operation (flop) rates, and message-passing
activity. :any:`ch_profiling` provides details about
profiling, including interpretation of the output data below. 
This particular example involves
the solution of a linear system on one processor using GMRES and ILU.
The low floating point operation (flop) rates in this example are due to
the fact that the code solved a tiny system. We include this example
merely to demonstrate the ease of extracting performance information.

.. _listing_exprof:

.. code-block:: none

   $ $PETSC_DIR/lib/petsc/bin/petscmpiexec -n 1 ./ex1 -n 1000 -pc_type ilu -ksp_type gmres -ksp_rtol 1.e-7 -log_view
   ...
   ------------------------------------------------------------------------------------------------------------------------
   Event                Count      Time (sec)     Flops                             --- Global ---  --- Stage ----  Total
                      Max Ratio  Max     Ratio   Max  Ratio  Mess   AvgLen  Reduct  %T %F %M %L %R  %T %F %M %L %R Mflop/s
   ------------------------------------------------------------------------------------------------------------------------

   VecMDot                1 1.0 3.2830e-06 1.0 2.00e+03 1.0 0.0e+00 0.0e+00 0.0e+00  0  5  0  0  0   0  5  0  0  0   609
   VecNorm                3 1.0 4.4550e-06 1.0 6.00e+03 1.0 0.0e+00 0.0e+00 0.0e+00  0 14  0  0  0   0 14  0  0  0  1346
   VecScale               2 1.0 4.0110e-06 1.0 2.00e+03 1.0 0.0e+00 0.0e+00 0.0e+00  0  5  0  0  0   0  5  0  0  0   499
   VecCopy                1 1.0 3.2280e-06 1.0 0.00e+00 0.0 0.0e+00 0.0e+00 0.0e+00  0  0  0  0  0   0  0  0  0  0     0
   VecSet                11 1.0 2.5537e-05 1.0 0.00e+00 0.0 0.0e+00 0.0e+00 0.0e+00  2  0  0  0  0   2  0  0  0  0     0
   VecAXPY                2 1.0 2.0930e-06 1.0 4.00e+03 1.0 0.0e+00 0.0e+00 0.0e+00  0 10  0  0  0   0 10  0  0  0  1911
   VecMAXPY               2 1.0 1.1280e-06 1.0 4.00e+03 1.0 0.0e+00 0.0e+00 0.0e+00  0 10  0  0  0   0 10  0  0  0  3546
   VecNormalize           2 1.0 9.3970e-06 1.0 6.00e+03 1.0 0.0e+00 0.0e+00 0.0e+00  1 14  0  0  0   1 14  0  0  0   638
   MatMult                2 1.0 1.1177e-05 1.0 9.99e+03 1.0 0.0e+00 0.0e+00 0.0e+00  1 24  0  0  0   1 24  0  0  0   894
   MatSolve               2 1.0 1.9933e-05 1.0 9.99e+03 1.0 0.0e+00 0.0e+00 0.0e+00  1 24  0  0  0   1 24  0  0  0   501
   MatLUFactorNum         1 1.0 3.5081e-05 1.0 4.00e+03 1.0 0.0e+00 0.0e+00 0.0e+00  2 10  0  0  0   2 10  0  0  0   114
   MatILUFactorSym        1 1.0 4.4259e-05 1.0 0.00e+00 0.0 0.0e+00 0.0e+00 0.0e+00  3  0  0  0  0   3  0  0  0  0     0
   MatAssemblyBegin       1 1.0 8.2015e-08 1.0 0.00e+00 0.0 0.0e+00 0.0e+00 0.0e+00  0  0  0  0  0   0  0  0  0  0     0
   MatAssemblyEnd         1 1.0 3.3536e-05 1.0 0.00e+00 0.0 0.0e+00 0.0e+00 0.0e+00  2  0  0  0  0   2  0  0  0  0     0
   MatGetRowIJ            1 1.0 1.5960e-06 1.0 0.00e+00 0.0 0.0e+00 0.0e+00 0.0e+00  0  0  0  0  0   0  0  0  0  0     0
   MatGetOrdering         1 1.0 3.9791e-05 1.0 0.00e+00 0.0 0.0e+00 0.0e+00 0.0e+00  3  0  0  0  0   3  0  0  0  0     0
   MatView                2 1.0 6.7909e-05 1.0 0.00e+00 0.0 0.0e+00 0.0e+00 0.0e+00  5  0  0  0  0   5  0  0  0  0     0
   KSPGMRESOrthog         1 1.0 7.5970e-06 1.0 4.00e+03 1.0 0.0e+00 0.0e+00 0.0e+00  1 10  0  0  0   1 10  0  0  0   526
   KSPSetUp               1 1.0 3.4424e-05 1.0 0.00e+00 0.0 0.0e+00 0.0e+00 0.0e+00  2  0  0  0  0   2  0  0  0  0     0
   KSPSolve               1 1.0 2.7264e-04 1.0 3.30e+04 1.0 0.0e+00 0.0e+00 0.0e+00 19 79  0  0  0  19 79  0  0  0   121
   PCSetUp                1 1.0 1.5234e-04 1.0 4.00e+03 1.0 0.0e+00 0.0e+00 0.0e+00 11 10  0  0  0  11 10  0  0  0    26
   PCApply                2 1.0 2.1022e-05 1.0 9.99e+03 1.0 0.0e+00 0.0e+00 0.0e+00  1 24  0  0  0   1 24  0  0  0   475
   ------------------------------------------------------------------------------------------------------------------------

   Memory usage is given in bytes:

   Object Type          Creations   Destructions     Memory  Descendants' Mem.
   Reports information only for process 0.

   --- Event Stage 0: Main Stage

                 Vector     8              8        76224     0.
                 Matrix     2              2       134212     0.
          Krylov Solver     1              1        18400     0.
         Preconditioner     1              1         1032     0.
              Index Set     3              3        10328     0.
                 Viewer     1              0            0     0.
   ========================================================================================================================
   ...

.. _sec_writing_application_codes:

Writing C/C++ or Fortran Applications
-------------------------------------

The examples throughout the library demonstrate the software usage and
can serve as templates for developing custom applications. We suggest
that new PETSc users examine programs in the directories
``$PETSC_DIR/src/<library>/tutorials`` where ``<library>`` denotes any
of the PETSc libraries (listed in the following section), such as
``SNES`` or ``KSP`` or ``TS``. The manual pages located at
https://petsc.org/release/documentation/ provide links (organized by
both routine names and concepts) to the tutorial examples.

To develop an application program that uses PETSc, we suggest the following:

* :ref:`Download <doc_download>` and :ref:`install <doc_install>` PETSc.

* For completely new applications

   #. Make a directory for your source code: for example, ``mkdir $HOME/application``

   #. Change to that directory; for
      example, ``cd $HOME/application``

   #. Copy an example in the directory that corresponds to the
      problems of interest into your directory, for
      example, ``cp $PETSC_DIR/src/snes/tutorials/ex19.c ex19.c``

   #. Select an application build process. The ``PETSC_DIR`` (and ``PETSC_ARCH`` if the ``--prefix=directoryname``
      option was not used when configuring PETSc) environmental variable(s) must be
      set for any of these approaches.

      * make (recommended). Copy $PETSC_DIR/share/petsc/Makefile.user or $PETSC_DIR/share/petsc/Makefile.basic.user
        to your directory, for example, ``cp $PETSC_DIR/share/petsc/Makefile.user makefile``

        Examine the comments in your makefile

        Makefile.user uses the `pkg-config <https://en.wikipedia.org/wiki/Pkg-config>`__ tool and is the recommended approach.

        Use ``make ex19`` to compile your program

      * CMake. Copy $PETSC_DIR/share/petsc/CMakeLists.txt to your directory, for example, ``cp $PETSC_DIR/share/petsc/CMakeLists.txt CMakeLists.txt``

        Edit CMakeLists.txt, read the comments on usage and change the name of application from ex1 to your application executable name.

   #. Run the  program, for example,
      ``./ex19``

   #. Start to modify the program for developing your application.

* For adding PETSc to an existing application

   #. Start with a working version of your code that you build and run to confirm that it works.

   #. Upgrade your build process. The ``PETSC_DIR`` (and ``PETSC_ARCH`` if the ``--prefix=directoryname``
      option was not used when configuring PETSc) environmental variable(s) must be
      set for any of these approaches.

      * Using make. Update the application makefile to add the appropriate PETSc include
        directories and libraries.

        *  Recommended approach. Examine the comments in $PETSC_DIR/share/petsc/Makefile.user and transfer selected portions of
           that file to your makefile.

        *  Minimalist. Add the line

           .. code-block:: console

              include ${PETSC_DIR}/lib/petsc/conf/variables

           to the bottom of your makefile. This will provide a set of PETSc specific make variables you may use in your makefile. See
           the comments in the file $PETSC_DIR/share/petsc/Makefile.basic.user for details on the usage.

        *  Simple, but hands the build process over to PETSc's control. Add the lines

           .. code-block:: console

              include ${PETSC_DIR}/lib/petsc/conf/variables
              include ${PETSC_DIR}/lib/petsc/conf/rules
              include ${PETSC_DIR}/lib/petsc/conf/tests

           to the bottom of your makefile. See the comments in the file $PETSC_DIR/share/petsc/Makefile.basic.user for details on the usage.
           Since PETSc's rules now control the build process you will likely need to simplify and remove much of your makefile.

        *  Not recommended since you must change your makefile for each new configuration/computing system. This approach does not require
           that the environmental variable ``PETSC_DIR`` be set when building your application since the information will be hardwired in your
           makefile. Run the following command in the PETSc root directory to get the information needed by your makefile:

           .. code-block:: console

             $ make getlinklibs getincludedirs getcflags getcxxflags getfortranflags getccompiler getfortrancompiler getcxxcompiler

           All the libraries listed need to be linked into your executable and the
           include directories and flags need to be passed to the compiler(s). Usually
           this is done by setting ``LDFLAGS=<list of library flags and libraries>`` and
           ``CFLAGS=<list of -I and other flags>`` and ``FFLAGS=<list of -I and other flags>`` etc in your makefile.

      * Using CMake. Update the application CMakeLists.txt by examining the code and comments in
        $PETSC_DIR/share/petsc/CMakeLists.txt

   #. Rebuild your application and ensure it still runs correctly.

   #. Add a ``PetscInitialize()`` near the beginning of your code and ``PetscFinalize()`` near the end with appropriate include commands
      (and use commands in Fortran)

   #. Rebuild your application and ensure it still runs correctly.

   #. Slowly start utilizing PETSc functionality in your code, ensure that your code continues to build and run correctly.

.. _sec_oo:

PETSc's Object-Oriented Design
------------------------------

Though PETSc has a large API, conceptually it's rather simple.
There are three abstract basic data objects (classes): index sets, ``IS``, vectors, ``Vec``, and matrices, ``Mat``.
Plus a larger number of abstract algorithm objects (classes) starting with: preconditioners, ``PC``, Krylov solvers, ``KSP``, and so forth.

Let ``Object``
represent any of these objects. Objects are created with

.. code-block::

   Object obj;
   ObjectCreate(MPI_Comm, &obj);

The object is empty and little can be done with it. A particular implementation of the class is associated with the object by setting the object's "type", where type
is merely a string name of an implementation class using

.. code-block::

   Object obj;
   ObjectSetType(obj,"Name");

Some objects support subclasses which are specializations of the type. These are set with

.. code-block::

   Object obj;
   ObjectNameSetType(obj,"SubName");

For example, within ``TS`` one may do

.. code-block::

   TS obj;
   TSCreate(PETSC_COMM_WORLD,&obj);
   TSSetType(obj,TSARKIMEX);
   TSARKIMEXSetType(obj,TSARKIMEX3);

The abstract class ``TS`` can embody any ODE/DAE integrator scheme.
This example creates an additive Runge-Kutta ODE/DAE IMEX integrator, whose type name is ``TSARKIMEX``, using a 3-order scheme with an L-stable implicit part,
whose subtype name is ``TSARKIMEX3``.

In order to allow PETSc objects to be runtime configurable, PETSc objects provide a universal way of selecting types (classes) and subtypes at runtime, from
what is referred to as the "options database". The code above can be replaced with

.. code-block::

   TS obj;
   TSCreate(PETSC_COMM_WORLD,&obj);
   TSSetFromOptions(obj);

now both the type and subtype can be conveniently set from the command line

.. code-block:: console

   $ ./app -ts_type arkimex -ts_arkimex_type 3

The object's type (implementation class) or subclass can also be changed at any time simply by calling ``TSSetType()`` again (though in order to override command line options the call to ``TSSetType()`` must be made _after_ ``TSSetFromOptions()``). For example:

.. code-block::

   // (if set) command line options "override" TSSetType()
   TSSetType(ts, TSGLLE);
   TSSetFromOptions(ts);

   // TSSetType() overrides command line options
   TSSetFromOptions(ts);
   TSSetType(ts, TSGLLE);

Since the later call always overrides the earlier call the second form shown is rarely -- if ever -- used, as it is less flexible than configuring command line settings.

The standard methods on an object are of the general form

.. code-block::

   ObjectSetXXX(obj,...);
   ObjectGetXXX(obj,...);
   ObjectYYY(obj,...);

For example

.. code-block::

   TSSetRHSFunction(obj,...)

Particular types and subtypes of objects may have their own methods, which are given in the form

.. code-block::

   ObjectNameSetXXX(obj,...);
   ObjectNameGetXXX(obj,...);
   ObjectNameYYY(obj,...);

and

.. code-block::

   ObjectNameSubNameSetXXX(obj,...);
   ObjectNameSubNameGetXXX(obj,...);
   ObjectNameSubNameYYY(obj,...);

where Name and SubName are the type and subtype names (for example, as above ``TSARKIMEX`` and ``3``. Most "set" operations have options database versions with the same
names in lower case, separated by underscores and with the set remove. For example,

.. code-block::

   KSPGMRESSetRestart(obj,30);   // ignored if the type is not KSPGMRES

can be set at the command line with

.. code-block:: console

   $ ./app -ksp_gmres_restart 30


There are a special subset of type-specific methods that
are ignored if the type does not match the function name. These are usually setter functions that control some aspect specific to the subtype. For example,

.. code-block::

   KSPGMRESSetRestart(obj,30);   // ignored if the type is not KSPGMRES

These allow cleaner code since it does not have a multitude of if statements to avoid inactive methods. That is one does not need to write code like

.. code-block::

   if (type == KSPGMRES) {     // unneeded clutter
     KSPGMRESSetRestart(obj,30);
   }

There are many "get" routines that give one temporary access to the internal data of an object. They are used in the style

.. code-block::

   XXX xxx;
   ObjectGetXXX(obj,&xxx);
   // use xxx
   ObjectRestoreXXX(obj,&xxx);

Objects obtained with a "get" routine should be returned with a "restore" routine, generally within the same function. Objects obtained with a "create" routine should be freed
with a "destroy" routine.

There may be variants of the "get" routines that give more limited access to the obtained object. For example,

.. code-block::

   const PetscScalar *x;

   // specialized variant of VecGetArray()
   VecGetArrayRead(vec, &x);
   // one can read but not write with x[]
   PetscReal y = 2*x[0];
   // don't forget to restore x after you are done with it
   VecRestoreArrayRead(vec, &x);

Objects can be displayed (in a large number of ways) with

.. code-block::

   ObjectView(obj,PetscViewer viewer);
   ObjectViewFromOptions(obj,...);

Where ``PetscViewer`` is an abstract object that can represent standard output, an ASCII or binary file, a graphical window, etc. The second
variant allows the user to delay until runtime the decision of what viewer and format to use to view the object or if to view the object at all.

Objects are destroyed with

.. code-block::

   ObjectDestroy(&obj)

.. figure:: /images/docs/manual/objectlife.svg
  :name: fig_objectlife

  Sample lifetime of a PETSc object


User Callbacks
~~~~~~~~~~~~~~

In many situations the user may also wish to override or provide custom functionality. This is handled via callbacks which the library will call at the appropriate time. The most general callback is provided by

.. code-block::

   PetscObjecSetCallback(obj,callbackfunction(), void *ctx, callbackdestroy(void *ctx));

where ``callbackfunction()`` is what is used by the library, ``ctx`` is an optional data-structure (array, struct, PETSc object) that is used by ``callbackfunction()``
and ``callbackdestroy(void *ctx)`` is an optional function that will be called when ``obj`` is destroyed. The use of the ``callbackdestroy()`` allows users to "set and forget"
data structures that will not be needed elsewhere but still need to be cleaned up when no longer needed. Here is an example of the use of a full-fledged callback

.. code-block::

   TS              ts;
   TSMonitorLGCtx *ctx;

   TSMonitorLGCtxCreate(..., &ctx)
   TSMonitorSet(ts, TSMonitorLGTimeStep, ctx, (PetscErrorCode(*)(void **))TSMonitorLGCtxDestroy);
   TSSolve(ts);

Occasionally routines to set callback functions take additional data objects that will be used by the object but are not context data for the function. For example,

.. code-block::

   SNES obj;
   Vec  r;
   void *ctx;

   SNESSetFunction(snes, r, UserApplyFunction(SNES,Vec,Vec,void *ctx), ctx);

The ``r`` vector is an optional argument provided by the user which will be used as work-space by ``SNES``. Note that this callback does not provide a way for the user
to have the ``ctx`` destroyed when the ``SNES`` object is destroyed, the users must ensure that they free it at an appropriate time. There is no logic to the various ways
PETSc accepts callback functions in different places in the code.

See :any:`fig_taocallbacks` for a cartoon on the use of callbacks in ``Tao``.

.. _sec_directory:

Directory Structure
-------------------

We conclude this introduction with an overview of the organization of
the PETSc software. The root directory of PETSc contains the following
directories:

-  ``docs`` (only in the tarball distribution of PETSc; not the git
   repository) - All documentation for PETSc. The files ``manual.pdf``
   contains the hyperlinked users manual, suitable for printing or
   on-screen viewering. Includes the subdirectory - ``manualpages``
   (on-line manual pages).

-  ``lib/petsc/conf`` - Base PETSc configuration files that define the standard
   make variables and rules used by PETSc

-  ``include`` - All include files for PETSc that are visible to the
   user.

-  ``include/petsc/finclude`` - PETSc Fortran include files.

-  ``include/petsc/private`` - Private PETSc include files that should
   *not* need to be used by application programmers.

-  ``share`` - Some small test matrices in data files

-  ``src`` - The source code for all PETSc libraries, which currently
   includes

   -  ``vec`` - vectors,

      -  ``is`` - index sets,

   -  ``mat`` - matrices,

   -  ``ksp`` - complete linear equations solvers,

      -  ``ksp`` - Krylov subspace accelerators,

      -  ``pc`` - preconditioners,

   -  ``snes`` - nonlinear solvers

   -  ``ts`` - ODE solvers and timestepping,

   -  ``dm`` - data management between meshes and solvers, vectors, and
      matrices,

   -  ``sys`` - general system-related routines,

      -  ``logging`` - PETSc logging and profiling routines,

      -  ``classes`` - low-level classes

         -  ``draw`` - simple graphics,

         -  ``viewer`` - mechanism for printing and visualizing PETSc
            objects,

         -  ``bag`` - mechanism for saving and loading from disk user
            data stored in C structs.

         -  ``random`` - random number generators.

Each PETSc source code library directory has the following
subdirectories:

-  ``tutorials`` - Programs designed to teach users about PETSc.
    These codes can serve as templates for the design of custom
    applications.

-  ``tests`` - Programs designed for thorough testing of PETSc. As
    such, these codes are not intended for examination by users.

-  ``interface`` - Provides the abstract base classes for the objects.
   Code here does not know about particular implementations and does not actually perform
   operations on the underlying numerical data.

-  ``impls`` - Source code for one or more implementations of the class for particular
   data structures or algorithms.

-  ``utils`` - Utility routines. Source here may know about the
   implementations, but ideally will not know about implementations for
   other components.

.. raw:: html

    <hr>

.. bibliography:: /petsc.bib
   :filter: docname in docnames
