Skip to end of metadata
Go to start of metadata

You are viewing an old version of this content. View the current version.

Compare with Current View Version History

« Previous Version 4 Current »

Discussion leader(s)

  • Adrian Priceputu

  • Bruno Chareyre

Key Achievements

  1. Concluded that we should use HDF5 format to store data instead of ascii based formats

    1. Flexible, self-describing hierarchical data format for storing scientific data - easy to include simulation metadata

  2. Sketched a framework for storing DEM data to save/reload any simulation in different codes

Focus for next period

  1. Setup the backbone of the simulation data structure

  2. Find an efficient way of populating, viewing and expanding the data structure

  3. Populate the data structure with specific data from various codes or models

Input needed from other WGs

  1. WG2 could help with populating relevant data for different contact models

Key contributors (in alphabetical order)

  1. Bruno Chareyre

  2. John Morrissey

  3. Mathieu Westphal

Brief Summary

File format

HDF5 offers a flexible file format for storing complex data and metadata. Metadata allows files to be self-describing and is suitable for storing details regarding the simulation, allowing data to be stored in a common format for all DEM codes.

Well supported across various computing libraries.

Two possible options:

  1. Define a file structure that allows all aspects of a DEM simulation to be recorded

    1. Simulation metadata (materials, interactions, domain, etc)

    2. Particle information

    3. contact information

  2. Use VTKHDF which offers a predefined HDF5 based format for data visualisation but fixed layout

    1. may not be possible to store all data required for interoperability for storing a complete simulation (metadata not officially supported)

    2. Easy of visualisation (read directly in paraview)

    3. Temporal support for large datasets not mature enough (single file only and not suitable for very large multi-timestep simulations)

Both options need development to capture a DEM

Required Data Structure

VELaSSCo format serves as example format (Ascii based) on how to structure.

It was decided that we need to display a hierarchy of data with normalized names in order to export / import simulations from one code to another.

Some data will be flagged as “mandatory” – needed for saving the simulation – while other will be flagged as “optional” – this is used for post-processing only.

A sketch of this framework (as discussed during the meeting) is shown below:

data framework sketch-20240730-081339.png

  1. Important Links

  • No labels