It may be made of triangles and quads, too, though. In some cases, those happen to be "regions" of the a domain, e.g., a boundary made of triangles. This is for accurate representation of the data. The cell blocks are there to preserve the order of the elements.The user can then decide what to do with the data. meshio's single purpose is to represent the data given in a file as accurately as possible. It doesn't know finite elements, graphics, what have you. meshio should stay agnostic of its applications.Should meshio.Mesh be enhanced to store data associated with Cells directly? Very often, as in the example of #684, numPhysicalTags=1, so there's just one int physicalTag to associate with each Cells (which in turn belongs to a physical name in Mesh.field_data). in MSH 4.1 in which the $Elements are specified in 'entity blocks', each of which has an entityTag pointing to an entity which has numPhysicalTags physicalTags.in OBJ, the name of the subdomain, as in the g group-name syntax #676.
the cells belong to a subdomain (material) or patch of boundary in a mixed boundary value problem (though see #684 and nschloe/pygmsh#301 where one of the types, 'line', has been split arbitrarily by a third-party code, Gmsh).Īssuming that the Cells are physically significant, the application will likely associate data with each, e.g.:
It has to be assumed that having more than one Cells of the same Cells.type will be done for some reason in the application, e.g. cells were split into a List in #631, there has been the possibility of having more than one of the Cells having the same Cells.type.
0 kommentar(er)
