Closed brtnfld closed 4 years ago
@petschge, did we ever decide what the best thing to do about this was?
I think the general agreement was to just remove the write alltogether
Any update if this is going to be merged? Also, should the hdf5_rebase branch be used instead of hdf5 for hdf5/DAOS VOL work?
I made an attempt to address this in #122 , can you look at it please @petschge ?
FYI, with this branch, harrisHDF5 has the same output with the DAOS VOL when compared to native HDF5 output.
Two questions:
1) "This branch", means the one with the potential fix from #122, right? 2) Does the same output mean "it fixed the issue and did not break anything else", or "it did not fix the issue"?
Thanks!
(1) yes, the hdf5_remove_attritue branch. (2) It fixed the issue of the output being different between the two different VOLs. This is what I do to check:
... first to run VPIC (harrisHDF5) using the HDF5 native VOL connector, and then using h5dump on all the output files. This gives the reference files to compare against. VPIC using H5DAOS VOL is run, and h5dump is used to generate the H5DOAS VOL reference files. For all the output dumps, the h5dump results are compared.
I ran ctest and the only test that failed was test_collision_script, but I have not checked if this fails only for this branch.
OK, thanks. I'll merge it then
HDF5 attributes writen to the file can be incorrect depending on which process writes last. Take for example writing the field attribute VPIC-ArrayUDF-GEO,
VPIC does (by all the processes):
but for the HarrisHDF5 case, grid->y0 can have different values between processes. Hyperslab selection can not be used with attributes, so all the processes write their entire array. Hence, the value that gets written to the attribute data is whichever process writes last.