Open HugoStrand opened 1 month ago
One of the offending parameters is the symmetrize
flag loaded by triqs/3.3.x
here,
https://github.com/TRIQS/triqs/blob/3.3.x/c%2B%2B/triqs/mesh/dlr.hpp#L250
which did not exist in triqs/3.2.x
, see
https://github.com/TRIQS/triqs/blob/3.2.x/c%2B%2B/triqs/mesh/dlr.hpp#L237
Dear @HugoStrand I have restored backward compatibility for the dlr meshes IO in commits 77d0339 and https://github.com/TRIQS/triqs/commit/86a7993d42422d9638906b5a8b72b8748b4c9b2a
Dear @Wentzell,
Thank you for the fix. I am afraid that it by itself is not sufficient for bwd compatibility.
It seems like the cppdlr
h5 storage pattern also have diverged from 1.0.x to 1.1.x, see
https://github.com/flatironinstitute/cppdlr/blob/1.0.x/c%2B%2B/cppdlr/dlr_imtime.hpp#L709
and
https://github.com/flatironinstitute/cppdlr/blob/1.1.x/c%2B%2B/cppdlr/dlr_imtime.hpp#L801
the field it2cf_zlu
is new and does not have any legacy fallback.
Reading a dlr mesh from 3.2.x with 3.3.x gives
Error in h5::group: it2cf_zlu does not exist in the group /ps/0/cmesh/dlr_it
I have sent a pull request to cppdlr/1.1.x
that should fix this issue, please see
https://github.com/flatironinstitute/cppdlr/pull/11
Thank you @HugoStrand for looking into this. There is indeed a backward compatibility break that was introduced in cppdlr. We have reviewed your changes in https://github.com/flatironinstitute/cppdlr/pull/11 and it should be ready for merge.
Description
There are a few new h5 properties stored for the
MeshDLRXXX
types in version 3.3.x. This breaks backwards compatibility of reading h5 data stored using triqs 3.2.x.Steps to Reproduce
Proposed solution
Add checks for the new data stored in the mesh types in 3.3.x and set them to default values if they are not present in the h5 file. (Discussed on the triqs quick updates meeting 2024-06-27).