C++ library for solving large sparse linear systems with algebraic multigrid method

Overview

AMGCL

Documentation Status DOI Build Status Build status codecov Coverity Scan Build Status

AMGCL is a header-only C++ library for solving large sparse linear systems with algebraic multigrid (AMG) method. AMG is one of the most effective iterative methods for solution of equation systems arising, for example, from discretizing PDEs on unstructured grids. The method can be used as a black-box solver for various computational problems, since it does not require any information about the underlying geometry. AMG is often used not as a standalone solver but as a preconditioner within an iterative solver (e.g. Conjugate Gradients, BiCGStab, or GMRES).

AMGCL builds the AMG hierarchy on a CPU and then transfers it to one of the provided backends. This allows for transparent acceleration of the solution phase with help of OpenCL, CUDA, or OpenMP technologies. Users may provide their own backends which enables tight integration between AMGCL and the user code.

See AMGCL documentation at http://amgcl.readthedocs.io/

Referencing

Demidov, Denis. AMGCL: An efficient, flexible, and extensible algebraic multigrid implementation. Lobachevskii Journal of Mathematics, 40(5):535–546, May 2019. doi pdf bib

Demidov, Denis. AMGCL -- A C++ library for efficient solution of large sparse linear systems. Software Impacts, 6:100037, November 2020. doi bib

Demidov, Denis, Lin Mu, and Bin Wang. Accelerating linear solvers for Stokes problems with C++ metaprogramming. Journal of Computational Science (2020): 101285. doi arxiv bib

Support

Issues
  • Stokes problem gives NaN by AMG but GMRES works fine

    Stokes problem gives NaN by AMG but GMRES works fine

    I'm trying to use AMGCL to solve a simple Stokes problem using finite element method. The linear system is similar to Naiver-Stokes one:

    [K G * {u = {b_u D S] p} b_p}

    2nd Order FEM System size: 4080 x 4080 u is the unknows for velocity from 1 - 3600 p is the unkonws for pressure from 3601-4080

    Tets=48 (I tried larger mesh which still gives me the similar error)

    G and D are non-square. S has zero-diagonal. This is a typical saddle-point problem matrix for Stokes. image

    Download the linear system here Ab_mm.zip

    Based on the benchmark problem, I trying to solve the system using following solver

    1. GMRES + ILU0, GOOD
    2. AMG + ILU0 and, NAN
    3. Schur Pressure AMG. Crash

    But only 1) GMRES + ILU0 wokrs, any AMG solver return nan or Crash.

    Can you check why AMGCL is not working here?

    Thanks, Bin

    output info:

    Solver
    ======
    Type:             FGMRES(30)
    Unknowns:         4080
    Memory footprint: 1.94 M
    
    Preconditioner
    ==============
    Number of levels:    2
    Operator complexity: 1.01
    Grid complexity:     1.02
    Memory footprint:    6.88 M
    
    level     unknowns       nonzeros      memory
    ---------------------------------------------
        0         4080         201072      6.85 M (98.77%)
        1           71           2503     37.69 K ( 1.23%)
    
    #Iters=1000 Error=nan
    

    My solver set up are:

    typedef amgcl::backend::builtin<double> Backend;
    
    //Simple iterative solver GMRES + ILU0
    typedef amgcl::make_solver<
    	relaxation::as_preconditioner<Backend, relaxation::ilu0>,
    	solver::fgmres<Backend>
    > Solver1;
    
    //AMG + ILU0
    typedef make_solver<
    	amg<Backend, coarsening::smoothed_aggregation, relaxation::ilu0>,
    	solver::fgmres<Backend>
    > Solver2;
    
    //Parameter setup
    Solver::params prm;
    double tol = 1e-6;
    prm.solver.tol = tol;
    prm.solver.maxiter = 1000;
    
    //Solve the system
    Solver solve(A,prm);
    std::cout << solve << std::endl;
    
    int iters;
    double error;
    std::tie(iters, error) = solve(b, X);
    printf("#Iters=%d Error=%lf\n", iters, error);
    

    Specially my schur_pressure_correction are:

    typedef make_solver<
    	preconditioner::schur_pressure_correction<
    	make_solver<
    	relaxation::as_preconditioner<Backend, relaxation::damped_jacobi>,
    	solver::bicgstab<Backend>
    	>,
    	make_solver<
    	amg<
    	Backend,
    	coarsening::smoothed_aggregation,
    	relaxation::ilu0
    	>,
    	solver::fgmres<Backend>
    	>
    	>,
    	solver::fgmres<Backend>
    > Solver;
    
    //Parameter setup
    Solver::params prm;
    double tol = 1.0e-6;
    prm.solver.tol = tol;
    prm.precond.usolver.solver.tol = tol * 10;
    prm.precond.psolver.solver.tol = tol * 10;
    prm.precond.psolver.solver.maxiter = 1000;
    prm.precond.usolver.solver.maxiter = 1000;
    
    for(size_t i=0;i<rows;++i)
    	if(i>3600) prm.precond.pmask[i] = 1;
    
    //Solve the system
    Solver solve(A,prm);
    std::cout << solve << std::endl;
    
    int iters;
    double error;
    std::tie(iters, error) = solve(b, X);
    printf("#Iters=%d Error=%lf\n", iters, error);
    
    opened by BinWang0213 61
  • Complex GMRES solver

    Complex GMRES solver

    I may have found a small bug in the generic GMRES implementation. Please take a look at [1] in Section 6.5.9 on the complex implementation of GMRES. They state that the complex Givens rotation is defined slightly different from the real one, see equation 6.80. When I change it here accordingly, I get much better convergence in the complex case. Can you confirm this? Do you think there will be a similar issue for LGMRES and FGMRES?

    Chris

    [1] Saad, Yousef. Iterative methods for sparse linear systems. Siam, 2003.

    opened by dondieselkopf 33
  • Getting start with amgcl on Visual Studio 2012

    Getting start with amgcl on Visual Studio 2012

    Hi Denis,

    Thanks for your work about this open source package. I am a student working on solve large dense linear system (i.e. Ax = b where A is dense and large). I wrote my own iterative complex gmres solver with preconditioner and I hope I can get a better performance with this amazing amgcl package. I am new to amgcl and based on my previous experience, to use this header-only package, I only need to let the compiler know the path to include the headers. And also to use amgcl, I also tried to build a boost library. However, when I tried to include headers in the "getting start" example in tutorial, it has several errors:

    Code:

    #include <amgcl/make_solver.hpp>
    #include <amgcl/solver/bicgstab.hpp>
    #include <amgcl/amg.hpp>
    #include <amgcl/coarsening/smoothed_aggregation.hpp>
    #include <amgcl/relaxation/spai0.hpp>
    #include <amgcl/adapter/crs_tuple.hpp>
    
    int main(){
    return 0;
    }
    

    Errors: image

    My env: Visual Studio 2012 w/ msvc-11.0 Boost 1.69

    I wonder what other steps I need or what I did wrong to make amgcl work on my system. I am sorry if this question is too simple since I am really new to these stuff. Any help will be appreciated.

    opened by ZhuonanLin 26
  • Block preconditioners in AMGCL for u,p formulation

    Block preconditioners in AMGCL for u,p formulation

    Hi I have been racking my brains to solve U,P formulation for elasticity equations using AMGCL, to no avail..

    using Backend = amgcl::backend::eigen<double>;
    using AmgSolver1 = amgcl::make_solver<
        amgcl::preconditioner::schur_pressure_correction<
            amgcl::make_solver<
                amgcl::relaxation::as_preconditioner<Backend, amgcl::relaxation::damped_jacobi>,
                amgcl::solver::bicgstab<Backend>
                >,
            amgcl::make_solver<
                amgcl::amg<
                    Backend,
                    amgcl::coarsening::smoothed_aggregation,
                    amgcl::relaxation::ilu0
                    >,
                amgcl::solver::gmres<Backend>
                >
            >,
        amgcl::solver::gmres<Backend>
        >;
    
    AmgSolver1::params prm;
    
    prm.solver.tol = 1e-5;	
    prm.precond.usolver.solver.tol = prm.solver.tol * 10;
    prm.precond.psolver.solver.tol = prm.solver.tol * 10;
    prm.precond.psolver.solver.maxiter = 100;
    prm.precond.usolver.solver.maxiter = 200;
    prm.solver.maxiter = 400;
    
    prm.precond.pmask.resize(Bm.size(), 0);
    for(size_t i = _numLocalDofs[0]; i < Bm.size(); ++i)
        prm.precond.pmask[i] = 1;
    
    
    //prm.precond.usolver.precond.max_levels = 3;
    //prm.precond.ncycle = 2;
    //prm.precond.npre = 4;
    //prm.precond.pre_cycles = 4;
    
    AmgSolver1 solver(*A, prm);		
    
    int    iters;
    double error;
    std::tie(iters, error) = solver(Bm, X);
    std::cout << iters << " " << error << std::endl;
    
    return X;
    
    

    I am unable to set even number of levels for these preconditioners. It appears already pre-chosen and fixed despite what I set it to.

    Either way the solver fails with Segmentation fault.

    Can you provide any insight as to what I might be missing?

    Many Thanks!

    opened by saurabh636 23
  • Complex-valued problems

    Complex-valued problems

    Hi.

    I would like to solve a complex-valued problem without rewriting it into a real-valued one. Unfortunately, I wasn't successful in using std::complex instead of double. I get a bunch of errors, for a large part related to implicit conversion where you wrote "1/x" instead of "1./x". Also, some comparisons have to be rewritten as "fabs(eps)>fabs(x)". Both can be fixed straightforwardly.

    However, I was wondering whether you see more substantial issues within the algorithms when plugging in a complex type?

    Thanks, Chris

    opened by dondieselkopf 23
  • Question: Using amgcl with MPI

    Question: Using amgcl with MPI

    So I am reading through the benchmark distributed Poisson equation implementation to figure out how I could have the linear elasticity problem I have with amgcl run on several MPI nodes. But I still have some questions I was hoping you might answer:

    • How do I split up my matrix on each node? Assuming I have hexahedral elements. Do I create smaller matrices for sub-volumes of the full image?
    • Do I have one node in each direction of overlap?
    • Are the matrices on each node stored with local indices, or do I store the global index for each element?
    • Do I need to tell amgcl the overlap somewhere? I couldn't find anything hinting at that.
    • Is it also possible for the MPI version to use my custom matrix class as input (which is working for the shared memory version)?
    question 
    opened by NOhs 22
  • Build issues with Anaconda

    Build issues with Anaconda

    So to build I am first creating a build directory inside amgcl and then running

    [ steven ] [~/Programming/amgcl/build] > cmake ..                               [master ✔]
    -- No build type selected, default to RelWithDebInfo
    -- The C compiler identification is GNU 5.3.1
    -- The CXX compiler identification is GNU 5.3.1
    -- Check for working C compiler: /usr/bin/cc
    -- Check for working C compiler: /usr/bin/cc -- works
    -- Detecting C compiler ABI info
    -- Detecting C compiler ABI info - done
    -- Detecting C compile features
    -- Detecting C compile features - done
    -- Check for working CXX compiler: /usr/bin/c++
    -- Check for working CXX compiler: /usr/bin/c++ -- works
    -- Detecting CXX compiler ABI info
    -- Detecting CXX compiler ABI info - done
    -- Detecting CXX compile features
    -- Detecting CXX compile features - done
    -- Try OpenMP C flag = [-fopenmp]
    -- Performing Test OpenMP_FLAG_DETECTED
    -- Performing Test OpenMP_FLAG_DETECTED - Success
    -- Try OpenMP CXX flag = [-fopenmp]
    -- Performing Test OpenMP_FLAG_DETECTED
    -- Performing Test OpenMP_FLAG_DETECTED - Success
    -- Found OpenMP: -fopenmp  
    -- Boost version: 1.60.0
    -- Found the following Boost libraries:
    --   program_options
    --   system
    --   filesystem
    --   serialization
    --   unit_test_framework
    -- Found METIS: /usr/include/metis  
    -- Could NOT find SCOTCH (missing:  SCOTCH_LIBRARIES) 
    -- Could NOT find PASTIX (missing:  PASTIX_INCLUDES PASTIX_LIBRARIES) 
    -- Looking for pthread.h
    -- Looking for pthread.h - found
    -- Looking for pthread_create
    -- Looking for pthread_create - not found
    -- Looking for pthread_create in pthreads
    -- Looking for pthread_create in pthreads - not found
    -- Looking for pthread_create in pthread
    -- Looking for pthread_create in pthread - found
    -- Found Threads: TRUE  
    -- Found PythonInterp: /home/steven/.anaconda2/bin/python (found version "2.7.11") 
    -- Found PythonLibs: /home/steven/.anaconda2/lib/libpython2.7.so (found suitable version "2.7.11", minimum required is "2.7.11") 
    -- Found NumPy: version "1.10.4" /home/steven/.anaconda2/lib/python2.7/site-packages/numpy/core/include
    -- Boost version: 1.60.0
    -- Found the following Boost libraries:
    --   system
    --   filesystem
    --   python
    -- Configuring done
    -- Generating done
    -- Build files have been written to: /home/steven/Programming/amgcl/build
    

    The first thing I notice is that SCOTCH and PASTIX are missing. I have tried installing scotch libraries. I have scotch, libscotchmetis-dev, libscotch-dev installed. The other thing I notice is that it is calling my boost version 1.60. Running $ dpkg -S /usr/include/boost/version.hpp I see that the output is libboost1.58-dev:amd64. Doing $ find ~/.anaconda2 -name boost (my anaconda install path, see cmake output) I find it listing packages as the 1.60.0 version, as would be suggested by the cmake output.

    Since no errors were thrown I decided to try and run make where it failed at [ 3%] Linking CXX executable test_solver_ns_eigen on a boost error. Where it couldn't find a library. It is looking in the anaconda/include/boost folder so I thought I'd reset to the system's version of boost.

    $ cmake -DBOOST_ROOT=/usr/include/boost/ -DBOOST_INCLUDEDIR=/usr/include .. which does show the boost version as 1.58.0 at the end of the cmake. Again it seems to be finding the anaconda version of boost and erroring at the same 3% mark. Here is the error

    [  3%] Linking CXX executable test_solver_ns_eigen
    CMakeFiles/test_solver_ns_eigen.dir/test_solver_ns_eigen.cpp.o: In function `__static_initialization_and_destruction_0':
    /home/steven/Programming/amgcl/tests/test_solver_ns_eigen.cpp:8: undefined reference to `boost::unit_test::ut_detail::auto_test_unit_registrar::auto_test_unit_registrar(boost::unit_test::basic_cstring<char const>, boost::unit_test::basic_cstring<char const>, unsigned long, boost::unit_test::decorator::collector&)'
    CMakeFiles/test_solver_ns_eigen.dir/test_solver_ns_eigen.cpp.o: In function `boost::unit_test::make_test_case(boost::function<void ()> const&, boost::unit_test::basic_cstring<char const>, boost::unit_test::basic_cstring<char const>, unsigned long)':
    /home/steven/.anaconda2/include/boost/test/tree/test_unit.hpp:249: undefined reference to `boost::unit_test::test_case::test_case(boost::unit_test::basic_cstring<char const>, boost::unit_test::basic_cstring<char const>, unsigned long, boost::function<void ()> const&)'
    CMakeFiles/test_solver_ns_eigen.dir/test_solver_ns_eigen.cpp.o: In function `__static_initialization_and_destruction_0':
    /home/steven/Programming/amgcl/tests/test_solver_ns_eigen.cpp:10: undefined reference to `boost::unit_test::ut_detail::auto_test_unit_registrar::auto_test_unit_registrar(boost::unit_test::test_case*, boost::unit_test::decorator::collector&, unsigned long)'
    CMakeFiles/test_solver_ns_eigen.dir/test_solver_ns_eigen.cpp.o: In function `bool boost::test_tools::tt_detail::check_frwd<boost::test_tools::check_is_small_t, double, double>(boost::test_tools::check_is_small_t, boost::unit_test::lazy_ostream const&, boost::unit_test::basic_cstring<char const>, unsigned long, boost::test_tools::tt_detail::tool_level, boost::test_tools::tt_detail::check_type, double const&, char const*, double const&, char const*)':
    /home/steven/.anaconda2/include/boost/test/tools/old/impl.hpp:92: undefined reference to `boost::test_tools::tt_detail::report_assertion(boost::test_tools::assertion_result const&, boost::unit_test::lazy_ostream const&, boost::unit_test::basic_cstring<char const>, unsigned long, boost::test_tools::tt_detail::tool_level, boost::test_tools::tt_detail::check_type, unsigned long, ...)'
    /home/steven/.anaconda2/include/boost/test/tools/old/impl.hpp:92: undefined reference to `boost::test_tools::tt_detail::report_assertion(boost::test_tools::assertion_result const&, boost::unit_test::lazy_ostream const&, boost::unit_test::basic_cstring<char const>, unsigned long, boost::test_tools::tt_detail::tool_level, boost::test_tools::tt_detail::check_type, unsigned long, ...)'
    collect2: error: ld returned 1 exit status
    tests/CMakeFiles/test_solver_ns_eigen.dir/build.make:99: recipe for target 'tests/test_solver_ns_eigen' failed
    make[2]: *** [tests/test_solver_ns_eigen] Error 1
    CMakeFiles/Makefile2:105: recipe for target 'tests/CMakeFiles/test_solver_ns_eigen.dir/all' failed
    make[1]: *** [tests/CMakeFiles/test_solver_ns_eigen.dir/all] Error 2
    Makefile:138: recipe for target 'all' failed
    make: *** [all] Error 2
    

    Turning the debug flag for boost on (in cmake) I see no paths leading to anaconda. cmake -DBOOST_ROOT:PATHNAME=/usr/include/boost/ -DBOOST_INCLUDEDIR=/usr/include -DBoost_DEBUG=ON .. | grep ".anaconda2" shows no output, as expected.

    And at this point I'm pretty lost at where the error is arising.

    opened by stevenwalton 22
  • Coarsening using near null space vectors

    Coarsening using near null space vectors

    Hi Denis,

    I'm trying to use rigid body modes in the coarsening with the example solve.cpp. The problem is that I have a segmentation fault running this problem with one null-space vector

    ./solver -A A.mtx -f b.mtx -N N.mtx -p solver.type=cg solver.tol=1e-8 solver.maxiter=5000 precond.relax.type=ilu0
    
    Segmentation fault (core dumped)
    

    The problem is running obviating the rigid body mode

    ./solver -A A.mtx -f b.mtx -p solver.type=cg solver.tol=1e-8 solver.maxiter=5000 precond.relax.type=ilu0
    
    Solver
    ======
    Type:             CG
    Unknowns:         9506
    Memory footprint: 297.06 K
    
    Preconditioner
    ==============
    Number of levels:    2
    Operator complexity: 1.02
    Grid complexity:     1.03
    Memory footprint:    6.49 M
    
    level     unknowns       nonzeros      memory
    ---------------------------------------------
        0         9506         167620      6.40 M (98.41%)
        1          325           2701     98.80 K ( 1.59%)
    
    Iterations: 144
    Error:      7.67667e-09
    
    [Profile:       0.313 s] (100.00%)
    [ self:         0.000 s] (  0.11%)
    [  reading:     0.181 s] ( 57.90%)
    [  setup:       0.008 s] (  2.52%)
    [  solve:       0.123 s] ( 39.48%)
    

    I would appreciate if you can check that the format of N.mtx is right and also the procedure. Thanks in advantage.

    opened by davidherreroperez 21
  • Block preconditioners

    Block preconditioners

    Hi,

    I'm looking to solve a linear system which is algebraically similar to the Stokes problem, in the sense that I have a matrix in the following block form:

    [ A     B ]
    [ B^T   0 ]
    

    with A symmetric positive definite, and B has full row rank.

    I am trying to find an efficient way to solve this system, and I hope to be able to adapt techniques one may use for the Stokes problem, as seen towards the end in this lecture by Wolfgang Bangerth. In this video, Bangerth advocates using the following (right) block preconditioner in conjunction with GMRES:

    [ A^-1    -A^-1 B^T S^-1 ]
    [ 0            S^-1      ]
    

    where S = B^T A^-1 B. Of course, one does not know the exact inverses of A and S, so one would like to approximate these. For the Stokes problem, one can approximate S^-1 by the inverse of the mass matrix (but for my problem I need to use a different matrix that I hope is somewhat similar), and Bangerth suggests using "one step of multigrid" to approximate the action of applying A^-1.

    I've been poking around the docs and the source code, and I think it should be possible to accomplish this kind of block-preconditioning with amgcl. Is this correct? I see that there's a block_preconditioner.hpp related to MPI, and also a schur_pressure_correction.hpp, both of which might be useful for me to understand how to assemble this, but I find it a little hard to decipher what's going on, especially since I'm not familiar with Schur pressure correction.

    In particular, can I perform "one step" of AMG for the approximation of A^-1? I'm struggling to see how to assemble the pieces, and any suggestions (or confirmation on whether or not I can do what I want) would be most welcome!

    P.S: I realize this is not truly an "issue", but I could not find any other place to ask questions to the community of users of amgcl. I hope this is OK.

    opened by Andlon 20
  • QR decomposition fails

    QR decomposition fails

    Hi Denis,

    Hope you are doing great. Nice to see that your project keeps advancing. There is a minor issue which I cannot really sort out myself. I recently tried to use your QR decomposition on a complex matrix. However, I get a few nan's in the result. When using Mathematica things seem okay. I have added some code in your QR test case to check it:

    https://github.com/dondieselkopf/amgcl/commit/355c521c631fe7859ca952c5692bb9302aef2dbf

    Input matrix can be found here: X.tar.gz

    I don't know if the problem is with the code or with my matrix. Maybe you have time to take a look at it.

    Cheers, Chris

    PS: There was a minor bug in the mm.hpp file (see my commit).

    opened by dondieselkopf 20
  • Improve solving times for SPD matrices larger than 100.000x100.000

    Improve solving times for SPD matrices larger than 100.000x100.000

    Hi Denis,

    I have a problem that requires several Ax = b solves, my current goal is use AMG to improve the times of my final solution. The main issue I have at this point is that I can calculate an accurate solution for the first and second linear system solves, after the 3 one is stuck and if I add a simple maxiter limit to something like 100 or 200, it does not generates a proper result

    Matrix and problem description:

    1. Is an SPD matrix of 120000x120000 with over 2M nnz
    2. Epsilon for error should be around 1e-4 and 1e-8
    3. As it is SPD I have used CG solver

    Those are the current matrices

    NOTE: All have been tested as tutorial suggest with the example/solver file

    So my question here is about changes on the relaxation and coarsening strategies and its parameters in order to improve the convergence of this matrices

    opened by mobereng 10
  • The applicability for periodic problem

    The applicability for periodic problem

    Hello,Denis I want to use the AMGCL to solve a 3D poisson equation(nnn) with periodic boundary condition. When I construct the coefficient matrix A, I put the nonzero coefficient into the vector col and val just as the example case. For example, for the equation of point(1,1,1),the col number of seven nonzero coefficient is (idx-n^2+n^3), (idx-n+n^2), (idx-1+n), idx, (idx+1), (idx+n), (idx+n^2). [ idx=1] Although the residual of the equations decresed to a quite small level, the result is much different from the exact solution in this way. What else I should do to solve this kind of periodic problem after I set the value and col number of all the nonzero element? Sorry to bother you. Best Regards!

    opened by DOUBLE-1024 2
  • The convergence theory for iterative methods as preconditioner

    The convergence theory for iterative methods as preconditioner

    I'm sorry to distrub you for something having nothing to do with code. I am confused about the precondtioners for the solvers as CG, GMRES. As stated the book of Saad "Iterative methods for sparse linear systems", the flexiable variant of GMRES is seperately discussed for the cases where M is not a constant operator (as you did in the AMGCL). I want to kown: 1.Whether is it the right way to use nested precondtioner for solvers like CG, GMRES? or I need to use the flexiable version of those solvers, especially CG. Maybe I need to get more literature to learn about that. 2.As far as I thought, algebraic multigrid is not a constant operator as preconditioner, I am not sure it is right.

    opened by g873249824 4
  • Recommendations for solver type and preconditioners

    Recommendations for solver type and preconditioners

    Hi Denis !

    At the moment I'm using the default builtin solver <double> type with coarsening::smoothed_aggregation and relaxation::spai0 I'm creating this issue to ask, what you think is better in terms of results accuracy and speed. All my matrix cases are SPD, I'm solving AtA x = Atb energy minimization (least squares problem) with dimentions from 7000x7000 to 200.000x200.000

    I will also test today with CUDA

    Appreciate your help !

    opened by mobereng 7
  • Can I couple custom solvers with the preconditioners?

    Can I couple custom solvers with the preconditioners?

    Dear Denis,

    I am new to AMG and AMGCL. I modified Fortran/poisson.f90 to solve a three-dimensional poisson problem. Besides, I compared the efficiency of implemented BiCGStab solver and my custom solver (based on BICGS, without any coarsening operations, written in pure Fortran). No MPI or OpenMP or GPU accelerating techniques were used.

    call cpu_time(tic)
    
    params = amgcl_params_create()
    call amgcl_params_sets(params, "solver.type", "bicgstab")
    call amgcl_params_setf(params, "solver.tol", 1e-6)
    call amgcl_params_seti(params, "precond.max_levels", 8)
    
    solver = amgcl_solver_create(nall, ptr, col, val, params)
    call amgcl_solver_report(solver)
    cnv = amgcl_solver_solve(solver, rhs, x1)
    
    call amgcl_solver_destroy(solver)
    call amgcl_params_destroy(params)
    
    call cpu_time(toc)
    print *, 'AMGCL:', toc - tic
        
    call cpu_time(tic)
    call my_custom_solver(nall, nnz, ptr, col, val, x2, rhs)
    call cpu_time(toc)
    print *, 'CUSTOM:', toc - tic
    

    The outputs were as follows.

    Number of levels:    4
    Operator complexity: 1.60
    Grid complexity:     1.13
    Memory footprint:    1.42 G
    
    level     unknowns       nonzeros      memory
    ---------------------------------------------
        0      4194304       28803072      1.07 G (62.66%)
        1       524976       14754962    320.79 M (32.10%)
        2        37942        2355460     41.71 M ( 5.12%)
        3         1781          53649      3.65 M ( 0.12%)
    
    AMGCL:   57.421875000000000
    CUSTOM:  18.531250000000000
    

    I surprisingly found that my custom solver preformed much more better than BiCGStab solver. I wondered if the parameters were set properly in my code. Or perhaps this just meant the BiCGStab solver provided by Eigen consumed too much time? If so, will it be possible to couple my custom solver with the preconditioners?

    opened by Arsennnic 4
  • How to use mm to read more than one right hand side?

    How to use mm to read more than one right hand side?

    I feel very greatful for your patience and work. I wonder if I can use mm.hpp to read more than one right hand side like n * 2 or n * 3 in the format of matrix market. Queen_4147.txt dgreen.txt

    By the way, i want to use some "skills" to accelerate the convergence of amg as a standalone solver. Some questions bother me (having nothing to do with the code). 1.Why doesn't amg work alone(as a solver) usually? 2.Does amg deficient in stability or effience for most common problems compared with preconditioned Krylov subspace methods?(I got ambiguous understanding from literature) 3.I want to do some comparison tests, but for some problems the amg solver divergences, like https://sparse.tamu.edu/VLSI/dgreen https://sparse.tamu.edu/Janna/Queen_4147 form SuiteSparse. What i used are default parameters(coarsening:smoothed aggregation ,relax:spai0). I tried little changes but it still didn't work. What is your seggestion for the test ?(Maybe poisson problem ?)

    Sorry to bother you frequently.

    Best regards.

    GENG

    opened by g873249824 4
  • Building library for fortran user

    Building library for fortran user

    Dear, Denis!

    Can you please explain how to build library in order to use it in fortran code with mpi enabled? I am trying to build on macos 10.15, gcc compiler 10.2 and open-mpi 3.1. So far i got to

    cmake -DAMGCL_TEST_COVERAGE=${TEST_COVERAGE}
    -DAMGCL_BUILD_TESTS=ON
    -DAMGCL_BUILD_EXAMPLES=${BUILD_EXAMPLES} -DAMGCL_HAVE_FORTRAN=ON
    -DAMGCL_HAVE_PYTHON=${TEST_PYTHON}
    -DPYTHON_EXECUTABLE:FILEPATH=/usr/bin/python3 ..

    but it doest work.

    Scanning dependencies of target test_solver_complex [ 1%] Building CXX object tests/CMakeFiles/test_solver_complex.dir/test_solver_complex.cpp.o [ 2%] Linking CXX executable test_solver_complex Undefined symbols for architecture x86_64: "__ZN5boost9unit_test9ut_detail24normalize_test_case_nameB5cxx11ENS0_13basic_cstringIKcEE", referenced from: __GLOBAL__sub_I_test_solver_complex.cpp in test_solver_complex.cpp.o ld: symbol(s) not found for architecture x86_64 collect2: error: ld returned 1 exit status make[2]: *** [tests/CMakeFiles/test_solver_complex.dir/build.make:104: tests/test_solver_complex] Error 1 make[1]: *** [CMakeFiles/Makefile2:351: tests/CMakeFiles/test_solver_complex.dir/all] Error 2 make: *** [Makefile:160: all] Error 2

    Thanks!

    Best regards, Shatrov Oleg.

    opened by ShatrovOA 1
  • AMG for large scale heterogeneous FEM problems

    AMG for large scale heterogeneous FEM problems

    Dear Denis,

    I have had a good experience with AMGCL solver in KratosFramework for fluid and structural problems. Recently I have started testing AMG for heterogeneous problems where there are large jumps in material properties within the domain.

    I have been trying different settings that I used before but so far no success in convergence. I have tried combinations of smoothers, krylov solvers, coarsening types.

    Can you give me some hints and tips to use AMG for large scale heterogeneous problems which may suffer from saddle point issue ?

    opened by RezaNajian 2
  • Two-phase oil reservoir simulation

    Two-phase oil reservoir simulation

    Dear Denis,

    I suggest to continue the issue #168 in this topic, since the original issue seems to be more fundamental and is not really related to just Cutheel-mckee algorithm.

    I am implementing a scheme of numerical solution of the two-phase oil-reservoir model. The phases are oil and water. As a test case I consider the simplest system, both fluids are incompressible, densities and viscosities are fixed. No capillary pressure.

    I am using the Finite Volume Method for the partial differential equations discretization, and I am solving the problem in (s_water; pressure) variables using the Newton algorithm to linearize the algebraic problem. s_oil is simply s_oil = 1 - s_water.

    The particular problem that I report here is a 38x38 cells 2D square reservoir with two wells. The initial condition is s_oil_0 = 1, p_0 = -1. The boundary conditions are left and right sides are impermeable for liquids, the upper and lower bounds of the box are at fixed pressure, p = p_0 = -1. One well is is injection well and the other is a production well.

    The vector of unknows is composed as s_water for every cell followed by pressure for every cell. Thus a matrix with a 2x2 block structure is obtained as shown in figure sparseMatrixStructure

    The lower-right block contains some non-zero elements due to boundary condition which currently assume an inflow of water through the upper and lower boundaries of reservoir.

    The problem is that while using the AMGCL library, the linear system can be solved for the grids with the number of cells less than 39 in every direction. The finest allowed grid is of 38x38 cells, and the lower right block of the matrix contains 36 successive lines of zeros between the lines corresponding to the boundary conditions (with non-zero elements on the main diagonal).

    I am using the Eigen library and the RowMajor SparseMatrix class to store my matrix A

    typedef Eigen::SparseMatrix<double, RowMajor> SpMat;
    SpMat  A(2*N, 2*N);
    

    Then, I use the following code to interface with the AMGCL

    #include <amgcl/adapter/eigen.hpp>
    #include <amgcl/backend/builtin.hpp>
    #include <amgcl/make_solver.hpp>
    #include <amgcl/solver/gmres.hpp>
    #include <amgcl/amg.hpp>
    #include <amgcl/coarsening/smoothed_aggregation.hpp>
    #include <amgcl/relaxation/spai0.hpp>
    
    typedef amgcl::make_solver<
    	amgcl::amg<
    	amgcl::backend::builtin<double>,
    	amgcl::coarsening::smoothed_aggregation,
    	amgcl::relaxation::spai0
    	>,
    	amgcl::solver::gmres<amgcl::backend::builtin<double> >
    > Solver_AMG;
    
    Solver_AMG solve(A);
    int    iters;
    double error;
    std::tie(iters, error) = solve(b0, u_Next);
    

    For the number of grid cells more or equal to 39x39 I obtain the following error

    Unhandled exception at 0x00007FFE31883E49 in OilReservoir_Eigen.exe: Microsoft C++ exception: std::runtime_error at memory location 0x0000002F1D0FE908. occurred
    

    image

    Pressing F5 in Visual Studio 2019, I get this with D of all zeros (715 elements total)

    OilReservoir_Eigen.exe has triggered a breakpoint. occurred
    

    image

    So, my concerns are as follows. I appreciate if you could kindly comment on them.

    1. The Eigen library implements SparseLU direct solver that solves the problem for any grid sizes. And the solution is physically reasonable. So, I do not prone to believe that the issue is "This looks like a memory error somewhere in your program", as you suggested in issue #168.

    2. I do not think that the Schur pressure correction approach is (physically) justified approach in this case. Consider the reservoir with s_oil = s_water = 0.5 in every cell and uniform pressure. Then, the two lines of blocks would be equivalent, so I cannot simply disregard the non-zeros in the lower right block of matrix in the iterative solver.

    3. Should I reorder the vector of unknows so that every two successive lines in the matrix are related to the same grid cell, but represent two equations, one for every phase. Then I could say that the matrix contains NxN cells (N - totl number of cells in the grid), where every cell is a 2x2 block. Thus, every grid cell is described by a 2x2 "tensor". Then, I could use the option amgcl::static_matrix<2,2,double> to initialize the amg solver?

    4. Does the implemented backend for Eigen support the Eigen::SparseMatrix<double, RowMajor> simultaneously with amgcl::static_matrix<2,2,double>?

    opened by ArturSalamatin 32
  • Cuthill-McKee matrix reorder algorithm with with Eigen::SparseMatrix

    Cuthill-McKee matrix reorder algorithm with with Eigen::SparseMatrix

    Dear Denis,

    would you be so kind to provide an example of how to use the Cuthill-McKee matrix reorder algorithm with Eigen::SparseMatrix<double, RowMajor>?

    Thank you in advance!

    opened by ArturSalamatin 7
Releases(1.4.0)
  • 1.4.0(Nov 26, 2020)

    • The codebase uses C++11 standard.
    • amgcl::mpi::amg preconditioner is implemented! This works much better than subdomain deflation which is now considered deprecated. See examples/mpi/mpi_amg.cpp and some benchmarks in https://doi.org/10.1134/S1995080219050056 (https://arxiv.org/abs/1811.05704).
    • Added wrappers for Scotch and ParMetis partitioning libraries.
    • Runtime interface has been refactored. Instead of doing
      typedef amgcl::make_solver<
          amgcl::runtime::amg<Backend>,
          amgcl::runtime::iterative_solver<Backend>
          > Solver;
      

      one should now

      typedef amgcl::make_solver<
          amgcl::amg<
              Backend,
              amgcl::runtime::coarsening::wrapper,
              amgcl::runtime::relaxation::wrapper
              >,
          amgcl::runtime::solver::wrapper<Backend>
          > Solver;
      

      This allows to reuse the same amgcl::amg implementation both for compile-time and runtime interfaces and greatly reduces compilation time and memory requirements for the library.

    • Got rid of as many Boost dependencies as possible in favor of C++11. Currently, only the runtime interface depends on Boost , as it uses boost::property_tree::ptree for defining runtime parameters. It should be possible to use the compile-time interface completely Boost-free. This also means that one should replace all uses of boost::tie and boost::make_tuple in amgcl-related code with std::tie and std::make_tuple. For example:
      Solver solve(std::tie(n, ptr, col, val));
      std::tie(iters, error) = solve(f, x);
      
    • Provide amgcl::backend::bytes() function that returns (sometimes approximately) the amount of memory allocated for an amgcl object. std::string amgcl::backend::human_readable_memory(size_t) converts bytes to a human-readable size string (e.g. 1024 is converted to 1 K).
    • Support for mixed-precision computations (where iterative solver and preconditioner use different precisions).
    • MPI versions of CPR preconditioners. Support for statically-sized matrices in global preconditioners of CPR. Support for mixed-precision in global and pressure-specific parts of CPR.
    • Helper functions for the computation of rigid body modes (for use as near null space vectors in structural problems) from 2D or 3D coordinates.
    • Improvements for the Schur pressure correction preconditioner.
    • Added Richardson and PreOnly (only apply the preconditioner once) iterative solvers. The latter is intended for use as a nested solver in composite preconditioners, such as Schur pressure correction.
    • epetra_map was moved to the adapter namespace.
    • Eigen backend was split into adapter and backend part.
    • amgcl::make_scaling_solver has been replaced with amgcl::scaled_problem adapter.
    • Added tutorials to the documentation.
    • Many bug fixes and minor improvements.
    Source code(tar.gz)
    Source code(zip)
  • 1.3.99(Nov 9, 2019)

    • The code base uses C++11 standard.
    • amgcl::mpi::amg preconditioner is implemented! This works much better than subdomain deflation which is now considered deprecated. See examples/mpi/mpi_amg.cpp and some benchmarks in https://doi.org/10.1134/S1995080219050056 (https://arxiv.org/abs/1811.05704).
    • Added wrappers for Scotch and ParMetis partitioning libraries.
    • Runtime interface has been refactored. Instead of doing
      typedef amgcl::make_solver<
          amgcl::runtime::amg<Backend>,
          amgcl::runtime::iterative_solver<Backend>
          > Solver;
      

      one should now

      typedef amgcl::make_solver<
          amgcl::amg<
              Backend,
              amgcl::runtime::coarsening::wrapper,
              amgcl::runtime::relaxation::wrapper
              >,
          amgcl::runtime::solver::wrapper<Backend>
          > Solver;
      

      This allows to reuse the same amgcl::amg implementation both for compile-time and runtime interfaces, and greately reduces compilation time and memory requirements for the library.

    • Got rid of as many Boost dependencies as possible in favor of C++11. Currently , only the runtime interface depends on Boost , as it uses boost::property_tree::ptree for defining runtime parameters. It should be possible to use the compile-time interface completely Boost-free. This also means that one should replace all uses of boost::tie and boost::make_tuple in amgcl-related code with std::tie and std::make_tuple. For example:
      Solver solve(std::tie(n, ptr, col, val));
      std::tie(iters, error) = solve(f, x);
      
    • Provide amgcl::backend::bytes() function that returns (sometimes approximately) the amount of memory allocated for an amgcl object. std::string amgcl::backend::human_readable_memory(size_t) converts bytes to a human-readable size string (e.g. 1024 is converted to 1 K).
    • Initial support for mixed-precision computations (where iterative solver and preconditioner use different precisions).
    • MPI versions of CPR preconditioners. Support for statically-sized matrices in global preconditioners of CPR. Support for mixed precision in global and pressure-specific parts of CPR.
    • epetra_map was moved to adapter namespace.
    • Eigen backend was split into adapter and backend part.
    • amgcl::make_scaling_solver has been replaced with amgcl::scaled_problem adapter.

    This is marked as pre-release, because the documentation still needs to be updated.

    Source code(tar.gz)
    Source code(zip)
  • 1.2.0(May 10, 2018)

    • Change default value of smoothed_aggregation.aggr.eps_strong from 0 to 0.08. This should work better for anisotropic cases.
    • Pressure mask may be set with a pattern in Schur pressure correction preconditioner.
    • When using async_setup, allow to exit initialization thread early in case the solution has already converged.
    • Stable implementation of inner product in OpenMP backend. This makes the solution deterministic for a fixed number of OpenMP threads.
    • Support non-zero initial condition in BiCGStab(L).
    • Switch implementation of BiCGStab(L) to Fokkema's version [1].
    • Support both left and right preconditioning in BiCGStab, BiCGStab(L), GMGES, CG.
    • Improve performance/scalability of mpi::subdomain_deflation.
    • Minor bug fixes and improvements.

    [1] Fokkema, Diederik R. Enhanced implementation of BiCGstab (l) for solving linear systems of equations. Universiteit Utrecht. Mathematisch Instituut, 1996.

    Source code(tar.gz)
    Source code(zip)
    amgcl-docs-1.2.tgz(9.90 MB)
  • 1.1.0(Oct 21, 2017)

    • Improve profiling: allow users to configure profiling operations.
    • Implement adapter::reorder for matrices and vectors. Allows to transparently apply Cuthill-McKee reordering to the system matrix and RHS before solution.
    • Improve performance of Schur pressure correction preconditioner by (optionally) approximating inverse of Kuu matrix with its inverted diagonal.
    • Use power iteration to estimate spectral radius in smoothed_aggregation. This improves convergence rate at the cost of setup time. The total time is usually improved, but may suffer on GPGPU backends.
    • Adding IDR(s) iterative solver (http://ta.twi.tudelft.nl/nw/users/gijzen/IDR.html).
    • Improve performance and scalability of mpi::subdomain_deflation preconditioner.
    • Support matrix-free solution with mpi::subdomain_deflation.
    • Provide amgcl::put(ptree p, string s) where s has key=value format. This makes parsing of command line parameters easier.
    • Add shared and distributed memory benchmarks to the documentation.
    • Add Clang and OSX tests on Travis-CI.
    • Minor bug fixes and improvements.
    Source code(tar.gz)
    Source code(zip)
  • 1.0.0(May 16, 2017)

    • Implemented OpenMP versions of incomplete LU smoothers (ilu0, iluk, ilut), and got rid of now obsolete parallel_ilu0 smoother. Parallel algorithm is based on level scheduling approach and is automatically selected when there are four or more OpenMP threads.
    • Reimplemented multicolor Gauss-Seidel smoother, merged the new implementation with gauss_seidel, and got rid of obsolete multicolor_gauss_seidel smoother. Parallel algorithm is based on level scheduling approach and is automatically selected when there are four or more OpenMP threads.
    • Code cleanup, minor improvements and bug fixes.
    Source code(tar.gz)
    Source code(zip)
  • 0.9.1(May 4, 2017)

    Mostly a bug fix release.

    • Fixed a bug in matrix-matrix product.
    • Allow to disable selected components from runtime interface to reduce compilation overhead (see #45).
    Source code(tar.gz)
    Source code(zip)
  • 0.9.0(May 3, 2017)

    • Use NUMA-friendly internal data structures. This shows measurable speed-up on NUMA systems.
    • Allow asynchronous amg setup. amgcl::amg constructor starts the setup process in a new thread. As soon as constructor returns, the instance is ready to be used as a preconditioner. Initially its just a single-level smoother, but when as the new (coarser) levels are constructed, they are put to use. In case of GPGPU backends, this should allow to overlap work between host CPU doing setup and the compute device doing the solution. In some cases a 2x speedup of the overall solution has been achieved.
    • Allow limiting number of amg levels, thus supporting using relaxation for coarse solves.
    • Rewrite lgmres and fgmres in terms of Givens rotations, which should work better with complex problems, see #34.
    • Use new, more effective, sparse matrix format in VexCL backend and allow to use non-scalar values with the backend.
    • Modernize cmake scripts. Provide amgcl::amgcl imported target, so that users may just
      find_package(amgcl)
      add_executable(myprogram myprogram.cpp)
      target_link_libraries(myprogram amgcl::amgcl)
      

      to build a program using amgcl. The imported target brings necessary compile and link options automatically.

    • Replace boost.python with pybind11 and improve python interface.
    • Unify example codes for different backends.
    • Minor improvements and bug fixes
    Source code(tar.gz)
    Source code(zip)
  • 0.8.1(Aug 12, 2016)

    • Implemented LGMRES solver ("Loose" GMRES, [BaJM05]).
    • Implemented FGMRES solver (Flexible GMRES, [Saad03]).
    • GMRES uses real residual instead of preconditioned one in termination condition.
    • Performance improvements in components using QR decomposition (spai1, aggregation with null-space provided).
    • Provided python examples.
    • Minor bug fixes and improvements.
    Source code(tar.gz)
    Source code(zip)
  • 0.8.0(Jul 6, 2016)

    • Updated two-stage preconditioners
      • Replaced SIMPLE preconditioner with Schur complement pressure correction.
      • Implemented MPI version of Schur complement pressure correction preconditioner.
      • Made CPR preconditioner actually work.
    • Breaking changes
      • Renamed amgcl/amgcl.hpp -> amgcl/amg.hpp
    • Added support for complex and non-scalar values for coefficients/unknowns.
    • Implemented ILU(k) smoother/preconditioner.
    • Added MPI block-preconditioner wrapper.
    • Introduced mpi::make_solver.
    • Allow using make_solver as preconditioner.
    • Improve Matrix-Matrix product performance for many-cored CPUs.
    • Provide MatrixMarket format I/O functions.
    • Generalize profiler class, provide a couple of custom performance counters.
    • Improve coarse solution performance on GPGPU backends.
    • Allow checking for consistency of runtime parameters.
    • Move documentation to http://amgcl.readthedocs.org.
    • Various bugfixes and improvements.
    Source code(tar.gz)
    Source code(zip)
  • 0.7.0(Nov 19, 2015)

    This is rather big and an API breaking release!

    • All runtime parameters (namely, coarsening type, relaxation type, and solver type) were moved to the generic parameter structure (stored in boost::property_tree). So the following code:
    boost::property_tree::ptree prm;
    typedef amgcl::runtime::make_solver< amgcl::backend::builtin<double> > Solver;
    Solver S(amgcl::runtime::coarsening::smoothed_aggregation,
         amgcl::runtime::relaxation::spai0,
         amgcl::runtime::solver::bicgstab,
         A, prm);
    

    would have to be changed to

    boost::property_tree::ptree prm;
    typedef amgcl::runtime::make_solver< amgcl::backend::builtin<double> > Solver;
    prm.put("precond.coarsening.type", amgcl::runtime::coarsening::smoothed_aggregation);
    prm.put("precond.relaxation.type", amgcl::runtime::relaxation::spai0);
    prm.put("solver.type",     amgcl::runtime::solver::bicgstab);
    Solver S(A, prm);
    

    This is done as part of the effort to generalize use of preconditioners in the library, so that any preconditioner supported by AMGCL could be uniformly constructed with the system matrix and the parameters.

    • amg::top_matrix() method was renamed to amg::system_matrix() for the same reason.

    • The use of preconditioners in AMGCL was generalized. A class that may be used as a preconditioner should have the following properties:

      • Provide public type backend_type for its backend.
      • Provide public type params containing its parameters.
      • Have constructor that takes three arguments:
      • System matrix
      • Parameters
      • Backend parameters
      • Export the system matrix in the backend format through system_matrix() method.

      A preconditioner may be used in the following contexts:

      • As a parameter to an iterative solver.
      • As a template parameter to make_solver class.
      • As a template parameter to a two-step preconditioner (CPR and SIMPLE).
      • As a template parameter to subdomain deflation class (as a local preconditioner).
    • Added amgcl::as_preconditioner<Backend, Relaxation> and amgcl::runtime::as_preconditioner<Backend> wrapper classes that allow to use smoothers as preconditioners.

    • Added ILUT(p,tau) smoother/preconditioner.

    • Implemented Chow and Patel version of parallel ILU. This allowed to enable ILU-type smoothers on all backends, but may not work as well as serial version for some problems.

    • Provided a wrapper for cuSPARSE implementation of ILU0 on CUDA backend.

    • Added adapter for complex-valued matrices. This uses an equivalent real formulation (ERF) for the matrix so that it may be solved with AMGCL.

    • Added zero copy matrix adapter for CRS matrices. The adapter allows to skip copy and thus save some memory for matrices that are binary compatible with internal AMGCL storage. Basically, that means that row pointer and column number arrays should be either signed or unsigned ptrdiff_t.

    • Provided wrapper interface for Fortran.

    Source code(tar.gz)
    Source code(zip)
  • 0.6.4(Nov 19, 2015)

    This is the last release before API-breaking 0.7.0

    • Implemented two-step preconditioners for Navier-Stokes type problems (CPR and SIMPLE).
    • Implemented multicolor Gauss-Seidel smoother
    • Get rid of mandatory dependence on std::chrono
    • Bug fixes and minor improvements
    Source code(tar.gz)
    Source code(zip)
  • 0.6.3(Mar 11, 2015)

    • Use norm of right-hand side instead of initial error for scaling residuals in iterative solvers. This yields consistent results when starting with a decent initial approximation.
    • Provide an HPX backend.
    • Accept near null-space vectors for aggregation-based coarsening.
    • Added SPAI(1) smoother (may work better than SPAI(0), but is extremely slow to setup for larger problems).
    • Iterative solvers now provide apply() methods, so that they may be used as preconditioners themselves.
    • Various fixes and improvements.
    Source code(tar.gz)
    Source code(zip)
  • 0.6.2(Nov 29, 2014)

    • Added adapter for ublas types. Provides amgcl::backend::map() for ublas::compressed_matrix and allows to use ublas vectors with builtin backend.
    • Moved make_solver parameters into single params struct This is an API breaking change! This unifies treatment of amg and solver params in amgcl::make_solver, amgcl::runtime::make_solver, and amgcl::mpi::subdmain_deflation classes. Now, whenever a class contains both an amg hierarchy and an iterative solver, the amg parameters may be accessed through the class params::amg, and the solver parameters -- through params::solver.
    • Fixed pyamgcl for use with python3 and arch linux.
    Source code(tar.gz)
    Source code(zip)
  • 0.6.1(Oct 7, 2014)

  • 0.6.0(Sep 27, 2014)

    This is a rather big release with lots of new features.

    • Added crs_builder backend. The backend is similar to crs_tuple in the sense that it is only used for initialization of AMG hierarchy. The difference is that crs_builder does not need fully constructed matrix in CRS format (which would be copied into AMG anyway), but builds matrix rows as needed. This results in reduced memory requirements.
    • Implemented MPI solver with subdomain deflation in collaboration with @RiccardoRossi. The method allows solution on parallel machines with distributed memory and has very good scalability.
    • Implemented BiCGStab(L) iterative solver.
    • Added an adapter for Epetra_CrsMatrix from Trilinos project.
    • Added SkylineLU sparse direct solver. This allows for larger coarse levels in builtin backend, which improves convergence and solve time. Again, thanks to @RiccardoRossi for help.
    • Added classes in amgcl::runtime namespace that allow for runtime configuration of multigrid template parameters. This makes AMGCL easy to use in 3rd party libraries/applications.
    • Provided Delphi wrapper for AMGCL.
    • Provided python wrapper for AMGCL. May be installed by pip install pyamgcl
    • New tests and examples
    • Various improvements and bug fixes.
    Source code(tar.gz)
    Source code(zip)
  • 0.5.0(Jun 13, 2014)

    This is a major change in the library interface and implementation. The code base has been rewritten from scratch to decouple various components of the AMG method, such as backends, coarseners, smoothers, and iterative solvers.

    This makes extending the library much easier. See the README for more information.

    Source code(tar.gz)
    Source code(zip)
  • 0.3.2(Jun 13, 2014)

    The main purpose of this release is to make a snapshot of the current library API before switching to v2 branch.

    Some changes that were made since the last release:

    • Added Blaze library backend (https://code.google.com/p/blaze-lib)
    • Use Kahan summation in implementation of inner_product for the VexCL backend
    • Bug fixes and minor changes
    Source code(tar.gz)
    Source code(zip)
  • 0.3.1(Apr 15, 2014)

The Universal Storage Engine

The Universal Storage Engine TileDB is a powerful engine for storing and accessing dense and sparse multi-dimensional arrays, which can help you model

TileDB, Inc. 1.1k Jun 14, 2021
C++ implementation of the Python Numpy library

NumCpp: A Templatized Header Only C++ Implementation of the Python NumPy Library

David Pilger 1.7k Jun 12, 2021
http://torch.ch

Development Status Torch is not in active developement. The functionality provided by the C backend of Torch, which are the TH, THNN, THC, THCUNN libr

Torch 8.6k Jun 11, 2021
Primary repository for the Trilinos Project

Trilinos Website | Documentation | Mailing List | Packages The Trilinos Project is an effort to develop algorithms and enabling technologies within an

Trilinos 640 Jun 14, 2021