[petsc-users] Development enquiry

[Mark Adams]

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 <amin.nadimy19 at imperial.ac.uk>
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20220208/41ce4210/attachment.html>