Fix integer overflows and parallelize the output writers for large meshes

[rois1995]

Proposed Changes

This PR fixes the output of large meshes and makes the output writing faster. The problems appeared on a mesh with 273M points and 496M cells (mostly prisms) run on 576 ranks: some output files were broken, the CGNS file could not be opened in ParaView, and some formats took very long to write. Each commit is self-contained, and its message gives the details.

1. Integer overflows

Several writers stored sizes, offsets or MPI counts in a 32-bit int. Above the limits below, the run crashed or, worse, wrote a broken file without any error. In all cases, the files of meshes below the limits are unchanged.

• MPI-IO collective writes (binary restart, PARAVIEW, PARAVIEW_LEGACY): the size in bytes written by one rank was cast to int. This broke when one rank wrote more than 2 GB in one call, e.g. a binary restart with 20 fields and more than ~13M points per rank (common in hybrid MPI+OpenMP runs). The local data is now described with an MPI datatype of 1 MB blocks, so no count can overflow.
• Sorting of the output data: buffer sizes, offsets and MPI counts were computed as (number of fields) x (number of points) in int, which broke above ~21M points per rank with 100 output fields. The data of each point is now sent as one element of an MPI datatype, and the sizes are size_t.
• PARAVIEW (.vtu): connectivity and offsets were written as Int32, so meshes with more than 2^31-1 connectivity entries (~358M prisms) gave unreadable files. They are now written as Int64 when needed.
• PARAVIEW_LEGACY (.vtk): the cell array of the 3.0 format is Int32 only. When it does not fit, the VTK 5.1 layout with Int64 offsets and connectivity is used (readable by ParaView >= 5.8).
• CGNS gather on the master rank: the MPI counts in bytes were cast to int, which broke above ~33.5M hexahedra per rank. This path is later replaced by the parallel writer (section 4).

2. CGNS: sections above 2^31-1 connectivity entries

The CGNS file of the large mesh is valid, but ParaView crashed when opening it. The VTK CGNS reader stores the connectivity size of each section in an int (reported in https://gitlab.kitware.com/vtk/vtk/-/work_items/20170). Until the reader is fixed, an element type above this limit is written as several sections with consecutive element ranges (<name>_1, <name>_2, ...). Smaller meshes still get one section per element type.

3. CGNS: named boundaries and double precision coordinates

• Boundaries: the volume CGNS file had only the interior cells, and the surface file merged all markers in one unnamed zone. The volume file now also has one section per marker, named as the marker, with a ZoneBC and a Family that carries the BC type. ParaView shows each marker as a named patch, and SU2 can read the file back as a mesh with the same markers. SURFACE_CGNS writes one zone per marker.
• Coordinates: they were written in single precision, which moves the points by up to ~1e-7 of the domain size, which can be larger than the smallest cells. When the output was used again as a mesh (a periodic case), the solution changed by up to 5e-5. Coordinates are now always written in double precision; with this, the same test reproduces the solution to ~1e-14.
• New option WRT_OUTPUT_DOUBLE_PRECISION (default NO): writes the fields of CGNS, PARAVIEW and PARAVIEW_MULTIBLOCK in double precision. The default keeps single precision, so file sizes do not change.

4. Parallel writing

• CGNS: the master rank gathered all data and wrote the whole file alone. This was slow, needed a lot of memory on the master node, and a large file could take longer than the job time left. All ranks now write their own part with the parallel CGNS API (cgp_*, parallel HDF5, already built by SU2 with MPI). Without MPI, the serial API is used as before. The write bandwidth of the CGNS files is now reported in the output summary (it always showed 0 MB/s).
• PARAVIEW_ASCII, RESTART_ASCII, TECPLOT_ASCII and the SU2 mesh writers (ASCII and binary): the ranks wrote one after the other, with a barrier after each rank and each block of data, so the time grew with the number of ranks. Each rank now formats its part in memory, and all ranks write at the same time with one collective MPI-IO call. The files are byte-identical to the previous ones, also for multizone meshes.

Testing

The large mesh cannot be shared, and the overflow limits cannot be reached in CI (a single section above 2^31-1 entries needs more than 20 GB of memory). The tests therefore check that the parallel writers give the same files as before:

• New regression tests (TestCases/output_writers/ascii_output.cfg, parallel regression on 2 ranks): the solution of vandv/rans/flatplate is written without iterating by SU2_CFD (RESTART_ASCII), SU2_SOL (PARAVIEW_ASCII, TECPLOT_ASCII and their surface versions) and SU2_DEF (SU2 mesh file). Each file is compared with a reference file written by the previous writers. The new files are byte-identical to the old ones, on 2 and 4 ranks. The reference files are in Reference files for the parallel ASCII output writer tests TestCases#205.
• The parallel CGNS writer is run by the existing oneram6 parallel regression test (CGNS and SURFACE_CGNS output).
• On the large mesh above, the parallel CGNS file is written and read correctly by post-processing scripts.

Temporary: .github/workflows/regression.yml uses the fixCGNSOutput branch of TestCases until su2code/TestCases#205 is merged. It will be set back to develop before merging.

Question for the reviewers

With MPI, the new writers always write in parallel; the old serial path (gather on the master rank, or ranks writing one after the other) is removed. Parallel HDF5 can be slow on some file systems (e.g. NFS). Should we add a config option to write serially (for example only for CGNS), or is the parallel writing enough?

Related Work

• VTK CGNS reader limit: https://gitlab.kitware.com/vtk/vtk/-/work_items/20170
• Reference files of the new tests: Reference files for the parallel ASCII output writer tests TestCases#205

PR Checklist

• 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.

🤖 Generated with Claude Code

[bigfooted]

wasn't this an issue that was raised at a conference a looong time ago? :-)
@rois1995 can we discuss on slack the status and order of importance/merging of all these huge PRs?