Write empty strings to hdf5

[GuySten]

Description

Currently we do not write empty strings to hdf5 which makes alot of fields conditionaly there.
This is a source for errors like the MWE below.

This PR change that behavior so that the fields are guaranteed to exist and can be empty.

MWE

import openmc

# --- a minimal real model: 10 cm water sphere, fixed source at the center ---
water = openmc.Material()
water.add_nuclide('H1', 2.0)
water.add_nuclide('O16', 1.0)
water.set_density('g/cm3', 1.0)

sphere = openmc.Sphere(r=10.0, boundary_type='vacuum')
cell = openmc.Cell(fill=water, region=-sphere)

settings = openmc.Settings()
settings.run_mode = 'fixed source'
settings.particles = 100
settings.batches = 5
settings.source = openmc.IndependentSource(space=openmc.stats.Point())

model = openmc.Model(
    geometry=openmc.Geometry([cell]),
    materials=openmc.Materials([water]),
    settings=settings,
)

# Model.run() forwards path_input=None (model.py:963), so the executable is
# invoked without -i and settings::path_input stays empty.
sp_file = model.run()

sp = openmc.StatePoint(sp_file, autolink=False)
print('statepoint:', sp_file)
print('version:   ', sp.version)
print('attrs:     ', sorted(sp._f.attrs))   # 'path' is missing
print(sp.path)                              # KeyError: 'path'

Checklist

• I have performed a self-review of my own code
• I have run clang-format (version 18) on any C++ source files (if applicable)
• I have followed the style guidelines for Python source files (if applicable)
• I have made corresponding changes to the documentation (if applicable)
• I have added tests that prove my fix is effective or that my feature works (if applicable)

[paulromano]

Thanks for proposing this @GuySten. However, I'm not crazy about this approach for something that is a relatively easy fix otherwise. I just submitted an alternative PR #4118. Let me know what you think of that one.

[GuySten]

Closing in favor of #4118.

For the record, the reasoning: even with the writer change here, the reader guards in #4118 are still needed for files written by older versions, so this PR was never sufficient on its own. What it added beyond that was the guarantee that future files don't need guards at all — and that isn't worth changing every file OpenMC writes. Removing the !name_.empty() checks in cell.cpp/lattice.cpp/surface.cpp also means an empty name dataset per cell, surface and lattice in summary.h5, which is most of them in a generated model.

Thanks for the review @paulromano.