h5md-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [h5md-user] Update


From: Peter Colberg
Subject: Re: [h5md-user] Update
Date: Fri, 22 Nov 2013 13:44:34 -0500
User-agent: Mutt/1.5.21 (2010-09-15)

Hi Pierre, hi all,

On Fri, Nov 22, 2013 at 02:28:25PM +0100, Pierre de Buyl wrote:
> 1. encoding. the discussion on encoding was a bit short. While it seems
> technically ok to use UTF8, I think that it might lead to additional issues 
> that
> will hurt both the practical use and the adoption of H5MD. The biggest one is
> that readers supporting the units module must support UTF8, else it makes 
> little
> sense. And I think that the amount of people interested in units is much 
> larger
> than the number of people interested in UTF8.
> 2. the list of units. In relation to the previous point, °C, °F, Ω, ° and Å 
> are
> in danger :-)

It would probably be reasonable to view the unit strings as a data
format, and less as a display format; i.e. choose a single format
based on ASCII, with a single representation of each unit. The data
format can be converted to a display format using udunits2.

> One practical issue I have thought of is that, for instance, if you want to 
> plot
> an observable that has UTF8 units with a viewer (matplotlib or gnuplot) that
> does not support UTF8 completely might trip on units.

Do you have an example that illustrates this issue?

With regard to Python and udunits2, I found the following:

https://code.google.com/p/cfunits-python/

https://github.com/Unidata/UDUNITS-2/issues/3

> The other one is that is may frighten potential users/developers?

I am more frightened of all the published work that is based on
simulations that are based on non-peer-reviewed source code ;-).

At this point, it seems better not to finalize the specification of
the units module. We could keep it at a version 0.*, and add a note
which clarifies that this is a preliminary version. To finalize the
units module, we need proof of some applications; both for writing
(simulation programs) and reading (analysis programs).

Peter



reply via email to

[Prev in Thread] Current Thread [Next in Thread]