I’m opening this topic to discuss possible improvements to the user interface (defined by the Problem API) for DEM objects (digital elevation models / topography).
Currently, modulo some filling issues that are currently being addressed in private development branch, DEMs are supported through three functions:
addDEMis used to define the topography to be loaded and its fill type;addDEMFluidBoxis used to add a fluid box inside the region spanned by the DEM, following the topography (or bathymetry in this case), with a user-defined height o which fluid will be filled;
and optionally
addDEMPlaneswill add geometric planes corresponding to the four sides of the DEM.
A topography can be used in two different ways: with the ENABLE_DEM flag, it will be treated geometrically, and this should be combined with a FT_NOFILL filltype for the DEM; or alternatively, the preferred usage is with FT_OUTER_BORDER, which makes the DEM equivalent to a Box with an irregular floor.
The geometric planes defined by addDEMPlanes can be used both as geometric boundaries for the simulation (with the ENABLE_PLANES simulation flag) and when using boundary particles to manipulate the wall geometries (e.g. setting them to an FT_UNFILL filltype to remove the corresponding particle boundaries). This (or defining the corresponding planes manually) is in fact currently the only way to control which walls will be filled and which not.
This makes defining test cases more convoluted than necessary when the DEM only defines a part of the domain, or e.g. in conjunction with periodic boundary conditions. We would like to improve the interface here, and user input about the approach to take would be useful.
A possible proposal, still open to discussion, would be the following.
A way to identify walls is needed. This could be an enumeration of WEST_WALL, EAST_WALL, NORTH_WALL, SOUTH_WALL, TOP_WALL, BOTTOM_WALL, corresponding respectively to X-, X+, Y-, Y+, Z-, Z+ (the west/east/north/south notation corresponds to the mapping from e.g. ASCII grid DEMs).
addDEMPlanes can be extended to take an optional argument to define which walls are to be added.
A new function (to be named still) will do the same for the particle boundaries. Note that, for backwards compatibility, all walls will be filled if an appropriate filltype is defined for the DEM, so this function should be able to override this default behavior (so it cannot be called addDEMBoundaries, for example). It may be instead necessary to have two different functions (e.g. enableDEMBoundaries() and disableDEMBoundaries()) to toggle boundaries on/off.
Comments on this proposal, with suggestions on how to improve it, are welcome.