Known limitations

This page collects the architectural limitations of Met.3D that are known and deliberate — things the design consciously does not do, together with the reason and, where one exists, the sketch of how they would be addressed. Many of them were already identified in Chapter 5.3.5 of Rautenhaus (2015) and are still open; a few have since been resolved and are listed at the end.

It is written for developers: it explains why a limitation exists and what lifting it would involve. If you only want to know whether Met.3D fits your data and your platform, Current limitations gives the short answers. If you are looking for actual bugs rather than design limits, see the issue tracker.

Data pipeline

Disk access is the dominant cost for uncached data, and nothing hides it

Reading a full ensemble means reading one field per member, and the available disk bandwidth determines how long that takes. Task parallelism helps only partially, because the code section actually touching the file system is throttled (see Scheduling in Met.3D).

The intended remedy is pre-loading: an additional pipeline module that monitors the requests entering a pipeline, estimates likely upcoming requests — the next time step while the user is looking at the current one, for example — and sends them into the pipeline at a lower priority, so that the scheduler processes them only when no user request is waiting. The memory manager and the task graph make this straightforward to add in principle; what is missing is the monitoring module and a notion of task priority in the scheduler. Neither exists today.

No progressive access

A data source that needs many input items gets them all at once: the task graph produces every input before the consuming task runs. That is efficient, but it requires all inputs to be resident in memory simultaneously. An ensemble that does not fit into the memory manager therefore cannot be processed at all, rather than being processed member by member.

The design sketch is to let the consuming thread suspend when it asks the memory manager for an item that is not there yet, and to wake it once the item has been read — turning the loop over members into a genuinely progressive one. This is not implemented.

No out-of-core support

The whole architecture rests on the assumption that a single field of one variable, one member and one time step fits into system and GPU memory (see Design rationale). Datasets that violate it are not supported. The two classical answers — streaming with domain decomposition, or a level-of-detail representation that is refined as the region of interest shrinks — would both require substantial work, streaming in particular in the visualization algorithms, which currently assume random access to the full field.

Parallelism inside a single module is unexplored

Met.3D exploits task parallelism between modules. Data parallelism within a module, alternative scheduling strategies, and a smarter policy for scheduling GPU access are all plausible improvements that have never been measured systematically.

Rendering

The raycaster uses a fixed step size

Sampling could be restricted to grid cell boundaries with an adaptive step size, which would cut the number of samples considerably. The obstacle is the geometry of hybrid sigma-pressure cells: computing the boundary crossings is itself expensive, and it is not obvious that the trade would pay off. The current mitigation is the coarser interaction step size.

Model level sampling needs software interpolation

The horizontal interpolation between the four surrounding grid columns cannot use texture hardware on hybrid sigma-pressure grids, which is why model level data renders several times slower than pressure level data. See Sampling NWP grids on the GPU.

Grid support

Vertical coordinates are baked into the shaders

Support for a vertical coordinate system is not a data-side concern only: the GPU sampling routines have to know how to convert a level index into a pressure. Adding a genuinely new vertical coordinate means touching the shader code. In many cases this can be avoided by using AUXILIARY_PRESSURE_3D, which stores an explicit 3-D pressure field and therefore accommodates arbitrary vertical coordinates at the cost of one extra 3-D texture.

Horizontal grids other than regular longitude/latitude are experimental

Rotated and proj4-projected grids can be read and visualized, but the support is opt-in at compile time (-DEXPERIMENTAL_PROJECTION_SUPPORT, off by default) and comes with real restrictions, in particular for derived variables and trajectories. See Experimental projection support.

Unstructured grids are not supported at all

Every grid class derives from MStructuredGrid, which assumes a regular longitude/latitude topology and a flat, index-addressable data array, and the GPU sampling routines address the data as a 3-D texture with exactly that layout. Reading ICON output on its native icosahedral grid would therefore require both a new grid type alongside MStructuredGrid and new sampling routines in the shaders, rather than only a new reader. In practice ICON data is remapped to a regular grid before use.

Technical direction

These are not limitations of the design but of its current technical base. They are listed here because they constrain how new code should be written; the authoritative state of each is in the issue tracker, not on this page.

Shader effects still depend on glfx

Met.3D’s *.fx.glsl effect files, which bundle several shader stages and named programs into one file, are compiled by the glfx library. glfx is a small, no longer actively developed dependency, and the intention is to move away from it. Until that happens, new shaders follow the existing effect-file conventions described in Shaders in Met.3D.

A move from OpenGL to Vulkan is under discussion

The renderer targets OpenGL 4.3. A port to Vulkan is discussed as a longer-term direction; it would affect essentially all rendering code, the OpenGL abstraction layer and every shader, and it is not scheduled. It is worth knowing about when designing new rendering infrastructure, but current work should target OpenGL.

Resolved

For orientation, these limitations of the original design no longer apply:

Original limitation	Current state
GPU-generated contour lines carried no labels.	Contour labels are placed by the actor variable and drawn in the label pass.
Shadows were computed per actor and projected onto the ground, so actors did not shadow each other.	Scene-wide cascaded shadow maps, plus volumetric light maps for direct volume rendering. See Shadow mapping.
Trajectories had to be precomputed externally.	Trajectories are computed inside Met.3D through a configurable pipeline, with interactive seeding. See Trajectory Pipeline.