This was an ill-advised and complicated to interpret option
which offers nothing particularly useful.
Change-Id: Ia7741ed62ef977c96fa52299a884e404bee659ac
Thanks to nate-thirdwave@ for pointing this out and offering
a fix.
Also add a TODO about an odd loop in covariance_impl.cc which was
revealed as I was testing the bazel build
https: //github.com/ceres-solver/ceres-solver/issues/800
Change-Id: I87d17155ee43ea2a52b8031177d6b3ac5ae1460a
With this change, the user can now choose between Approximate Minimum
Degree and Nested Dissection as a fill reducing algorithm when using
a sparse direct factorization based linear solver like SPARSE_NORMAL_CHOLESKY
or SPARSE_SCHUR.
Currenly only SUITE_SPARSE is supported. It requires that
SuiteSparse be compiled with Metis support enabled.
On most problems AMD is still the better choice, but in some cases
like the grid3D dataset from https://lucacarlone.mit.edu/datasets/
the solution time with AMD is 57s and with NESDIS 38 on my M1 Mac.
On some other problems at Google we have observed speedups of 10x,
there is also a corresponding decrease in the total amount of memory
used.
This patch is based on the original work done by NeroBurner in
https://ceres-solver-review.googlesource.com/c/ceres-solver/+/20580
1. Add a new enum to the public api LinearSolverOrderingType and
a setting Solver::Options::linear_solver_ordering_type.
2. TrustRegionPreprocessor had some complicated logic which determined
when linear solvers should reorder their matrices on their own and not
this has been refactored into a more readable function that lives
inside reorder_program.h/cc.
3. Plumbing in reorder_program.cc and trust_region_processor.cc to use
nested dissection.
4. Update bundle_adjuster.cc to use nested dissection.
Change-Id: I388b027934f86c58b4da2b65a4fa5204ea73bf40
1. Generalize SuiteSparse::AnalyzeCholesky and
SuiteSparse::BlockAnalyzeCholesky from just doing AMD to taking
OrderingType as an argument and using that to determine whether
AMD & Nested Dissection algorithms are used for computing the
fill-reducing ordering or a natural ordering when computing
the symbolic factorization.
2. Remove AnalyzeCholeskyWithNaturalOrdering.
3. Replace and generalize SuiteSparse::BlockAMDOrdering with
SuiteSparse::BlockOrdering which also takes OrderingType as an
argument. Same for SuiteSparse::ApproximateMinimumDegreeOrdering
and SuiteSparse::NestedDissectionOrdering by
SuiteSparse::Ordering.
4. Remove LinearSolver::Options::use_postordering and replace it
with LinearSolver::Options::ordering_type.
5. Replace Preconditioner::Options::use_postordering and replace it
with Preconditioner::Options::ordering_type.
6. Add NESDIS to OrderingType. With the above changes, the linear
solvers can now use Nested Dissection once this information
is piped through the nonlinear solver.
Change-Id: Ib8e93fbf34ae2981bf2ac54dcda9e25c7c213790
With this change we can drop the complicated/conditional handling
around CAMD and assume that it is always available.
Change-Id: I93e1da676fb75817f79824b8b2b6549d03f278b0
Instead of having four separate scalars, allocate them as
an array as they are all touched as a group of four.
Change-Id: I773cfc08cf53b66032985c11a4b0ebc06db06083
Compiling jet_test using the /std:c++17 switch triggers a C3198 compile
error in <numeric>. Moving #pragma below all the includes, allows to
workaround the issue.
Additionally, locally ensure the floating-point model is always
/fp:precise to be able to access the floating-point environment in
jet_test.
Change-Id: Ia5b3a3dac13baf46546ac1d0d304fc05512f8816
pair_hash.h uses std::size_t and std::hash but does not include the
corresponding headers <cstddef> and <functional>.
Change-Id: I194a5c76e8f50b1574e1359f616351581033c576
* Use generator expression instead of CMAKE_RUNTIME_OUTPUT_DIRECTORY
to get the path of compiled CUDA test targets when running
cuda-memcheck tests.
* Only add cuda-memcheck targets if testing is enabled.
Change-Id: Idea498dd9008b7e5075d4af9775f9f43716e22f1
covariance.h was using SUITE_SPARSE even when SUITESPARSE
was disabled because it did not have config.h included in it
so it did not see that CERES_NO_SUITESPARSE was defined.
Add more config.h includes to files that are using these
configuration macros.
Change-Id: I6b1d2c2bd9e559de40a6332cd6be85ad4da3377b
Overriding export gflags export macros breaks glog in shared Ceres
solver builds. Threfore, always compile gtest as a static library to
avoid the need of overriding the export macros.
Change-Id: Ibc9a04a771085caa8f02c81745ce626643df8450
These changes allow the use of a SuiteSparse CMake package from
https://github.com/sergiud/SuiteSparse that allows native compilation of
SuiteSparse using CMake on a variety of platforms Packages generated
using official SuiteSparse makefiles can still be used without
modifications. The find module remains agnostic to specific CMake
package implementation.
CMake packages have the advantage that they are self-contained and
relocatable. The latter is particularly useful in cross-compilation
scenarios.
Fixes#728
Change-Id: I089d5c6f87c05b1530a5ab9a36dff2fcbe82d13d
In many cases, manifolds stored in ProductManifold have a default
constructor which can simplify ProductManifold initialization even
further. Allow default construction of ProductManifold in this case.
Change-Id: I29b2612870c02232556688019a77049709684a55
* Fix workspace type in CUDADenseQR and CUDADenseCholesky --
Workspace sizes are in terms of number of elements, not bytes.
* Add cuda-memcheck tests to catch such CUDA memory errors in
the future.
Change-Id: I3dd0f0947daba9e4c6cd0216bef81d694547d505
Since the number of manifolds used to initialize ProductManifold and
their types are known at compile-time, it is possible to avoid storing
pointers to the base class as required by a homogeneous, currently
dynamically sized container. Instead, we can use std::tuple<> as a
heterogenous container with the number of elements fixed at compile-time
that allows us to store the concrete manifold realizations.
The advantage of this approach is that we can bypass the vtable when
iterating over each manifold within ProductManifold. The indirection is
invoked only once while accessing the ProductManifoldImpl members.
Additionally, potential dynamic memory allocations by a std::vector can
be completely avoided. This makes the ProductManifold implementation
more efficient both in memory and runtime.
Change-Id: Ic71b0c175ab726f8992e9703f7666bca477baf19
Previously they were defined in manifold.h but their implementations
were in the internal directory and to prevent circular dependencies
the implementation headers were pushed to the bottom of manifold.h
This started out as one header and has become progressively worse
as more manifolds are templated.
This change moves the two manifolds into their own headers which
also contain their implementations.
Change-Id: I671da0279a47cd2ff1f52c69a1d159426f55bd80
This brings it in line with other manifolds like SphereManifold
and LineManifold, where the user has the choice to specify the size
of the manifold at compile time or runtime.
Most of the time the size is known at compile time so this will
speed up the common case.
Change-Id: I0c7ff8b7a9a64a81203eb11afc074874e208815a
Disable the definition of `min`/`max` macros by defining `NOMINMAX`
and prevent macro substitution in the public interface.
Also, quiet floating-point comparisons are defined as template functions
by the MSVC STL which causes compilation errors due to ambiguities in
resolving the template parameter types.
Fixes#668Fixes#716Fixes#718
Change-Id: I5fe7832a6a3a7ad0421a2557527528c34b88e9c7
Also refactor the logic for generating ba tests a bit
breaking it into dense, sparse and iterative tests.
Change-Id: I6b33e3b047ef900b12907bd150febe4744779b7a
Current language standard selection mechanism is quite convoluted and
the logic for propagating a specific C++ language standard (which cannot
be fully enforced anyway) is unnecessarily complicated. Instead
communicate the minimum required C++ standard and let CMake handle the
requirement. This allows the compiler and consumers to use newer
language revisions if available. The language standard used to compile
Ceres solver can still be set via `CMAKE_CXX_STANDARD`.
Move to CMake 3.10 which is supported by Ubuntu 18.04 LTS and simplify
the corresponding language features request.
Change-Id: Ib1f95e2bc5f06bf1275a62565d303eb0f114d127
1. Add CUDA initialization and cleanup management to the
ContextImpl object. The ContextImpl is now solely responsible
for managing CUDA-related resources.
2. All CUDA dense solvers now use lazy CUDA initialization
via the ContextImpl object.
Change-Id: Ief456860c72e462367ee997d389c19e2bff50baf
Sameer Agarwal