Re: [h5md-user] Writing vs reading

[Felix Höfling]

Am 10.01.2014, 16:57 Uhr, schrieb Olaf Lenz <address@hidden>:

> Hi!
>
> Ultimately, the problem that seems to reoccur in many of the discussions  
> is
> the question who will have to do the most effort: the writer of h5md, or
> the reader?
> We have to decide who we want to give that effort. Depending on that
> decision, we will have to make the specs either very restrictive and  
> clear,
> or to allow any meaningful use.
>
> Let me show this in the case of particle positions. I see two possible
> solutions:
>
> *1. Reader-friendly*
> In a "reader-friendly" approach, we would specify exactly how positions  
> in
> periodic boundary conditions have to be stored in h5md, e.g. "image" has  
> to
> always exist, and "position" always has to be within the primary box.  
> This
> makes reading the positions from a h5md file simpler.
> However, it comes at the cost that the writer of the file will have to
> prepare the data exactly as h5md specifies it.
>
> *2. Writer-friendly*
> In a "writer-friendly" approach, we would allow any possible case how to
> store the positions as long as it is unique (with image, without image,
> inside the primary box, outside the primary box, whatever).
> This comes at the cost that reading the file is more complex.
>
> Which of these solutions do we prefer? I have the feeling that so far,  
> h5md
> is constructed in a "writer-friendly" way. Is that what we want?
>
> Some more points on this decision:
>
>    - Both of the solutions can be made simpler by providing library
>    functions to read or write data.
>    - When we go the reader-friendly way, we will not be able to prevent
>    people to write files that do not conform to the specs anyway, so a  
> good
>    reader will either have to throw an error in that case, or he will  
> have to
>    handle it.
>    - When we choose the writer-friendly way, we can not guarantee that  
> all
>    readers can actually handle all possible cases. Library functions that
>    support a reader may help, but it will not be possible to cover all
>    possible cases in such a function.
>    - I would expect that more people will program tools that read h5md
>    files than people that program tools to write h5md files. Furthermore,
>    people that create such files are probably more used to stick to  
> specs than
>    people that read them. Insofar it might make sense to make h5md
>    reader-friendly rather than writer-friendly.
>
> Any opinions on that?
>
> Olaf

Thanks for elaborating your thoughts. It precisely hits the point of many
of the discussions.

I agree that H5MD has been developed with having the "writer-friendly"
goal in mind. Maybe because at that time more writer software existed than
readers. I would like to add two more concerns:

* reader-friendly makes the format less flexible, as only a specific
situation is allowed. Example: if the writer just dumps the raw particle
data (reduced + image), the reader has to extend them to absolute
coordinates and may even have to sort the data bringing them back in the
initial order. Or the writer does the job (which doesn'
t hurt because it runs in parallel) and the simple-minded reader is happy.
Different people prefer different solutions.

* many analysis tools will be programmed for a specific purpose and will
probably process output only from a specific simulation software. If they
don't cover all cases, that's fine. If such a tool shall become portable,
of course, it would need extensions.

Thus I think that flexibility writer-wise beats simplicity reader-wise.

Felix