Les concepteurs hdf5 ont-ils résolu le problème de corruption lié à l'ouverture de fichiers .hdf5?

Question

Je cours un code qui prend des fichiers .hdf5 comme une entrée (produite par une simulation) puis les analyse et produit des statistiques et trace en exécutant la ligne de commande: python3 Collector.py dans un shell Konsole d'un Linux Fedora 21. J'ai beaucoup de routines .py dans deux dossiers différents nommés gizmo et utilities dans le répertoire de travail. Les fichiers snapshot_index.hdf5 sont transférés séparément (à l'aide du logiciel globus) d'une autre machine qui exécute les simulations dans un répertoire local appelé output dans le répertoire de travail de mon ordinateur portable. (Il y a beaucoup de fichiers correspondant à "index" allant de 0 à 600 mais j'ai seulement besoin de deux tels index, par exemple snapshot_396.hdf5 et snapshot_600.hdf5). Les simulations sont exécutées dans deux modes différents: basse résolution et haute résolution. Lorsque des fichiers .hdf5 de faible résolution en kilo-bits sont l'entrée de l'expression part (à l'intérieur du code python principal mentionné ci-dessus), je peux exécuter le code et produire les résultats mais quand je mets une méga-morsure la taille des fichiers de haute résolution en entrée de l'expression part, je reçois le message d'erreur suivant:

# in utilities.simulation.Snapshot(): 
    read snapshot_times.txt 
    reading snapshot index = 600, redshift = 0.000 


# in gizmo.gizmo_io.Read(): 
    reading header from: ./output/snapshot_600.hdf5 

Traceback (most recent call last): 
    File "Collector.py", line 12, in <module> 
    part=gizmo.io.Read.read_snapshots('all', 'index', 600, element_indices=None) 
    File "/home/username/Desktop/Projects/PaperMaterials/DM_Dominated_Objects/NewFolder2/covering_fractions/Simulations/gizmo/gizmo_io.py", line 314, in read_snapshots 
    'index', snapshot_index, simulation_directory, snapshot_directory, simulation_name) 
    File "/home/username/Desktop/Projects/PaperMaterials/DM_Dominated_Objects/NewFolder2/covering_fractions/Simulations/gizmo/gizmo_io.py", line 513, in read_header 
    file_in = h5py.File(file_name, 'r') # open hdf5 snapshot file 
    File "/usr/lib/python3.4/site-packages/h5py/_hl/files.py", line 222, in __init__ 
    fid = make_fid(name, mode, userblock_size, fapl) 
    File "/usr/lib/python3.4/site-packages/h5py/_hl/files.py", line 79, in make_fid 
    fid = h5f.open(name, h5f.ACC_RDONLY, fapl=fapl) 
    File "h5f.pyx", line 71, in h5py.h5f.open (h5py/h5f.c:1809) 
OSError: Unable to open file (Truncated file: eof = 933756928, sblock->base_addr = 0, stored_eoa = 1765865624) 

je ne comprends pas le sens de l'erreur. Mais quand j'ai fait une recherche sur le sujet, j'ai remarqué que ce n'est pas un nouveau problème concernant les fichiers .hdf5 (Corrupt files when creating HDF5 files without closing them (h5py)) sauf que la raison de ne pas pouvoir ouvrir le fichier est différente dans mon cas. D'après ce que je comprends (je ne sais pas si c'est correct), les fichiers sont trop gros et donc tronqués. Si c'est le cas, quelle est la solution pour cela? Et si j'ai tort alors quel est le problème? Votre aide est grandement appréciée.

Answer 1

Il semble que votre fichier d'entrée soit corrompu. Que se passe-t-il si vous exécutez les utilitaires de ligne de commande h5dump, h5stat ou h5ls dans votre fichier d'entrée?

Je ne pense pas que votre problème a quelque chose à voir avec les concepteurs de HDF5, ou l'autre question que vous avez liée (qui concernait un programme qui s'est écrasé lors de l'écriture d'un fichier HDF5). Très probablement votre programme d'écriture a un bug. Vous pouvez vérifier cela en vérifiant si d'autres programmes HDF5 valides fonctionnent avec vos fichiers.

Votre fichier semble avoir une taille inférieure à 1 Go, ce qui n'est pas énorme pour HDF5.