Remarks

[dubosipsl]

@pvthinker I have the following remarks:

• the package itself should not depend on LoopManagers, only on ManagedLoops. If LoopManagers is used for tests, this dependency can be added to a Project.toml in the test/ subdirectory
• when using a package, explicitly use only the needed symbols. This makes it easier to check what comes from where.
• struct Param is mutable: I am not sure there is a strong advantage to this. Immutable structs are generally preferred. When a struct is immutable, we can be sure that it is properly initialized and functional.
• for extensibilty, it would be better to let param.cycle and param.operator be functions rather than symbols. For type stability their type should appear as type parameters for Param.
• similarly param.location could be an object rather than a symbol. Then functions restriction_XXX! would be replaced by a function restrict! taking this object as input argument, and dispatching on its type
• Separate the solver itself from the current state of the iteration Gmg.data ?
• Leave the creation of the arrays Data.x ... to the user ? For instance the arrays could be of some exotic type. Maybe pass an extra argument to the Data constructor, and let the array type (currently Array{Float64, 3} be a type parameter of Data.
• not sure what type Level adds

[pvthinker]

@dubosipsl Thank you Thomas for the feed-backs. Before including your propositions, let me comment/answer

1. [LoopManagers] : sure!
2. [using] : yes!
3. [Param] : ahah, some of the fields should clearly be immutable = the ones pertaining to the structure or the problem (e.g. location, operator, nx, ny, nz etc) but other mutable = the ones pertaining to optimizing (tol, maxite, cycle, omega, npre, npost). In particular, omega should be optimized for each problem. I've to commit this little tuning function, very useful as it impacts quite a lot the convergence rate.
4. [location] : yes in principle but in practice I only see an ugly solution: the location should then be passed as an argument in the restriction/prolongation call. This would make the calls uglier. I'm sure you've an elegant solution.
5. [Gmg.data] : I don't understand this remark. I like to have all the multigrid in one struct "Gmg"
6. [leaving data.x to the user] and data.b also (only for the 1st level). Yes, sure! it was already on my todo list. I see it as an another API to solve!().
7. [type Level] : good point, so far nothing. I'll probably remove it.