Multidimensional lists not flatten correctly in Python front end

[q-posev]

Bug reported via email. Flattening of list swaps the data ordering (reshape issue likely).

[q-posev]

@scemama I tried to reproduce this bug that you sent me by e-mail and I do not get the re-shaping issue that @joguenzl reported. Here is a simple test using nucleus_coord which is a non-square matrix:

 import trexio

 filename = 'test_benz'

 demo_file = trexio.File(filename, mode='w', back_end=trexio.TREXIO_HDF5)

 coords = [
     [0.00000000  ,  1.39250319 ,  0.00000000 ],
     [-1.20594314 ,  0.69625160 ,  0.00000000 ],
     [-1.20594314 , -0.69625160 ,  0.00000000 ],
     [0.00000000  , -1.39250319 ,  0.00000000 ],
     [1.20594314  , -0.69625160 ,  0.00000000 ],
     [1.20594314  ,  0.69625160 ,  0.00000000 ],
     [-2.14171677 ,  1.23652075 ,  0.00000000 ],
     [-2.14171677 , -1.23652075 ,  0.00000000 ],
     [0.00000000  , -2.47304151 ,  0.00000000 ],
     [2.14171677  , -1.23652075 ,  0.00000000 ],
     [2.14171677  ,  1.23652075 ,  0.00000000 ],
     [0.00000000  ,  2.47304151 ,  0.00000000 ],
     ]

 trexio.write_nucleus_num(demo_file, 12)
 trexio.write_nucleus_coord(demo_file, coords)

 demo_file.close()

 demo_r = trexio.File(filename, mode='r', back_end=trexio.TREXIO_AUTO)

 coords_test = trexio.read_nucleus_coord(demo_r)

 print(coords_test)
 print(coords)

 demo_r.close()

If you run this code, the shape and values of coords and coords_test are identical.

It would really help to have a minimal example (and the version of trexio used) reported together with the bug in order to reproduce it.

[joguenzl]

Hello, I figured out what had happened here a while ago and unfortunately forgot to inform you, sorry about that. I had gotten confused with the array dimensions (ao_num vs mo_num) and gave the library the transposes of the expected matrices, so the data got misaligned when it was restored. It was on v. 2.4.0.

I think it would be useful to add a check for the array dimensions in the Python write methods to avoid the issue in the future.

[q-posev]

Ok, thanks for the update! I am closing this issue.

NB: It was not a bug but a misuse of the API.