Unified Geometry Handling

[koehlerson]

@termi-official and me fixed https://github.com/KristofferC/JuAFEM.jl/issues/315 in https://github.com/KristofferC/JuAFEM.jl/pull/317. We noticed its maybe worth to discuss if it makes sense to encode more geometric information into the Grid. Currently the geometric information is somewhat widespread and it could be beneficial in future to clearer separate geometric and algebraic functionality. A potential possible benefit could be unified finite element entity handling in grids with mixed geometric cells.

Specifically we have the following in mind

• Geometric interpolation handling moved into grid
• Move RefShape and dim distinction for interpolation functions into grid
• Refactor remaining code to use an updated mesh interface, e.g. provide CellScalarValues constructor with Grid

Do you guys think this could be beneficial or are there any pitfalls? 🦦

[lijas]

I dont quite understand what you mean. Could you maybe explain with an example?

[termi-official]

Sorry, we should have elaborated better. We think that the design of JuAFEM may be a simplified and a bit more robust by shifting the code for handling geometric information. Let me go into some details.

Let us start with the point which seems to me most obvious to me. If we think about the case where a mesh is generated using mixed geometric entities (e.g. triangles+quadrilaterals to make it simple), then, if I understand the usage of this framework correctly, we can use the MixedDofHandler with two fields. One field with Lagrange{2,RefTetrahedron,order}() and one field with Lagrange{2,RefCube,order}(). We think including the geometric type at this point is redundant and can be eliminated, because we can get this piece of information from the grid. Note that there is anyway a tight dependency between the i'th cell in the grid and its geometry.

We think that the same thing should be true for the dimension. Technically we can have problems on mixed dimensional meshes. For example, in my area of research it often pops up that my grids containing line elements embedded in 3D (think of cables) along with hexahedral elements (think of a volume interacting with the cable). On both parts of the grid (1D subgrid and 3D subgrid) the same PDE is used. I do not know how common this use case is, but it should be possible to eliminate the dim parameter without too much problems. I think it is mostly the Jacobian logic which will need some further investigation.

Regarding the geometric interpolation, it looks like it can be moved into to the grid. This way we can have a simpler way of accessing the correct default geometric interpolation. I.e. we would suggest to introduce another function, which could have a signature like

default_geometric_interpolation(grid::AbstractGrid)

which dependes on the obovely mentions simpifications of the Lagrange type. This is handy when we think about e.g. reaction-diffusion systems with high order lagrange basis. Here we usually do not need a the same high order basis for the geometry.

I hope this explains it a bit better.

[koehlerson]

To conclude this: Right now we explicitely downstream the geometric interpolation into every object that needs the information, e.g. latest example https://github.com/KristofferC/JuAFEM.jl/pull/317#issuecomment-764915672. However, the information is already there and it's maybe worth to reuse the already existing information. This should simplify keeping track of geometric information and should avoid issues like the one mentioned.

[lijas]

I think I understand. For the DofHandler, where only one celltype is allowed, it already figures out the default geometric interpolation from the default_interpolation-function. I dont know if it is possible to do the same for the MixedDofHandler since there we add fields via the FieldHandler first, and FieldHandler does not know about the celltypes, hmm...

Regarding your comment on cell types with different dimensions: Are the cable really pure 1d-elements (1 dof in each node), or are they 3d-line-segemnts (3 dofs in each node)? If it is a 3d-line-segment, then we can already handle that with the celltype Line2D/Line3D.

Regarding the geometric interpolation, it looks like it can be moved into to the grid. This way we can have a simpler way of accessing the correct default geometric interpolation. I.e. we would suggest to introduce another function, which could have a signature like
default_geometric_interpolation(grid::AbstractGrid)

Isn't this handled by default_interpolation already? https://github.com/KristofferC/JuAFEM.jl/blob/96ae0b6531a011a4633486c39c79eb63018f1f79/src/Grid/grid.jl#L293

Regarding CellScalarValues(::grid)-construct, I agree that would be nice. One objection though is that it maybe hides a bit to much "behind the scenes". New user might find it unclear why CellScalarValues would need a grid. It is also not obvious what the constructor would to if we have multiple celltypes...

[koehlerson]

Regarding your comment on cell types with different dimensions: Are the cable really pure 1d-elements (1 dof in each node), or are they 3d-line-segemnts (3 dofs in each node)? If it is a 3d-line-segment, then we can already handle that with the celltype Line2D/Line3D.

Consider some quantity like temperature or concentration, then you only care about one dof in each node. Structural 1D simplifications are special in the sense that they decompose the displacements into the directions of the ambient space.

I do not know the plans for the future if MixedDofHandler should replace DofHandler at some point in the future. Considering that both will persist, then it'd be nice if you only need the MixedDofHandler for multi physics problem. You kinda - for my understanding - misuse it in order to have mixed cell types in the grid, because multiple celltypes could be used for one field. Maybe you have some part where you want to preserve symmetric properties so you use there quads and at other places where you don't care triangles for the same field. Pretty constructed example, but I think the point is a bit clearer. You could have mixed cell types already with the normal DofHandler if it would access all geometric information from the grid, i.e. including the geometric interpolation. So practically speaking you'd cache jacobians etc in the geometric cells.

Regarding the CellValues: @termi-official told me that for a rather robust implementation you can have some sort of collection where each index holds a specific kind of entity, let's say a collection with 9 locations, index 1 is reserved for line cells, index 2 for linear quads, index 3 for quadratic quads, index 4 for triangles,... and so on. In the constructor you pass the grid now you know which entities exists in the grid. Let's say three different types. So, you only fill up 3 of 9 locations where in each location a suitable CellValue subtype sits with the appropriate N, dNd\xi stuff and so on

[kimauth]

I agree that the grid and the geometry interpolation are closely related. However, I think handling both the geometry and the function interpolation in the CellValues is very flexible, also for custom extensions to the functionality. E.g. I am using a custom CellValues struct with a custom geometry interpolation for cohesive elements. On these same cohesive elements I also want to solve a diffusion equation, using (somewhat modified) continuum elements. Therefore, I need to have two different geometry interpolations on the same cells. Would that still be possible with your ideas for moving the geometry interpolation to the grid? (Now it is very simple, I just use several different CellValues.)

[termi-official]

The short answer is: yes, it is still possible from a pure software point of view, however the approach will most likely look a bit different in the new implementation. I guess your elements have a Lagrangian geometry on a connected domain, so we can view the additional geometric interpolation as some H1 field over some subdomain (assuming the new mixed DOF handler). Does this make sense? Please note that I am not familiar with cohesive elements and the formulation you mention above, so I would ask whether you could leave a reference here with details on the additional geometrical field?