> I don't think we thought about the HDF5 tools as of data validation tools. 

Right, it's not obvious, but as I said, once your codes start producing NaNs, 
something is wrong, so in the long term, you don't want your h5 files 
containing NaNs, and you want to know when it occurs.

> Using h5dump to dump GBs or TBs of data to get NaN doesn't make much sense if 
> h5diff already reads each element and reports the differences, i.e., I see 
> your point. My personal opinion is that an application should be checking the 
> validity of the data, but I can see the HDF5 tools as a "second line of 
> defense" :-)

Yes, many of our files are GBs of data, so h5dump-ing them to find NaNs doesn't 
make sense given that h5diff is reading the data.

As for an app checking the validity of its dumped data, I agree in principle, 
but in practice that would result in additional overhead for scientific codes. 
In my case, I'd much rather do it after the run, using h5 tools, rather than at 
each dump of the data.

> 
> If we provide an option to h5diff to choose NaN behavior, will it help? What 
> do other members of this FORUM think?

For us, it would be great.

I'd love to be able to do

h5diff --check-for-nans file1.h5 file2.h5 

and have it tell me that NaNs were detected in the files.

Thanks!
Dave
_______________________________________________
Hdf-forum is for HDF software users discussion.
[email protected]
http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org

Reply via email to