WG3 Meeting in Warsaw - expanding the Open DEM File Format

On 24–25 November 2025, WG3 met in Warsaw for two busy (and genuinely productive) days of discussion, whiteboarding, and decisions. We came in with a clear plan for what we wanted to tackle, and we left with something even better: a shared understanding of what the Open DEM file format should contain and a practical way to document and publish that work so others can build on it.

A big part of our time was spent getting very concrete about the basics. We agreed on the minimum information that should be stored for a first set of simple material models, contact models, and particle/body data. That sounds small, but it’s the foundation that everything else depends on. If this layer is unclear or inconsistent, interoperability collapses immediately. If it’s solid, the entire ecosystem gets easier: sharing results, reusing data, validating simulations, and writing tools that work across more than one code.

Once we had the what, we tackled the how. We aligned on a hierarchical structure for storing variables so the format stays readable and scalable as the scope grows. In the same flow, we also agreed on notations and measurement units, so when someone sees a variable, they don’t have to guess whether it’s in metres or millimetres, or whether a symbol means what it means in their own code. That might not sound exciting—until you’ve tried to compare two datasets where the same name means two different things.

We also spent time on the questions that always come up when you’re trying to standardize anything, and it was worth it. We talked through what should be stored versus derived, how to stay minimal without becoming vague, and where the line sits between format-level meaning and code-specific implementation details. These philosophical discussions were actually very practical, because they help prevent the format from drifting into either extreme: too rigid to use, or too loose to trust.

To keep things grounded, we also discussed a real performance comparison that looked at the practical cost of moving DEM data in and out of different formats. In particular, we compared the read/write speeds for DEM datasets stored as plain text versus HDF5, and also looked at VTKHDF as a format that can bridge efficient storage with post-processing needs. This kind of hands-on comparison is important because it connects our format decisions to what users actually feel day-to-day: file sizes, I/O time, and how quickly data becomes usable in analysis or visualization workflows.

One of the most important outcomes was that we didn’t stop at decisions—we agreed on a clear methodology for turning them into version-controlled documentation in the ON-DEM GitHub repository. That means our output isn’t just meeting notes: it becomes structured, reviewable content that the community can rely on. We also framed parts of this documentation as examples that other COST members can copy and extend later. In other words, we’re not only defining what exists today—we’re making it easier for the next person to contribute without reinventing the approach.

Finally, we left Warsaw with a work plan for the coming weeks, tied to deliverables and deadlines, and with owners and next steps that feel realistic. That matters, because momentum is fragile: clarity + small, consistent progress beats big intentions every time.

Thank you to everyone who joined, contributed, challenged assumptions, and helped us converge. Meetings like this are where a shared standard becomes a shared project - and Warsaw moved us a real step forward.