[petsc-users] Load Vec from 1D HDF5 dataset MATT READ THIS EMAIL!

Håkon Strandenes haakon at hakostra.net
Sun Mar 29 16:00:05 CDT 2015


Den 2015-03-29 21:48, skrev Matthew Knepley:
> 
> But of course there already is a PETSc-specific HDF5 format. Someone
> made up "/MESH/nodes/x". This is the essence of HDF5,
> XML, etc. that they are not actually formats, but rather storage
> technologies like the UNIX filesystem. Someone still has to declare
> a format, and we do.
> 
> However, if you want the data array to be 1D in any old HDF5 tool,
> except when complex is used, except when timestepping is used,
> then Yes, we need to make an exception for blocksize. I just think we
> will end up changing this back when it becomes apparent that
> having to put a check in all these HDF5 tools as well is onerous.
> 
>    Matt

My problem, as previously written, is that in the HDF5 output, you do 
already disregard dimensions with size one, all the time, except when 
dealing with the block size. Why?? Just think of the following cases:

1: When you create a dof=1 DMDA, that dof is not added as an extra 
dimension in the HDF5 output. Why don't you always create this 
dimension? When you create a dof=2 or dof=3, you suddenly write one 
extra dimension.
2: When you create a 2D DMDA (or 1D), you do not have that third 
dimension in the output. Why isn't a 2D grid just a special case of 3D 
with one dimension where the size is one?
3: When you do not use complex numbers, you do not have that extra 
dimension in the HDF5 output. Why don't you always add one extra 
dimension here in order to be consistent?
4: When you do not use timestepping, this temporal dimension is not 
added in the HDF5 output. Why don't you always add one extra dimension 
for time, just to avoid having to check for it? You coud treat "no 
timestepping" as "timestep 1"?

So the ONLY TIME you always add one dimension of size 1 is when dealing 
with the block size. In more or less all other cases you disregard these 
one-size dimensions and tries to compact the dataset into as few 
dimensions as possible. This is HIGHLY non-consistent and non-intuitive.

Is it really that hard to handle this "last special case", and suddenly 
get a consistent HDF5 output format?

Regards,
Håkon

(I know that I can make a 3D DMDA with one or two dimensions of size 1, 
and then have one or two dimension of size 1 in the HDF5 output, but 
that is really the only case I can think of. This is however not an 
issue, since it is explicitly declared a 3D case, and the user then 
expect 3D output)


More information about the petsc-users mailing list