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

P4est code migrations and restructuring (04/10/22 meeting) #1

Closed
10 of 11 tasks
JordiManyer opened this issue Oct 4, 2022 · 0 comments
Closed
10 of 11 tasks

P4est code migrations and restructuring (04/10/22 meeting) #1

JordiManyer opened this issue Oct 4, 2022 · 0 comments
Assignees

Comments

@JordiManyer
Copy link
Member

JordiManyer commented Oct 4, 2022

  • Move RedistributeGlue to GridapDistributed.jl. Also, we should check if it can re-use some of the code already present for PartitionedArrays.Exchanger (by extending this type).
  • Create a new abstract type for distributed models (for instance AbstractDistributedDiscreteModel) with a common api that can be reused by different types of models. Both DistributedDiscreteModel and OctreeDistributedDiscreteModel should implement this api. Try to see where we can already re-use code.
  • Move ModelHierarchy to GridapSolvers.jl. We agreed that this makes sense since only multi-level solvers will require the use of hierarchical meshes. We also need to generalize this type (which is currently hard-coded for OctreeDistributedDiscreteModel).
  • Move the inter-grid projection routines to Gridap.jl. The logic is that these routines would be useful for serial implementations of h-AMR amongst other things. We need to create an abstraction layer which provides freedom in the choice of projection. Our current routines should implement an instance of this abstract api for L2-projection.
  • Using the new inter-grid projection capabilities, re-do and move our current inter-grid routines (projection+redist) to GridapSolvers.jl alongside ModelHierarchy.
  • Move GMG to GridapSolvers.jl.
  • We did not discuss this, but it seems quite logical: Move PatchBasedSmoothers to GridapSolvers.jl.

After this, the idea is that GridapP4est.jl should implement a specific refinement and redistribution engine that couples to GridapDistributed.jl. Only the routines related to this should actually stay in the repo.

Other features that might be interesting to have/explore

  • Now we are constrained to one mesh level to be defined as a single level of refinement from the previous one. We may have more aggressive coarsening ratios with practical scenarios in mind.
  • Is it possible to compose Refinement and Redistribution as a single step?

Questions arising when doing the migrations

  • Can some of the functions in GridapP4est.jl/src/RedistributeTools.jl be moved to GridapDistributed.jl along with RedistributeGlue? Can some of these functions be rewritten using PartitionedArrays.Exchanger methods?
  • Should we also wrap the PartitionedArrays.async_exchange() routines for RedistributeGlue?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants