[Dune] Handling several materials

[Dedner, Andreas]

Hi.
Just wanted to give another perspective based on how we might do this in dune-fem:
the way I would suggest doing this is to store the parameters defining your domain in a
discrete function over a `FiniteVolumeSpace`. This gives you then exactly one value per
entity (possibly a bit of an overkill since it is a double by default but that could be useful as
mention below). Then
(a) local grid refinement and coarsening is taken care automatically., i.e., the material
      properties are transferred to the new elements in the mesh when calling grid.adapt()
(b) (when using Python bindings) you can directly use this discrete function as UFL coefficient       when describing the UFL form using `ufl.conditional`. Unfortunately `ufl.conditional` isn't
      very nice to use but since I didn't so far have an application I didn't look more into ufl
      and subdomains. So in fact instead of defining the material property discrete function
      by setting an integer on each cell I would directly use the finite volume discrete function
      to store the material properties - at least if this is not prohibitive w.r.t. memory, i.e., it
      depends on how many material properties have to be set. Assuming it is only a few values
      (r) then one could setup a finite volume discrete function with range dimension r and
      directly use that within the ufl expression for the model. Again adaptivity would be handle
      automatically as mentioned in (a).
Just some thoughts
Andreas
________________________________
From: Dune <dune-bounces at lists.dune-project.org> on behalf of Christian Engwer <christian.engwer at uni-muenster.de>
Sent: 06 April 2020 16:39
To: HELFER Thomas 202608 <thomas.helfer at cea.fr>
Cc: dune at lists.dune-project.org <dune at lists.dune-project.org>
Subject: Re: [Dune] Handling several materials

> In case of adaptative remeshing, would those modules update individual domains, so I
> would not have to care about those technicalities you mentionned ?

If you use local adaptivity you will always have to make sure your
data is present on the adapted mesh. Usually this requires some
interpolations and so on. In a similar way we now also have to
transfer these indices. And additionaly from the "Gmsh" mesh to your
actual mesh object.

If you would opt for multidomain or subgrid. Things wuld be
significantly more complecated. You would safe some work, because you
don't transfer the parameters between meshes (as you have exactly one
parameter set per subdomain), but you will have to setup Problems mit
many different subdomains and extract the list of cells in one
subdomain from your gmsh file (so you will need again the initial
indices).

Ciao
Christian

_______________________________________________
Dune mailing list
Dune at lists.dune-project.org
https://lists.dune-project.org/mailman/listinfo/dune
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dune-project.org/pipermail/dune/attachments/20200406/fc6033f5/attachment.htm>