Let me take a shot at this, * Using my nomenclature, you want a forest (unstructured coarse grid) of, I guess tri-trees in 2D and quad-trees in 3D. Or a non-conforming AMR grid with simplices. * We have support for quad/oct trees, tensor grids, (p4est) and single level tensor, Cartesian grids, but no 60/120 degree grids. * It sounds like you do your own AMR and want to use PETSc for solvers. In that case I can only see using an unstructured (CSR) matrix with constraints added for "hanging" nodes. And then use AMG solvers. * Developing your own MG solvers a doable, but its a big project. Like a Ph.D. dissertation. Our team members have done this but I don't think any of these solvers are in the library. * We do have a p4est mesh class, Forest, that deals with the mesh management of these forest of oct-trees, but I don't believe we have mesh coarsening for this. * About 6 years ago the p4est developer told me he was working on your kind of simplex forest of trees, but I don't know how that progressed and PETSc does not have an interface to it anyway.
Thanks, Mark On Tue, Feb 8, 2022 at 9:29 AM Nadimy, Amin <[email protected]> wrote: > Dear Sir/Madam, > > > We are developing a semi-structured code based on a triangular mesh. It > has similarities to Adaptive Mesh refinement (AMR) in which from an initial > mesh (in our case unstructured) a structured mesh is generated based on a > refine-by-splitting strategy, ending up, like in AMR, with a > semi-structured mesh. > > > > - > > Effectively we need a CSR type storage for the coarse initial mesh and > a stencil-based storage for the internal, structured mesh. We have noticed > that you have some routines to deal with semi-structured meshes but they > specifically target AMR type meshes, which may not be useful in our case as > the stencil and neighbouring are different to that of a structured > grid-based mesh. Do you think these approaches could be used directly for > our case or with minor modifications? > > > - > > Other possibilities that we have considered are the use of > block-structured solvers, however, in our case, the blocks are not dense > and therefore this approach will be worse. > > > - > > Another alternative would be to develop our own multigrid based on > PETSc ensuring that there is communication between the different blocks > during the smoothing operation, could this also easily be done or would > effectively require applying the smoothers independently to the different > structured sections and us performing the communication and extra-smoothing > steps at the interface? > > > Kind regards, > > -- > Amin Nadimy > > Applied Modelling and Computation Group (AMCG), > > Imperial College London >
