SU2 Binary grid format

[vdweide]

Proposed Changes

A binary version of the SU2 grid format has been defined, see below, and a very first version of the reader has been implemented. The binary version of this SU2 format enables a much faster reading of the grid file, especially for very large cases. E.g., I am running a case, which consists of 430 million hexahedra (435 million points). When using the ASCII version of the SU2 file it took 45 minutes on 3,000 cores to read the grid. With the new binary format it takes less than 2 seconds. I tried to create a CGNS version of this grid, but I got errors in the CGNS library (I tried multiple versions) and therefore created this solution.

At the moment the format described below is used for the binary grid file (extension .su2b). However, at this stage this can be changed easily. It is a bit less flexible than the ASCII format, but it is still so similar that the same base classes can be used for the actual reading. The current format is as follows, where conn_type = uint32_t for 4 byte types and conn_type = uint64_t for 8 byte types

int32_t size_conn_type // Type used for the connectivities. Either 4 or 8 bytes.
// This also serves as a check if little or big endian format is used.
int32_t number_of_zones // Number of zones. Must be present, in contrast to the ASCII format
for all zones // Loop over all the zones in the grid
int32_t zone_id // Zone ID. Must be present, in contrast to the ASCII format
int32_t n_dim // Number of dimensions of the zone
conn_type n_elem // Number of volume elements of the zone.
conn_type offset_elem // Offsets of the volume element connectivity, size is n_elem+1
conn_type elem_conn // Connectivity of the volume elements. Same as in ASCII format.
// Size is offset_elem[nElem].
conn_type n_points // Number of points in the grid
double coor + conn_type point ID // Coordinates and point ID. Same as in ASCII format.
// Size n_dim*n_points coordinates and n_points ID's
int32_t n_markers // Number of markers for this zone
for all markers // Loop over the markers of this zone
char[33] marker_name // Name of the marker
conn_type n_bound_elem // Number of boundary elements for this marker.
conn_type offset_bound_elem // Offsets of the surface connectivity, size is n_bound_elem+1
conn_type bound_elem_conn // Connectivity of the boundary elements. Same as in ASCII format.

The addition of the offset allows for fast navigating through the file, which is beneficial for large number of MPI ranks. The conn_type is also used for the offset a uint32_t can be used for grids of roughly 300 to 400 million points, depending a bit on the element types used. For even bigger grids the uint64_t is necessary.

This is still a draft PR, so there is no support yet for actuator disks. Also the corresponding reading of the FEM part is not implemented yet. This will be done if people think this is a useful addition. Then also a converter from ASCII to the binary format will be made available.

Related Work

None

PR Checklist

Put an X by all that apply. You can fill this out after submitting the PR. If you have any questions, don't hesitate to ask! We want to help. These are a guide for you to know what the reviewers will be looking for in your contribution.

• I am submitting my contribution to the develop branch.
• My contribution generates no new compiler warnings (try with --warnlevel=3 when using meson).
• My contribution is commented and consistent with SU2 style (https://su2code.github.io/docs_v7/Style-Guide/).
• I used the pre-commit hook to prevent dirty commits and used pre-commit run --all to format old commits.
• I have added a test case that demonstrates my contribution, if necessary.
• I have updated appropriate documentation (Tutorials, Docs Page, config_template.cpp), if necessary.

[pcarruscag]

Looks good.
Would it be a lot of work to handle the writing too? I suppose you have a simple converter but missing all the mpi stuff?

[vdweide]

Looks good. Would it be a lot of work to handle the writing too? I suppose you have a simple converter but missing all the mpi stuff?

Yes, I do have a sequential converter. I think it should be doable to add a write option as well. I'll have a look at it.