Follow-up: Segfault with API-generated HDF5, even when cloning a working example's structure

[dinhyi]

Hello WarpX developers and users,

This is a follow-up to a previous question. Thanks to the community's help, I am now using the openpmd-api to create my external B-field file for WarpX v25.04. However, I am still encountering a persistent Segfault and am hoping you can help me debug it.

Here is a summary of my controlled experiments:

1. Working Case: The official example-femm-3d.h5 file runs perfectly with my inputs script.

2.Failing Case: Any HDF5 file I generate using the openpmd-api in Python causes a Segfault inside WarpX.

3.Key Finding: This crash happens even when I generate a "dummy" HDF5 file that contains simple, clean data (arrays of zeros and ones) but has the same grid metadata (dimensions, spacing, offset) as my final desired grid.

and here mentioned how I generate my data：

Step 1: Interpolation from Source Data
My original data is a large CSV file containing scattered, axisymmetric field data points (r, z, Hr, Hz). Since the openPMD format requires a uniform grid, my first step is to interpolate my scattered data. I use a Python script with pandas and scipy.interpolate.griddata to generate three 3D NumPy arrays (Bx_data, By_data, Bz_data) on a uniform Cartesian grid.
Additionally, I have checked the interpolated NumPy arrays (Bx_data, By_data, Bz_data) and can confirm they do not contain any NaN or inf values, This strongly suggests the problem is with the file's metadata or structure, not the numerical data values.

Step 2: HDF5 File Creation
I then use the following Python script, which is a direct adaptation of the official openpmd_create_3d.py example, to write the NumPy arrays from Step 1 into an HDF5 file. The goal is to clone the structure of the working example file as closely as possible.
`#!/usr/bin/env python3
import openpmd_api as io
import numpy as np

number of grid points

nxnynz = the number of lines in B*_3d.txt

x_min, x_max = -0.7, 0.7
y_min, y_max = -0.7, 0.7
z_min, z_max = -4.0, 4.0
nx = 49
ny = 49
nz = 49

read data

Bx_data = np.loadtxt('gridded_bx.txt').reshape(nx, ny, nz)
By_data = np.loadtxt('gridded_by.txt').reshape(nx, ny, nz)
Bz_data = np.loadtxt('gridded_bz.txt').reshape(nx, ny, nz)

create openpmd file

series = io.Series("test.h5",io.Access.create)

only 1 iteratiion needed

it = series.iterations[1]

set meta information

B = it.meshes["B"]
B.grid_spacing = [(x_max-x_min)/nx, (y_max-y_min)/ny, (z_max-z_min)/nz]
B.grid_global_offset = [x_min, y_min, z_min]
B.axis_labels = ['x', 'y', 'z']
B.geometry = io.Geometry.cartesian
B.unit_dimension = {
io.Unit_Dimension.M: 1,
io.Unit_Dimension.I: -1,
io.Unit_Dimension.T: -2
}

label

B_x = B["x"]
B_x.position = [0,0,0]
B_y = B["y"]
B_y.position = [0,0,0]
B_z = B["z"]
B_z.position = [0,0,0]

dataset = io.Dataset(Bx_data.dtype, Bx_data.shape)
B_x.reset_dataset(dataset)
B_y.reset_dataset(dataset)
B_z.reset_dataset(dataset)

B_x.store_chunk(Bx_data)
B_y.store_chunk(By_data)
B_z.store_chunk(Bz_data)

E = it.meshes["E"]

set meta information

E.grid_spacing = B.grid_spacing
E.grid_global_offset = B.grid_global_offset
E.axis_labels = ['x', 'y', 'z']
E.geometry = io.Geometry.cartesian
E.unit_dimension = {
io.Unit_Dimension.M: 1,
io.Unit_Dimension.L: 1,
io.Unit_Dimension.I: -1,
io.Unit_Dimension.T: -3
}

label

E_x = E["x"]
E_x.position = [0,0,0]
E_y = E["y"]
E_y.position = [0,0,0]
E_z = E["z"]
E_z.position = [0,0,0]

dataset = io.Dataset(Bx_data.dtype,Bx_data.shape)
E_x.reset_dataset(dataset)
E_y.reset_dataset(dataset)
E_z.reset_dataset(dataset)

E is zero in this example

E_x.make_constant(0.0)
E_y.make_constant(0.0)
E_z.make_constant(0.0)

series.flush()

del series`
the three .txt files are
gridded_bx.txt
gridded_by.txt
gridded_bz.txt

Finally here is the content of the Backtrace.0.0 file generated by the crash:
Backtrace.0.0.txt

My Question:

Given that a file generated with the official openpmd-api and clean data (no NaN/inf values) still causes a Segfault, what could be the potential cause? Is there a known issue with the HDF5 reader in WarpX v25.04, or a subtle, "unwritten" metadata requirement that I am missing?

Any insight from the backtrace file would be greatly appreciated.

Thank you.