lehrfempp
lehrfempp copied to clipboard
craffael
MeshHierarchy: Mark internal public functions as internal in the documentation
The MeshHierarchy class has five methods which essentially attach a struct for every mesh entity:
-
const std::vector<PointChildInfo> &PointChildInfos(size_type level) const -
const std::vector<EdgeChildInfo> &EdgeChildInfos(size_type level) const -
const std::vector<CellChildInfo> &CellChildInfos(size_type level) const -
const std::vector<ParentInfo> &ParentInfos(size_type level, dim_t codim) const -
const std::vector<sub_idx_t> &RefinementEdges(size_type level) const
In order to better align with the rest of LehrFEM++ and to also make it more clear that the data values are indeed attached to Mesh entities, I would suggest to use (Codim)MeshDataSets instead of std::vector. I.e. the signature of PointChildInfos could become
const MeshDataSet<PointChildInfo>& PointChildInfos(size_type level) const
To achieve this, MeshHierarchy would of course need to store CodimMeshDataSets internally instead of std::vector, but I don't think that this is a problem.
An Advantage of using MeshDataSets is also that we get automatic bounds checking, i.e. the user gets an error message when he passes e.g. an entity of the wrong codimension or when the entity belongs to the wrong mesh. In addition, the code to access the stored data becomes a bit less verbose:
auto data = mesh_hierarchy.PointChildInfos(1)[mesh.Index(e)];
would become
auto data = mesh_hierarchy.PointChildInfos(1)(e);
All these methods were never meant for the "public" interface of the library, because all the data structures rely on complicated conventions and are mainly meant for "local use". Therefore, I do not consider the conversion to MeshDataSet worth while.
Aha I see, that wasn't clear to me when I looked at the header file and also @TobiasRohner started using one of the methods without knowing that these are not part of the "public interface". I see two possible ways to improve the current situation:
- we group all these methods in the doxygen documentation under "internal methods" and add a note to everyone saying that it's not meant to be used by the user.
- we make the methods private and add a friendship declaration to MeshHierarchy so that the current code still compiles.
What do you prefer? Most of these methods are only used by lf::refinement::test::checkFatherChildRelations() or lf::refinement::WriteMatlabLevel().
I advocate the first approach, because access to refinement information should not be restricted too much. I will take care of adding a warning to the documentation.