Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a uniform coarse generation algorithm #1526

Open
wants to merge 10 commits into
base: develop
Choose a base branch
from

Conversation

pratikvn
Copy link
Member

@pratikvn pratikvn commented Jan 13, 2024

This PR is an updated version of #979 . The idea is to have a very cheap coarse grid generation algorithm that works well for matrices that are uniform, for example, matrices that arise from stencils on structured grids.

For example, for a 7 point stencil on a 3D grid, it is very competitive to PGM (with_deterministic=false) with much faster generation and faster apply for larger problems (on OMP executor with 8 cores):

unif_pgm

@pratikvn pratikvn added is:new-feature A request or implementation of a feature that does not exist yet. 1:ST:ready-for-review This PR is ready for review type:multigrid This is related to multigrid labels Jan 13, 2024
@pratikvn pratikvn requested review from a team January 13, 2024 01:06
@pratikvn pratikvn self-assigned this Jan 13, 2024
@ginkgo-bot ginkgo-bot added reg:build This is related to the build system. reg:testing This is related to testing. mod:core This is related to the core module. mod:cuda This is related to the CUDA module. mod:reference This is related to the reference module. reg:example This is related to the examples. mod:hip This is related to the HIP module. labels Jan 13, 2024
Copy link

Quality Gate Passed Quality Gate passed

The SonarCloud Quality Gate passed, but some issues were introduced.

44 New issues
1 Security Hotspot
66.4% Coverage on New Code
2.0% Duplication on New Code

See analysis details on SonarCloud

Copy link

codecov bot commented Jan 13, 2024

Codecov Report

Attention: Patch coverage is 97.64310% with 7 lines in your changes are missing coverage. Please review.

Project coverage is 89.78%. Comparing base (fb70ec0) to head (0537b1e).
Report is 232 commits behind head on develop.

❗ Current head 0537b1e differs from pull request most recent head 915e227. Consider uploading reports for the commit 915e227 to get more accurate results

Files Patch % Lines
...ence/test/multigrid/uniform_coarsening_kernels.cpp 96.32% 5 Missing ⚠️
core/device_hooks/common_kernels.inc.cpp 0.00% 2 Missing ⚠️
Additional details and impacted files
@@             Coverage Diff             @@
##           develop    #1526      +/-   ##
===========================================
- Coverage    91.04%   89.78%   -1.27%     
===========================================
  Files          700      707       +7     
  Lines        56996    57487     +491     
===========================================
- Hits         51894    51612     -282     
- Misses        5102     5875     +773     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@upsj
Copy link
Member

upsj commented Jan 19, 2024

Especially focusing on distributed, I think if we include this, we should try to support at least 2D and maybe 3D coarsening (i + n * j and i + n * j + k * n * m).

@MarcelKoch MarcelKoch self-requested a review January 19, 2024 15:13
@MarcelKoch
Copy link
Member

Maybe it makes sense to split the UniformCoarsening class up. The generated object essentially stores an array with coarse row indices, so it seems natural to allow users to pass in these indices. But I don't think we can add a parameter to the existing class, since then there would be two mutually exclusive parameters.
I think Tobias' approach for the direct solvers, i.e. having multiple factories that generate the same class makes sense here.

Copy link
Member

@MarcelKoch MarcelKoch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As I mentioned, I think the UniformCoarsening class should be split up. Other than that I have mostly smaller comments.

parameters_.coarse_skip, &coarse_rows_));

gko::dim<2>::dimension_type coarse_dim =
(coarse_rows_.get_size() + parameters_.coarse_skip - 1) /
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ceildiv

.with_criteria(iter_stop, tol_stop)
.on(exec));
if (coarse_type == std::string("uniform")) {
std::cout << "Using Uniform coarsening" << std::endl;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think the output is necessary, since that information is already part of the program arguments.

.on(exec));
if (coarse_type == std::string("uniform")) {
std::cout << "Using Uniform coarsening" << std::endl;
multigrid_gen = gko::share(mg::build()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it shouldn't generate the MG twice.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This just builds the factories, no actual generation is done.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

doesn't really matter, it's unnecessary duplication.

tol_stop->add_logger(logger);

// Create smoother factory (ir with bj)
auto inner_solver_gen =
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is it necessary to introduce these intermediate factories again. I refactored this example to be as minimal as possible.

namespace kernels {
namespace reference {
/**
* @brief The UNIFORM_COARSENING solver namespace.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think these comments are useful.

}
}

static void assert_same_coarse_rows(const index_type* m1,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same but for array.

PairTypenameNameGenerator);


TYPED_TEST(UniformCoarsening, CanBeCopied)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aren't copy/move/clone/clear generally core tests?

TYPED_TEST(UniformCoarsening, CanBeCopied)
{
using Mtx = typename TestFixture::Mtx;
using MgLevel = typename TestFixture::MgLevel;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

unused (and in the other tests)

* @ingroup LinOp
*/
template <typename ValueType = default_precision, typename IndexType = int32>
class UniformCoarsening
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this define copy/move assignment/constructors? The default ones are not completely inline with our normal understanding of those.

Comment on lines +282 to +260
gko::kernels::reference::uniform_coarsening::fill_incremental_indices(
this->exec, 2, &c_rows);
GKO_ASSERT_ARRAY_EQ(c_rows, c2_rows);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

range-based for loop?

@upsj upsj requested review from upsj and greole February 7, 2024 09:46
@MarcelKoch MarcelKoch added this to the Ginkgo 1.8.0 milestone Apr 5, 2024
@pratikvn pratikvn force-pushed the uniform-coarsening branch from 903a8a5 to 915e227 Compare April 26, 2024 13:01
Copy link

@pratikvn pratikvn removed this from the Ginkgo 1.8.0 milestone May 3, 2024
@tcojean tcojean added this to the Ginkgo 1.9.0 milestone May 3, 2024
@pratikvn pratikvn force-pushed the uniform-coarsening branch from 915e227 to 2f5525a Compare June 25, 2024 11:38
@pratikvn pratikvn removed the 1:ST:ready-for-review This PR is ready for review label Jun 26, 2024
@pratikvn pratikvn added the 1:ST:WIP This PR is a work in progress. Not ready for review. label Jun 26, 2024
@pratikvn pratikvn force-pushed the uniform-coarsening branch 2 times, most recently from c6939ee to e77eef8 Compare July 4, 2024 10:44
@pratikvn pratikvn force-pushed the uniform-coarsening branch from e77eef8 to 185f551 Compare July 4, 2024 11:55
@pratikvn
Copy link
Member Author

pratikvn commented Jul 4, 2024

@upsj, After a bit of thought, I think this class should not represent Geometric/Structured coarsening. Uniform coarsening is just a cheap coarsening method that just uniformly discards rows and columns to construct the coarse matrix, and hence is not suitable for Geometric coarsening, which needs to create connections between the coarse nodes.

@MarcelKoch , we already provide the users with a way to specify custom indices for coarsening with the FixedCoarsening class

@upsj
Copy link
Member

upsj commented Jul 4, 2024

@pratikvn If we discard variables for restriction, we still need to interpolate new values for prolongation, so I don't yet see how this makes multi-dimensional coarsening impossible if 1D coarsening is possible?

@pratikvn
Copy link
Member Author

pratikvn commented Jul 4, 2024

In a similar fashion to PGM, the prolongation matrix will be a transpose of the restriction matrix. I think maybe I have given a wrong impression that this would be a 1D coarsening. The fine level vectors will not have extrapolated values, but just "mapped" values.

@upsj
Copy link
Member

upsj commented Jul 4, 2024

Doesn't PGM do the same thing? And I believe we are mixing two things here - coarsening and interpolation. One is structural, one concerns the actual numerical values.

@pratikvn
Copy link
Member Author

Just adding more performance results on a 7pt stencil and some chosen matrices from Suitesparse, to show that this type of coarsening can help in certain cases.

Apply speedup for cage15 (v/s PGM) matrix and bcsstm39 matrix (v/s no preconditioning)

speedup_app_ss_bicgstab_cskip.pdf

Apply speedup for 7pt stencil (v/s PGM)

speedup_app_7pt_cg_cskip.pdf

Generate speedup for 7pt stencil (v/s PGM)

speedup_gen_7pt_cg_cskip.pdf

@upsj
Copy link
Member

upsj commented Jul 17, 2024

I don't think these results matter, since even for simple stencils, the matrix loses all connectivity:

Take the poisson-solver example and plug in the following code:

    auto gen = gko::multigrid::UniformCoarsening<ValueType, IndexType>::build().on(app_exec)->generate(matrix->clone());
    gko::write(std::cout, matrix);
    gko::write(std::cout, gko::as<mtx>(gen->get_composition()->get_operators()[1]));

The fine matrix is tridiagonal, but the coarse matrix is just a diagonal matrix.

@upsj
Copy link
Member

upsj commented Oct 18, 2024

I don't see this PR being useful in its current state. IMO we should either turn it into a regular coarsening algorithm, or abandon it.

@MarcelKoch MarcelKoch modified the milestones: Ginkgo 1.9.0, Ginkgo 1.10.0 Dec 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1:ST:WIP This PR is a work in progress. Not ready for review. is:new-feature A request or implementation of a feature that does not exist yet. mod:core This is related to the core module. mod:cuda This is related to the CUDA module. mod:hip This is related to the HIP module. mod:reference This is related to the reference module. reg:build This is related to the build system. reg:example This is related to the examples. reg:testing This is related to testing. type:multigrid This is related to multigrid
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants