underworldcode / underworld3

https://underworldcode.github.io/underworld3/
Other
21 stars 10 forks source link

Saving mesh varibles to .h5 and .xdmf files fail when using petsc 3.22.0 #259

Open NengLu opened 1 month ago

NengLu commented 1 month ago

Branch tested: development PETSc version: 3.15.0; 3.22.0 Python version: 3.11; 3.12 Issue description:

The xdmf file could not be made correctly when using the function mesh.write_timestep()or mesh.petsc_save_checkpoint() with the new version petsc (3.22.0), because the mesh variables are not saved properly in the h5 file.

To test:

import h5py
from petsc4py import PETSc
import underworld3 as uw

mesh = uw.meshing.StructuredQuadBox(elementRes=(4,4), minCoords=(0, 0), maxCoords=(1, 1))      
v = uw.discretisation.MeshVariable("V", mesh, mesh.dim, degree=1,continuous=True)
p = uw.discretisation.MeshVariable("P", mesh, 1, degree=0,continuous=False)
with mesh.access(p,v):
    p.data[:, 0] = 1
    v.data[:, :] = 1

index = 0
fname = f"{'test'}{index:05d}.h5"
xfname = f"{'test'}{index:05d}.xdmf"
viewer = PETSc.ViewerHDF5().createHDF5(fname, mode=PETSc.Viewer.Mode.WRITE,  comm=PETSc.COMM_WORLD)
meshVars = [p,v]
viewer(mesh.dm)
for var in meshVars:
    viewer(var._gvec)
viewer.destroy()

h5 = h5py.File(fname, "r")
with h5py.File(fname, 'r') as h5_file:
       def print_keys(name, obj):
           print(name)
       h5_file.visititems(print_keys)

when run under the env_py3.11_petsc3.21.5, the results are:

cell_fields
cell_fields/P_P
fields
fields/P
fields/V
.....

when run under the env_py3.12_petsc3.22.0, the results are:

fields
fields/P
fields/V
....
knepley commented 1 month ago

Yes, Stefano changed something. I believe I fixed this by moving the old code to another storage version, which is how we need to manage output changes from now on. I think 1.1.0 will go back to what you want. If not, we can fix it and assign it another version.

NengLu commented 1 month ago

Yes, Stefano changed something. I believe I fixed this by moving the old code to another storage version, which is how we need to manage output changes from now on. I think 1.1.0 will go back to what you want. If not, we can fix it and assign it another version.

Thanks for your reply.