From d1e954d246fee0cb9dd67bf9fe224debd9aa84dd Mon Sep 17 00:00:00 2001 From: Sameer Agarwal Date: Mon, 21 Nov 2016 22:37:46 -0800 Subject: [PATCH] Minor changes to the documentation. 1. Section title changes. 2. Moving the glog discussion into installation.rst 3. Re-working the faqs into two separate chapters. Change-Id: I95dd25bace50f0f9077ef114504999190686963e --- docs/source/api.rst | 12 - docs/source/conf.py | 3 +- docs/source/faqs.rst | 324 +--------- docs/source/features.rst | 6 +- docs/source/guide.rst | 12 + docs/source/index.rst | 54 +- .../source/{building.rst => installation.rst} | 605 ++++++++++-------- docs/source/license.rst | 2 +- docs/source/modeling_faqs.rst | 134 ++++ docs/source/nnls_modeling.rst | 156 ++--- docs/source/solving_faqs.rst | 171 +++++ scripts/make_docs.py | 6 +- 12 files changed, 760 insertions(+), 725 deletions(-) delete mode 100644 docs/source/api.rst create mode 100644 docs/source/guide.rst rename docs/source/{building.rst => installation.rst} (61%) create mode 100644 docs/source/modeling_faqs.rst create mode 100644 docs/source/solving_faqs.rst diff --git a/docs/source/api.rst b/docs/source/api.rst deleted file mode 100644 index 051f6e734..000000000 --- a/docs/source/api.rst +++ /dev/null @@ -1,12 +0,0 @@ -.. _chapter-api: - -============= -API Reference -============= - -.. toctree:: - :maxdepth: 3 - - nnls_modeling - nnls_solving - gradient_solver diff --git a/docs/source/conf.py b/docs/source/conf.py index 86e00f1e3..59a418e9e 100644 --- a/docs/source/conf.py +++ b/docs/source/conf.py @@ -41,7 +41,7 @@ master_doc = 'index' # General information about the project. project = u'Ceres Solver' -copyright = u'2015 Google Inc' +copyright = u'2016 Google Inc' # The version info for the project you're documenting, acts as replacement for # |version| and |release|, also used in various other places throughout the @@ -86,7 +86,6 @@ pygments_style = 'sphinx' # A list of ignored prefixes for module index sorting. #modindex_common_prefix = [] - # -- Options for HTML output --------------------------------------------------- # The theme to use for HTML and HTML Help pages. See the documentation for diff --git a/docs/source/faqs.rst b/docs/source/faqs.rst index 7513f44dc..5a28f4187 100644 --- a/docs/source/faqs.rst +++ b/docs/source/faqs.rst @@ -1,5 +1,9 @@ .. _chapter-tricks: +.. default-domain:: cpp + +.. cpp:namespace:: ceres + =================== FAQS, Tips & Tricks =================== @@ -7,324 +11,12 @@ FAQS, Tips & Tricks Answers to frequently asked questions, tricks of the trade and general wisdom. -Building -======== +.. toctree:: + :maxdepth: 2 -#. Use `google-glog `_. + modeling_faqs + solving_faqs - Ceres has extensive support for logging detailed information about - memory allocations and time consumed in various parts of the solve, - internal error conditions etc. This is done logging using the - `google-glog `_ library. We - use it extensively to observe and analyze Ceres's - performance. `google-glog `_ - allows you to control its behaviour from the command line `flags - `_. Starting - with ``-logtostderr`` you can add ``-v=N`` for increasing values - of ``N`` to get more and more verbose and detailed information - about Ceres internals. - - In an attempt to reduce dependencies, it is tempting to use - `miniglog` - a minimal implementation of the ``glog`` interface - that ships with Ceres. This is a bad idea. ``miniglog`` was written - primarily for building and using Ceres on Android because the - current version of `google-glog - `_ does not build using the - NDK. It has worse performance than the full fledged glog library - and is much harder to control and use. - - -Modeling -======== - -#. Use analytical/automatic derivatives. - - This is the single most important piece of advice we can give to - you. It is tempting to take the easy way out and use numeric - differentiation. This is a bad idea. Numeric differentiation is - slow, ill-behaved, hard to get right, and results in poor - convergence behaviour. - - Ceres allows the user to define templated functors which will - be automatically differentiated. For most situations this is enough - and we recommend using this facility. In some cases the derivatives - are simple enough or the performance considerations are such that - the overhead of automatic differentiation is too much. In such - cases, analytic derivatives are recommended. - - The use of numerical derivatives should be a measure of last - resort, where it is simply not possible to write a templated - implementation of the cost function. - - In many cases it is not possible to do analytic or automatic - differentiation of the entire cost function, but it is generally - the case that it is possible to decompose the cost function into - parts that need to be numerically differentiated and parts that can - be automatically or analytically differentiated. - - To this end, Ceres has extensive support for mixing analytic, - automatic and numeric differentiation. See - :class:`CostFunctionToFunctor`. - -#. When using Quaternions, consider using :class:`QuaternionParameterization`. - - `Quaternions `_ are a - four dimensional parameterization of the space of three dimensional - rotations :math:`SO(3)`. However, the :math:`SO(3)` is a three - dimensional set, and so is the tangent space of a - Quaternion. Therefore, it is sometimes (not always) benefecial to - associate a local parameterization with parameter blocks - representing a Quaternion. Assuming that the order of entries in - your parameter block is :math:`w,x,y,z`, you can use - :class:`QuaternionParameterization`. - - If however, you are using `Eigen's Quaternion - `_ - object, whose layout is :math:`x,y,z,w`, then we recommend you use - Lloyd Hughes's `Ceres Extensions - `_. - -#. How do I solve problems with general linear & non-linear - **inequality** constraints with Ceres Solver? - - Currently, Ceres Solver only supports upper and lower bounds - constraints on the parameter blocks. - - A crude way of dealing with inequality constraints is have one or - more of your cost functions check if the inequalities you are - interested in are satisfied, and if not return false instead of - true. This will prevent the solver from ever stepping into an - infeasible region. - - This requires that the starting point for the optimization be a - feasible point. You also risk pre-mature convergence using this - method. - -#. How do I solve problems with general linear & non-linear **equality** - constraints with Ceres Solver? - - There is no built in support in ceres for solving problems with - equality constraints. Currently, Ceres Solver only supports upper - and lower bounds constraints on the parameter blocks. - - The trick described above for dealing with inequality - constraints will **not** work for equality constraints. - -#. How do I set one or more components of a parameter block constant? - - Using :class:`SubsetParameterization`. - -#. Putting `Inverse Function Theorem - `_ to use. - - Every now and then we have to deal with functions which cannot be - evaluated analytically. Computing the Jacobian in such cases is - tricky. A particularly interesting case is where the inverse of the - function is easy to compute analytically. An example of such a - function is the Coordinate transformation between the `ECEF - `_ and the `WGS84 - `_ where the - conversion from WGS84 to ECEF is analytic, but the conversion - back to WGS84 uses an iterative algorithm. So how do you compute the - derivative of the ECEF to WGS84 transformation? - - One obvious approach would be to numerically - differentiate the conversion function. This is not a good idea. For - one, it will be slow, but it will also be numerically quite - bad. - - Turns out you can use the `Inverse Function Theorem - `_ in this - case to compute the derivatives more or less analytically. - - The key result here is. If :math:`x = f^{-1}(y)`, and :math:`Df(x)` - is the invertible Jacobian of :math:`f` at :math:`x`. Then the - Jacobian :math:`Df^{-1}(y) = [Df(x)]^{-1}`, i.e., the Jacobian of - the :math:`f^{-1}` is the inverse of the Jacobian of :math:`f`. - - Algorithmically this means that given :math:`y`, compute :math:`x = - f^{-1}(y)` by whatever means you can. Evaluate the Jacobian of - :math:`f` at :math:`x`. If the Jacobian matrix is invertible, then - its inverse is the Jacobian of :math:`f^{-1}(y)` at :math:`y`. - - One can put this into practice with the following code fragment. - - .. code-block:: c++ - - Eigen::Vector3d ecef; // Fill some values - // Iterative computation. - Eigen::Vector3d lla = ECEFToLLA(ecef); - // Analytic derivatives - Eigen::Matrix3d lla_to_ecef_jacobian = LLAToECEFJacobian(lla); - bool invertible; - Eigen::Matrix3d ecef_to_lla_jacobian; - lla_to_ecef_jacobian.computeInverseWithCheck(ecef_to_lla_jacobian, invertible); - - -Solving -======= - -#. How do I evaluate the Jacobian for a solver problem? - - Using :func:`Problem::Evaluate`. - -#. Choosing a linear solver. - - When using the ``TRUST_REGION`` minimizer, the choice of linear - solver is an important decision. It affects solution quality and - runtime. Here is a simple way to reason about it. - - 1. For small (a few hundred parameters) or dense problems use - ``DENSE_QR``. - - 2. For general sparse problems (i.e., the Jacobian matrix has a - substantial number of zeros) use - ``SPARSE_NORMAL_CHOLESKY``. This requires that you have - ``SuiteSparse`` or ``CXSparse`` installed. - - 3. For bundle adjustment problems with up to a hundred or so - cameras, use ``DENSE_SCHUR``. - - 4. For larger bundle adjustment problems with sparse Schur - Complement/Reduced camera matrices use ``SPARSE_SCHUR``. This - requires that you build Ceres with support for ``SuiteSparse``, - ``CXSparse`` or Eigen's sparse linear algebra libraries. - - If you do not have access to these libraries for whatever - reason, ``ITERATIVE_SCHUR`` with ``SCHUR_JACOBI`` is an - excellent alternative. - - 5. For large bundle adjustment problems (a few thousand cameras or - more) use the ``ITERATIVE_SCHUR`` solver. There are a number of - preconditioner choices here. ``SCHUR_JACOBI`` offers an - excellent balance of speed and accuracy. This is also the - recommended option if you are solving medium sized problems for - which ``DENSE_SCHUR`` is too slow but ``SuiteSparse`` is not - available. - - .. NOTE:: - - If you are solving small to medium sized problems, consider - setting ``Solver::Options::use_explicit_schur_complement`` to - ``true``, it can result in a substantial performance boost. - - If you are not satisfied with ``SCHUR_JACOBI``'s performance try - ``CLUSTER_JACOBI`` and ``CLUSTER_TRIDIAGONAL`` in that - order. They require that you have ``SuiteSparse`` - installed. Both of these preconditioners use a clustering - algorithm. Use ``SINGLE_LINKAGE`` before ``CANONICAL_VIEWS``. - -#. Use :func:`Solver::Summary::FullReport` to diagnose performance problems. - - When diagnosing Ceres performance issues - runtime and convergence, - the first place to start is by looking at the output of - ``Solver::Summary::FullReport``. Here is an example - - .. code-block:: bash - - ./bin/bundle_adjuster --input ../data/problem-16-22106-pre.txt - - iter cost cost_change |gradient| |step| tr_ratio tr_radius ls_iter iter_time total_time - 0 4.185660e+06 0.00e+00 2.16e+07 0.00e+00 0.00e+00 1.00e+04 0 7.50e-02 3.58e-01 - 1 1.980525e+05 3.99e+06 5.34e+06 2.40e+03 9.60e-01 3.00e+04 1 1.84e-01 5.42e-01 - 2 5.086543e+04 1.47e+05 2.11e+06 1.01e+03 8.22e-01 4.09e+04 1 1.53e-01 6.95e-01 - 3 1.859667e+04 3.23e+04 2.87e+05 2.64e+02 9.85e-01 1.23e+05 1 1.71e-01 8.66e-01 - 4 1.803857e+04 5.58e+02 2.69e+04 8.66e+01 9.93e-01 3.69e+05 1 1.61e-01 1.03e+00 - 5 1.803391e+04 4.66e+00 3.11e+02 1.02e+01 1.00e+00 1.11e+06 1 1.49e-01 1.18e+00 - - Ceres Solver v1.12.0 Solve Report - ---------------------------------- - Original Reduced - Parameter blocks 22122 22122 - Parameters 66462 66462 - Residual blocks 83718 83718 - Residual 167436 167436 - - Minimizer TRUST_REGION - - Sparse linear algebra library SUITE_SPARSE - Trust region strategy LEVENBERG_MARQUARDT - - Given Used - Linear solver SPARSE_SCHUR SPARSE_SCHUR - Threads 1 1 - Linear solver threads 1 1 - Linear solver ordering AUTOMATIC 22106, 16 - - Cost: - Initial 4.185660e+06 - Final 1.803391e+04 - Change 4.167626e+06 - - Minimizer iterations 5 - Successful steps 5 - Unsuccessful steps 0 - - Time (in seconds): - Preprocessor 0.283 - - Residual evaluation 0.061 - Jacobian evaluation 0.361 - Linear solver 0.382 - Minimizer 0.895 - - Postprocessor 0.002 - Total 1.220 - - Termination: NO_CONVERGENCE (Maximum number of iterations reached.) - - Let us focus on run-time performance. The relevant lines to look at - are - - - .. code-block:: bash - - Time (in seconds): - Preprocessor 0.283 - - Residual evaluation 0.061 - Jacobian evaluation 0.361 - Linear solver 0.382 - Minimizer 0.895 - - Postprocessor 0.002 - Total 1.220 - - - Which tell us that of the total 1.2 seconds, about .3 seconds was - spent in the linear solver and the rest was mostly spent in - preprocessing and jacobian evaluation. - - The preprocessing seems particularly expensive. Looking back at the - report, we observe - - .. code-block:: bash - - Linear solver ordering AUTOMATIC 22106, 16 - - Which indicates that we are using automatic ordering for the - ``SPARSE_SCHUR`` solver. This can be expensive at times. A straight - forward way to deal with this is to give the ordering manually. For - ``bundle_adjuster`` this can be done by passing the flag - ``-ordering=user``. Doing so and looking at the timing block of the - full report gives us - - .. code-block:: bash - - Time (in seconds): - Preprocessor 0.051 - - Residual evaluation 0.053 - Jacobian evaluation 0.344 - Linear solver 0.372 - Minimizer 0.854 - - Postprocessor 0.002 - Total 0.935 - - - - The preprocessor time has gone down by more than 5.5x!. Further Reading =============== diff --git a/docs/source/features.rst b/docs/source/features.rst index 681876e8e..1f5e91ebd 100644 --- a/docs/source/features.rst +++ b/docs/source/features.rst @@ -1,6 +1,6 @@ -======== -Features -======== +==== +Why? +==== .. _chapter-features: * **Code Quality** - Ceres Solver has been used in production at diff --git a/docs/source/guide.rst b/docs/source/guide.rst new file mode 100644 index 000000000..bcf6bc8a5 --- /dev/null +++ b/docs/source/guide.rst @@ -0,0 +1,12 @@ +.. _chapter-users-guide: + +============ +User's Guide +============ + +.. toctree:: + :maxdepth: 2 + + nnls_modeling + nnls_solving + gradient_solver diff --git a/docs/source/index.rst b/docs/source/index.rst index f7f02efe3..3851dd135 100644 --- a/docs/source/index.rst +++ b/docs/source/index.rst @@ -1,20 +1,30 @@ -.. Ceres Solver documentation master file, created by - sphinx-quickstart on Sat Jan 19 00:07:33 2013. - You can adapt this file completely to your liking, but it should at least - contain the root `toctree` directive. - ============ Ceres Solver ============ +Ceres Solver [#f1]_ is an open source C++ library for modeling and +solving large, complicated optimization problems. It can be used to +solve `Non-linear Least Squares`_ problems with bounds constraints and +general unconstrained optimization problems. It is a mature, feature +rich, and performant library that has been used in production at +Google since 2010. For more, see :doc:`features`. + +`ceres-solver@googlegroups.com +`_ is +the place for discussions and questions about Ceres Solver. We use the +`GitHub Issue Tracker +`_ to manage bug +reports and feature requests. + + .. toctree:: - :maxdepth: 3 + :maxdepth: 1 :hidden: - features - building + installation tutorial - api + guide + features faqs users contributing @@ -22,34 +32,8 @@ Ceres Solver bibliography license -Ceres Solver [#f1]_ is an open source C++ library for modeling and -solving large, complicated optimization problems. It is a feature -rich, mature and performant library which has been used in production -at Google since 2010. Ceres Solver can solve two kinds of problems. - -1. `Non-linear Least Squares`_ problems with bounds constraints. -2. General unconstrained optimization problems. - .. _Non-linear Least Squares: http://en.wikipedia.org/wiki/Non-linear_least_squares -Getting started -=============== - -* Download the `latest stable release - `_ or clone the - Git repository for the latest development version. - - .. code-block:: bash - - git clone https://ceres-solver.googlesource.com/ceres-solver - -* Read the :ref:`chapter-tutorial` and browse the :ref:`chapter-api`. -* Join the `mailing list - `_ - and ask questions. -* File bugs, feature requests on `GitHub - `_. - Cite Us ======= diff --git a/docs/source/building.rst b/docs/source/installation.rst similarity index 61% rename from docs/source/building.rst rename to docs/source/installation.rst index 37a3942cc..ddda50f49 100644 --- a/docs/source/building.rst +++ b/docs/source/installation.rst @@ -1,8 +1,8 @@ -.. _chapter-building: +.. _chapter-installation: -======================= -Building & Installation -======================= +============ +Installation +============ Getting the source code ======================= @@ -37,30 +37,41 @@ optional. For details on customizing the build process, see - `CMake `_ 2.8.0 or later. **Required on all platforms except for Android.** -- `Google Log `_ 0.3.1 or +- `glog `_ 0.3.1 or later. **Recommended** - .. NOTE:: + ``glog`` is used extensively throughout Ceres for logging detailed + information about memory allocations and time consumed in various + parts of the solve, internal error conditions etc. The Ceres + developers use it extensively to observe and analyze Ceres's + performance. `glog `_ allows you to + control its behaviour from the command line. Starting with + ``-logtostderr`` you can add ``-v=N`` for increasing values of ``N`` + to get more and more verbose and detailed information about Ceres + internals. - Ceres has a minimal replacement of ``glog`` called ``miniglog`` - that can be enabled with the ``MINIGLOG`` build - option. ``miniglog`` is needed on Android as ``glog`` currently - does not build using the NDK. It can however be used on other - platforms too. + Unfortunately, the current version of `google-glog + `_ does not build using the Android + NDK. So, Ceres also ships with a minimal replacement of ``glog`` + called ``miniglog`` that can be enabled with the ``MINIGLOG`` build + option. - **We do not advise using** ``miniglog`` **on platforms other than - Android due to the various performance and functionality - compromises in** ``miniglog``. + So, in an attempt to reduce dependencies, it is tempting to use + `miniglog` on platforms other than Android. While there is nothing + preventing the user from doing so, we strongly recommend against + it. ``miniglog`` has worse performance than ``glog`` and is much + harder to control and use. .. NOTE :: - If you are compiling ``glog`` from source, please note that currently, - the unit tests for ``glog`` (which are enabled by default) do not compile - against a default build of ``gflags`` 2.1 as the gflags namespace changed - from ``google::`` to ``gflags::``. A patch to fix this is available from - `here `_. + If you are compiling ``glog`` from source, please note that + currently, the unit tests for ``glog`` (which are enabled by + default) do not compile against a default build of ``gflags`` 2.1 + as the gflags namespace changed from ``google::`` to + ``gflags::``. A patch to fix this is available from `here + `_. -- `Google Flags `_. Needed to build +- `gflags `_. Needed to build examples and tests. - `SuiteSparse @@ -110,8 +121,9 @@ distribution. package repository (built from SuiteSparse v3.4.0) **cannot** be used to build Ceres as a *shared* library. Thus if you want to build Ceres as a shared library using SuiteSparse, you must perform a - source install of SuiteSparse or use an external PPA (see - `bug report here `_). + source install of SuiteSparse or use an external PPA (see `bug report + here + `_). It is recommended that you use the current version of SuiteSparse (4.2.1 at the time of writing). @@ -333,15 +345,16 @@ dependencies. are at least two possible fixes to this problem: #. Use ``google-glog`` and define ``GLOG_NO_ABBREVIATED_SEVERITIES`` - when building Ceres and your own project, as documented - `here `__. - Note that this fix will not work for ``miniglog``, - but use of ``miniglog`` is strongly discouraged on any platform for which + when building Ceres and your own project, as documented `here + `__. + Note that this fix will not work for ``miniglog``, but use of + ``miniglog`` is strongly discouraged on any platform for which ``google-glog`` is available (which includes Windows). - #. If you do not require GDI, then define ``NOGDI`` **before** including - windows.h. This solution should work for both ``google-glog`` and - ``miniglog`` and is documented for ``google-glog`` - `here `__. + #. If you do not require GDI, then define ``NOGDI`` **before** + including windows.h. This solution should work for both + ``google-glog`` and ``miniglog`` and is documented for + ``google-glog`` `here + `__. #. Make a toplevel directory for deps & build & src somewhere: ``ceres/`` #. Get dependencies; unpack them as subdirectories in ``ceres/`` @@ -353,17 +366,19 @@ dependencies. #. ``google-glog`` Open up the Visual Studio solution and build it. #. ``gflags`` Open up the Visual Studio solution and build it. - #. (Experimental) ``SuiteSparse`` Previously SuiteSparse was not available - on Windows, recently it has become possible to build it on Windows using - the `suitesparse-metis-for-windows `_ - project. If you wish to use ``SuiteSparse``, follow their instructions - for obtaining and building it. + #. (Experimental) ``SuiteSparse`` Previously SuiteSparse was not + available on Windows, recently it has become possible to build + it on Windows using the `suitesparse-metis-for-windows + `_ + project. If you wish to use ``SuiteSparse``, follow their + instructions for obtaining and building it. - #. (Experimental) ``CXSparse`` Previously CXSparse was not available on - Windows, there are now several ports that enable it to be, including: - `[1] `_ and - `[2] `_. If you wish to use - ``CXSparse``, follow their instructions for obtaining and building it. + #. (Experimental) ``CXSparse`` Previously CXSparse was not + available on Windows, there are now several ports that enable it + to be, including: `[1] `_ + and `[2] `_. If you + wish to use ``CXSparse``, follow their instructions for + obtaining and building it. #. Unpack the Ceres tarball into ``ceres``. For the tarball, you should get a directory inside ``ceres`` similar to @@ -391,12 +406,13 @@ dependencies. #. (Optional) ``CXSPARSE_INCLUDE_DIR_HINTS`` #. (Optional) ``CXSPARSE_LIBRARY_DIR_HINTS`` - to the appropriate directories where you unpacked/built them. If any of - the variables are not visible in the ``CMake`` GUI, create a new entry - for them. We recommend using the ``_(INCLUDE/LIBRARY)_DIR_HINTS`` - variables rather than setting the ``_INCLUDE_DIR`` & - ``_LIBRARY`` variables directly to keep all of the validity - checking, and to avoid having to specify the library files manually. + to the appropriate directories where you unpacked/built them. If + any of the variables are not visible in the ``CMake`` GUI, create a + new entry for them. We recommend using the + ``_(INCLUDE/LIBRARY)_DIR_HINTS`` variables rather than + setting the ``_INCLUDE_DIR`` & ``_LIBRARY`` variables + directly to keep all of the validity checking, and to avoid having + to specify the library files manually. #. You may have to tweak some more settings to generate a MSVC project. After each adjustment, try pressing Configure & Generate @@ -442,8 +458,9 @@ iOS You need iOS version 7.0 or higher to build Ceres Solver. -To build Ceres for iOS, we need to force ``CMake`` to find the toolchains from -the iOS SDK instead of using the standard ones. For example: +To build Ceres for iOS, we need to force ``CMake`` to find the +toolchains from the iOS SDK instead of using the standard ones. For +example: .. code-block:: bash @@ -454,21 +471,24 @@ the iOS SDK instead of using the standard ones. For example: ``PLATFORM`` can be: ``OS``, ``SIMULATOR`` or ``SIMULATOR64``. You can -build for ``OS`` (``armv7``, ``armv7s``, ``arm64``), ``SIMULATOR`` (``i386``) or -``SIMULATOR64`` (``x86_64``) separately and use ``lipo`` to merge them into -one static library. See ``cmake/iOS.cmake`` for more options. +build for ``OS`` (``armv7``, ``armv7s``, ``arm64``), ``SIMULATOR`` +(``i386``) or ``SIMULATOR64`` (``x86_64``) separately and use ``lipo`` +to merge them into one static library. See ``cmake/iOS.cmake`` for +more options. -After building, you will get a ``libceres.a`` library, which you will need to -add to your Xcode project. +After building, you will get a ``libceres.a`` library, which you will +need to add to your Xcode project. The default CMake configuration builds a bare bones version of Ceres -Solver that only depends on Eigen (``MINIGLOG`` is compiled into Ceres if it is -used), this should be sufficient for solving small to moderate sized problems -(No ``SPARSE_SCHUR``, ``SPARSE_NORMAL_CHOLESKY`` linear solvers and no -``CLUSTER_JACOBI`` and ``CLUSTER_TRIDIAGONAL`` preconditioners). +Solver that only depends on Eigen (``MINIGLOG`` is compiled into Ceres +if it is used), this should be sufficient for solving small to +moderate sized problems (No ``SPARSE_SCHUR``, +``SPARSE_NORMAL_CHOLESKY`` linear solvers and no ``CLUSTER_JACOBI`` +and ``CLUSTER_TRIDIAGONAL`` preconditioners). -If you decide to use ``LAPACK`` and ``BLAS``, then you also need to add -``Accelerate.framework`` to your Xcode project's linking dependency. +If you decide to use ``LAPACK`` and ``BLAS``, then you also need to +add ``Accelerate.framework`` to your Xcode project's linking +dependency. .. _section-customizing: @@ -477,28 +497,30 @@ Customizing the build It is possible to reduce the libraries needed to build Ceres and customize the build process by setting the appropriate options in -``CMake``. These options can either be set in the ``CMake`` GUI, -or via ``-D