Multigrid CoarseFine structure

[yhmtsai]

In #528, I implement the CoarseFine class inherit LinOp and AmgxPgm with LinOpFactory.

1. Should I add a class similar with LinOp/LinOpFactory to remove the confusion between solver and coarsefine?
   I would like to add the Multigrid solver which user can select different CoarseFine behaviour mostly like the inner solver of IR.

multigrid.build()
    .with_coarsefine(coarsefine_factory)
    .with_coarsest_solver(solver_factory)

currently, I need to use gko::as<CoarseFine> to check whether the output from coarsefine_factory->generate is CoarseFine or other LinOp.
Adding similar class may gives a lot of copy-paste.

2. using the AmgxPgmOp or dynamic_cast<matrix_format>
   Is the matrix-dependent function of amgxpgm under AmgxPgm or matrix_format?

• under matrix_format -> gko::as<AmgxPgmOp> (current)
• under AmgxPgm -> using dynamic_cast<matrix_format> (like csr apply) and implement the kernel under AmgxPgm.

This does not affect the implementation of kernels but the place of implementation and test.

[upsj]

1: Building a separate CoarseningFactory seems more sensible to me. You should still be able to reuse all the PARAMETER and ENABLE_BUILD_METHOD macros, as they don't specify the factory type, right?
CoarseFine seems to me like a good abstraction for all types of multigrid methods, and using a general LinOp would trade a bit of type safety for almost no benefit.

2: I would keep this separate from the Csr format, since the class is already pretty packed with functionality, and this would not really scale when we decide to add other multigrid types.
Of course Csr is the only format that allows you to easily implement algorithms like the edge matching for AMGX, but that is true for several algorithms that don't live inside Csr.

[pratikvn]

1. I also agree that building a separate CoarseningFactory would be better. I would also probably name it RestrictProlongateFactory, because that is what the factory would be responsible for, generating and providing apply methods for the restriction and prolongation operators.

Another question, does it make sense to tie the Restriction and Prolongation operators together ? Would there be any case for generating the restriction and prolongation operators separately (using different algorithms) ?

2. I would also keep this out of the CSR class as it is not something that the CSR class should be responsible for.

[Slaedr]

In geometric multigrid it's relatively common to use different restriction and prolongation operators. I guess it's less common in algebraic multigrid, but it might be nice to keep them separate.

[yhmtsai]

Conclusion: We decide to use (CoarseFine) MultigridLevel and its components as ginkgo's LinOp, an interface (MultigridLevel) and default implementation with composition (EnableMultigridLevel<ValueType>). to make the balance between the flexibility and multigrid solver implementation.

Each MultigridLevel is composed of prolong, coarse, restrict operator and all operators are LinOp.
MultigridLevel(fine_op) = prolong x coarse x restrict
the coarse operator will be the fine operator of next MultigridLevel.
Although there are some additional works which need to add, users can use MultigridLevel's components, combination or composition to build it own Multigrid scheme.
The related PR: #528

I close this issue now.
Feel free to reopen it if anyone would like to have some discussion on it.