Hi All,
I am updating and cleaning up the code implementing regions, so it's a good time to fix the naming of certain things, especially to be consistent with the new CMesh class (a C implementation of mesh-related data structures, as described in [1]). The CMesh should make the changes proposed below feasible.
In a modern FEM, there is a distinction between a node (a topological entity, where degrees of freedom are defined - e.g. points, edges, faces, element/cell interiors) and a vertex (the geometrical points that define the element shape). Our the regions selectors use the term "nodes", due to historical reasons, incorrectly, as what is really meant is "vertices".
So I would like to propose a new naming scheme (feedback welcome!), a new "kind" attribute of regions, and a bunch of new operators:
nodes -> vertices elements -> cells edges, faces stay facets refer to entities with co-dimension 1 (= dimension 1 less than cells; = edges in 2D, faces in 3D)
set-like operators: + (union), - (difference), * (intersection), followed by one of ('v', 'e', 'f', 'c', and 's') for vertices, edges, faces, cells, and facets. So the current '+n' would be '+v', '+e' would be '+c' etc. The actual meaning of those operators would depend of the region kind, see below.
region kinds (is there a better word than "kind"?):
- cells_only, facet_only, face_only, edge_only, vertex_only - only the specified entities are included, others are empty sets (so that the ops are still defined)
- cells, facet, face, edge, vertex - entities of higher dimension are not included
- the "cells" kind is the most general, and corresponds to current implementation with the "can_cells" flag set to True. The flags will disappear.
- intermediate regions used in expressions would have the "cells" kind for simplicity - this could be improved later
- Question: maybe there would be too many kinds? Too few? I can see an application for cells_only, facet_only, face_only, edge_only, but the others were added more or less for the feeling of "completeness".
The kinds would allow a clear distinction between regions of different purpose (volume integration domains, surface domains, etc.) and could use less memory.
Let me know what you think about the proposed changes (especially Vladimir and other people who work with the internals).
Cheers, r.
[1] A. Logg: Efficient Representation of Computational Meshes. 2012
Hi Robert,
I have no objections to the proposed changes. CMesh class seems to be an efficient representation of FE meshes and also renaming the entities sounds reasonable. The region kinds is good idea, but I propose to unified it somehow at the user level, otherwise it can be confusing.
Regards Vladimir
Dne pondělí, 3. června 2013 17:26:11 UTC+2 Robert Cimrman napsal(a):
Hi All,
I am updating and cleaning up the code implementing regions, so it's a good time to fix the naming of certain things, especially to be consistent with the new CMesh class (a C implementation of mesh-related data structures, as described in [1]). The CMesh should make the changes proposed below feasible.
In a modern FEM, there is a distinction between a node (a topological entity, where degrees of freedom are defined - e.g. points, edges, faces, element/cell interiors) and a vertex (the geometrical points that define the element shape). Our the regions selectors use the term "nodes", due to historical reasons, incorrectly, as what is really meant is "vertices".
So I would like to propose a new naming scheme (feedback welcome!), a new "kind" attribute of regions, and a bunch of new operators:
nodes -> vertices elements -> cells edges, faces stay facets refer to entities with co-dimension 1 (= dimension 1 less than cells; = edges in 2D, faces in 3D)
set-like operators: + (union), - (difference), * (intersection), followed by one of ('v', 'e', 'f', 'c', and 's') for vertices, edges, faces, cells, and facets. So the current '+n' would be '+v', '+e' would be '+c' etc. The actual meaning of those operators would depend of the region kind, see below.
region kinds (is there a better word than "kind"?):
- cells_only, facet_only, face_only, edge_only, vertex_only - only the specified entities are included, others are empty sets (so that the ops are still defined)
- cells, facet, face, edge, vertex - entities of higher dimension are not included
- the "cells" kind is the most general, and corresponds to current implementation with the "can_cells" flag set to True. The flags will disappear.
- intermediate regions used in expressions would have the "cells" kind for simplicity - this could be improved later
- Question: maybe there would be too many kinds? Too few? I can see an application for cells_only, facet_only, face_only, edge_only, but the others were added more or less for the feeling of "completeness".
The kinds would allow a clear distinction between regions of different purpose (volume integration domains, surface domains, etc.) and could use less memory.
Let me know what you think about the proposed changes (especially Vladimir and other people who work with the internals).
Cheers, r.
[1] A. Logg: Efficient Representation of Computational Meshes. 2012
On 06/13/2013 04:21 PM, vlu...@kme.zcu.cz wrote:
Hi Robert,
I have no objections to the proposed changes. CMesh class seems to be an efficient representation of FE meshes and also renaming the entities sounds reasonable. The region kinds is good idea, but I propose to unified it somehow at the user level, otherwise it can be confusing.
For regular use, only two types are important - cell_(only) - for volume integrals, and facet_(only) for boundary integrals. It will still be possible to use the default (cell) kind for everything, but using the other kinds might come handy for large problems when every byte counts.
You can check the work-in-progress code at [1]. The CMesh has been extended as well, mainly with adapter functions to work with the rest of the code, that expects everything organized by element groups. Neither CMesh nor (new) Region require element groups (-> much simpler code!), so this might be considered as the first step to get rid of them. For now, a Domain instance has both .mesh (Mesh instance) and .cmesh (CMesh instance) attributes.
BTW. I am using @property and @property.setter decorators in the new code, which requires Python >= 2.6. Let me know if it is a problem for someone.
r.
[1] https://github.com/rc/sfepy/commits/regions
Regards Vladimir
Dne pondělí, 3. června 2013 17:26:11 UTC+2 Robert Cimrman napsal(a):
Hi All,
I am updating and cleaning up the code implementing regions, so it's a good time to fix the naming of certain things, especially to be consistent with the new CMesh class (a C implementation of mesh-related data structures, as described in [1]). The CMesh should make the changes proposed below feasible.
In a modern FEM, there is a distinction between a node (a topological entity, where degrees of freedom are defined - e.g. points, edges, faces, element/cell interiors) and a vertex (the geometrical points that define the element shape). Our the regions selectors use the term "nodes", due to historical reasons, incorrectly, as what is really meant is "vertices".
So I would like to propose a new naming scheme (feedback welcome!), a new "kind" attribute of regions, and a bunch of new operators:
nodes -> vertices elements -> cells edges, faces stay facets refer to entities with co-dimension 1 (= dimension 1 less than cells; = edges in 2D, faces in 3D)
set-like operators: + (union), - (difference), * (intersection), followed by one of ('v', 'e', 'f', 'c', and 's') for vertices, edges, faces, cells, and facets. So the current '+n' would be '+v', '+e' would be '+c' etc. The actual meaning of those operators would depend of the region kind, see below.
region kinds (is there a better word than "kind"?):
- cells_only, facet_only, face_only, edge_only, vertex_only - only the specified entities are included, others are empty sets (so that the ops are still defined)
- cells, facet, face, edge, vertex - entities of higher dimension are not included
- the "cells" kind is the most general, and corresponds to current implementation with the "can_cells" flag set to True. The flags will disappear.
- intermediate regions used in expressions would have the "cells" kind for simplicity - this could be improved later
- Question: maybe there would be too many kinds? Too few? I can see an application for cells_only, facet_only, face_only, edge_only, but the others were added more or less for the feeling of "completeness".
The kinds would allow a clear distinction between regions of different purpose (volume integration domains, surface domains, etc.) and could use less memory.
Let me know what you think about the proposed changes (especially Vladimir and other people who work with the internals).
Cheers, r.
[1] A. Logg: Efficient Representation of Computational Meshes. 2012
participants (2)
-
Robert Cimrman
-
vlu...@kme.zcu.cz