For the purpose of collective I/O it is true that all ranks must call H5Dwrite() so that they can participate in those collective operations that are necessary (the file space re-allocation and so on). However, even though they called H5Dwrite() with a valid memspace, the fact that they have a NONE selection in the given file space should cause their chunk-file mapping struct (see lines 357-385 of H5Dpkg.h for the struct's definition and the code for H5D__link_chunk_filtered_collective_io() to see how it uses this built up list of chunks selected in the file) to contain no entries in the "fm->sel_chunks" field. That alone should mean that during the chunk redistribution, they will not actually send anything at all to any of the ranks. They only participate there for the sake that, were the method of redistribution modified, ranks which previously had no chunks selected could potentially be given some chunks to work on.
For all practical purposes, every single chunk_entry seen in the list from rank 0's perspective should be a valid I/O caused by some rank writing some positive amount of bytes to the chunk. On rank 0's side, you should be able to check the io_size field of each of the chunk_entry entries and see how big the I/O is from the "original_owner" to that chunk. If any of these are 0, something is likely very wrong. If that is indeed the case, you could likely pull a hacky workaround by manually removing them from the list, but I'd be more concerned about the root of the problem if there are zero-size I/O chunk_entry entries being added to the list.
_______________________________________________ Hdf-forum is for HDF software users discussion. [email protected] http://lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org Twitter: https://twitter.com/hdf5
