<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=iso-8859-1" http-equiv=Content-Type>
<META name=GENERATOR content="MSHTML 11.00.9600.18231">
<STYLE></STYLE>
</HEAD>
<BODY
style="WORD-WRAP: break-word; FONT-SIZE: 14px; FONT-FAMILY: Calibri, sans-serif; COLOR: rgb(0,0,0); -webkit-nbsp-mode: space; -webkit-line-break: after-white-space"
bgColor=#ffffff>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>DETECTING HDF5 VERSUS NETCDF GENERATED
FILES<BR>REQUEST FOR COMMENTS </FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=2 face=Arial>AUTHOR: Pedro Vicente</FONT></DIV>
<DIV> </DIV><FONT size=2 face=Arial>
<DIV><BR>AUDIENCE: <BR>1) HDF, netcdf developers, </DIV>
<DIV> </DIV>
<DIV>Ed Hartnett <BR>Kent Yang</DIV>
<DIV> </DIV>
<DIV>2) HDF, netcdf users, that replied to this thread</DIV>
<DIV> </DIV>
<DIV>Miller, Mark C. </DIV>
<DIV>John Shalf </DIV>
<DIV> </DIV>
<DIV>3 ) netcdf tools developers</DIV>
<DIV> </DIV>
<DIV>Mary Haley , NCL</DIV>
<DIV> </DIV>
<DIV>4) HDF, netcdf managers and sponsors</DIV>
<DIV> </DIV>
<DIV>David Pearah , CEO HDF Group<BR>Ward Fisher, UCAR<BR>Marinelli,
Daniel J. , Richard Ullmman, Christopher Lynnes, NASA</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>5)<BR>[CF-metadata] list</DIV>
<DIV> </DIV>
<DIV>After this thread started 2 months ago, there was an annoucement on the
[CF-metadata] mail list<BR>about<BR>"a meeting to discuss current and future
netCDF-CF efforts and directions. <BR>The meeting will be held on 24-26 May 2016
in Boulder, CO, USA at the UCAR Center Green facility."</DIV>
<DIV> </DIV>
<DIV>This would be a good topic to put on the agenda, maybe?</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>THE PROBLEM:</DIV>
<DIV> </DIV>
<DIV>Currently it is impossible to detect if an HDF5 file was generated by the
HDF5 API or by the netCDF API.</DIV>
<DIV>See previous email about the reasons why.</DIV>
<DIV> </DIV>
<DIV>WHY THIS MATTERS:</DIV>
<DIV> </DIV>
<DIV>Software applications that need to handle both netCDF and HDF5 files cannot
decide which API to use.<BR>This includes popular visualization tools like IDL,
Matlab, NCL, HDF Explorer.</DIV>
<DIV> </DIV>
<DIV>SOLUTIONS PROPOSED: 2</DIV>
<DIV> </DIV>
<DIV>SOLUTION 1: Add a flag to HDF5 source </DIV>
<DIV> </DIV>
<DIV>The hdf5 format specification, listed here</DIV>
<DIV> </DIV>
<DIV><A
href="https://www.hdfgroup.org/HDF5/doc/H5.format.html">https://www.hdfgroup.org/HDF5/doc/H5.format.html</A></DIV>
<DIV> </DIV>
<DIV>describes a sequence of bytes in the file layout that have special meaning
for the HDF5 API. It is common practice, when designing a data format, <BR>so
leave some fields "reserved for future use".</DIV>
<DIV> </DIV>
<DIV>This solution makes use of one of these empty "reserved for future
use" spaces to save a byte (for example) that describes an enumerator<BR>of
"HDF5 compatible formats".</DIV>
<DIV> </DIV>
<DIV>An "HDF5 compatible format" is a data format that uses the HDF5 API at a
lower level (usually hidden from the user of the upper API),<BR>and providing
its own API.</DIV>
<DIV> </DIV>
<DIV>This category can still be divide in 2 formats:<BR>1) A "pure HDF5
compatible format". Example, NeXus</DIV>
<DIV> </DIV>
<DIV><A href="http://www.nexusformat.org/">http://www.nexusformat.org/</A></DIV>
<DIV> </DIV>
<DIV>NeXus just writes some metadata (attributes) on top of the HDF5 API, that
has some special meaning for the NeXus community</DIV>
<DIV> </DIV>
<DIV>2) A "non pure HDF5 compatible format". Example, netCDF</DIV>
<DIV> </DIV>
<DIV>Here, the format adds some extra feature besides HDF5. In the case of
netCDF, these are shared dimensions between variables.</DIV>
<DIV> </DIV>
<DIV>This sub-division between 1) and 2) is irrelevant for the problem and
solution in question</DIV>
<DIV> </DIV>
<DIV>The solution consists of writing a different enumerator value on the
"reserved for future use" space. For example</DIV>
<DIV> </DIV>
<DIV>Value decimal 0 (current value): This file was generated by the HDF5 API
(meaning the HDF5 only API)<BR>Value decimal 1: This file was generated by the
netCDF API (using HDF5) <BR>Value decimal 2: This file was generated by <put
here another HDF5 based format><BR>and so on</DIV>
<DIV> </DIV>
<DIV>The advantage of this solution is that this process involves 2 parties: the
HDF Group and the other format's organization.</DIV>
<DIV> </DIV>
<DIV>This allows the HDF Group to "keep track" of new HDF5 based formats.
It allows to make the other format "HDF5 certified" .</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>SOLUTION 2: Add some metadata to the other API on top of HDF5</DIV>
<DIV> </DIV>
<DIV>This is what Nexus uses. <BR>A Nexus file on creation writes several
attributes on the root group, like "NeXus_version" and other numeric data.
<BR>This is done using the public HDF5 API calls.</DIV>
<DIV> </DIV>
<DIV>The solution for netCDF consists of the same approach, just write some
specific attributes, and a special netCDF API to write/read them.</DIV>
<DIV> </DIV>
<DIV>This solutions just requires the work of one party (the netCDF group)</DIV>
<DIV> </DIV>
<DIV>END OF RFC</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>In reply to people that commented in the thread</DIV>
<DIV> </DIV>
<DIV>@John Shalf </DIV>
<DIV> </DIV>
<DIV>>>Perhaps NetCDF (and other higher-level APIs that are built on top
of HDF5) should include an attribute attached <BR>>>to the root group that
identifies the name and version of the API that created the file? (adopt
this as a convention)</DIV>
<DIV> </DIV>
<DIV>yes, that's one way to do it, Solution 2 above</DIV>
<DIV> </DIV>
<DIV>@Mark Miller</DIV>
<DIV> </DIV>
<DIV>>>>Hmmm. Is there any big reason NOT to try to read a netCDF
produced HDF5 file with the native HDF5 library if someone so chooses?</DIV>
<DIV> </DIV>
<DIV>It's possible to read a netCDF file using HDF5, yes. <BR>There are 2 things
that you will miss doing this:<BR></DIV>
<DIV>1) the ability to inquire about shared netCDF dimensions. <BR>2) the
ability to read remotely with openDAP. <BR>Reading with HDF5 also exposes
metadata that is supposed to be private to netCDF. See below</DIV>
<DIV> </DIV>
<DIV>>>>> And, attempting to read an HDF5 file produced by
Silo using just the HDF5 library (e.g. w/o Silo) is a major pain.</DIV>
<DIV> </DIV>
<DIV>This I don't understand. Why not read the Silo file with the Silo
API?</DIV>
<DIV> </DIV>
<DIV>That's the all purpose of this issue, each higher level API on top of HDF5
should be able to detect "itself".<BR>I am not familiar with Silo, but if Silo
cannot do this, then you have the same design flaw that netCDF has.</DIV>
<DIV> </DIV>
<DIV><BR>>>> In a cursory look over the libsrc4 sources in netCDF
distro, I see a few things that might give a hint a file was created with
netCDF. . .<BR>>>>> First, in NC_CLASSIC_MODEL, an attribute gets
attached to the root group named "_nc3_strict". So, the existence of an
attribute on the root group by that name would suggest the HDF5 file was
generated by netCDF.</DIV>
<DIV> </DIV>
<DIV>I think this is done only by the "old" netCDF3 format. </DIV>
<DIV> </DIV>
<DIV>>>>>> Also, I tested a simple case of nc_open, nc_def_dim,
etc. nc_close to see what it produced.<BR>>>>> It appears to produce
datasets for each 'dimension' defined with two attributes named "CLASS" and
"NAME". </DIV>
<DIV> </DIV>
<DIV>This is because netCDF uses the HDF5 Dimension Scales API internally to
keep track of shared dimensions. These are internal attributes <BR>of Dimension
Scales. This approach would not work because an HDF5 only file with Dimension
Scales would have the same attributes.</DIV>
<DIV> </DIV>
<DIV><BR>>>>> I like John's suggestion
here.<BR>>>>>>But, any code you add to any applications now will
work *only* for files that were produced post-adoption of this convention.</DIV>
<DIV> </DIV>
<DIV>yes. there are 2 actions to take here. <BR>1) fix the issue for the
future<BR>2) try to retroactively have some workaround that makes possible now
to differentiate a HDF5/netCDF files made before the adopted convention<BR>see
below </DIV>
<DIV> </DIV>
<DIV><BR>>>>> In VisIt, we support >140 format readers. Over 20
of those are different variants of HDF5 files (H5part, Xdmf, Pixie, Silo,
Samrai, netCDF, Flash, Enzo, Chombo, etc., etc.) <BR>>>>>When
opening a file, how does VisIt figure out which plugin to use? In particular,
how do we avoid one poorly written reader plugin (which may be the wrong one for
a given file) from preventing the correct one from being found. Its kinda a hard
problem.</DIV>
<DIV> </DIV>
<DIV><BR>Yes, that's the problem we are trying to solve. I have to say, that is
quick a list of HDF5 based formats there. </DIV>
<DIV> </DIV>
<DIV>>>>> Some of our discussion is captured here. . .<BR><A
href="http://www.visitusers.org/index.php?title=Database_Format_Detection">http://www.visitusers.org/index.php?title=Database_Format_Detection</A></DIV>
<DIV> </DIV>
<DIV>I"ll check it out, thank you for the suggestions</DIV>
<DIV> </DIV>
<DIV>@Ed Hartnett </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>>>>I must admit that when putting netCDF-4 together I never
considered that someone might want to tell the difference between a "native"
HDF5 file and a netCDF-4/HDF5 file. </DIV>
<DIV>>>>>>Well, you can't think of everything.</DIV>
<DIV> </DIV>
<DIV>This is a major design flaw.<BR>If you are in the business of designing
data file formats, one of the things you have to do is how to make it possible
to identify it from the other formats.</DIV>
<DIV> </DIV>
<DIV><BR>>>> I agree that it is not possible to canonically tell the
difference. The netCDF-4 API does use some special attributes to track named
dimensions, <BR>>>>>and to tell whether classic mode should be
enforced. But it can easily produce files without any named dimensions, etc.
<BR>>>>So I don't think there is any easy way to tell.</DIV>
<DIV> </DIV>
<DIV>I remember you wrote that code together with Kent Yang from the HDF Group.
<BR>At the time I was with the HDF Group but unfortunately I did follow closely
what you were doing.<BR>I don't remember any design document being circulated
that explains the internals of the "how to" make the netCDF (classic) model of
shared dimensions<BR>use the hierarchical group model of HDF5.<BR>I know this
was done using the HDF5 Dimension Scales (that I wrote), but is there any design
document that explains it?</DIV>
<DIV> </DIV>
<DIV>Maybe just some internal email exchange between you and Kent Yang?<BR>Kent,
how are you? <BR>Do you remember having any design document that explains
this?<BR>Maybe something like a unique private attribute that is written
somewhere in the netCDF file?</DIV>
<DIV> </DIV>
<DIV><BR>@Mary Haley, NCL</DIV>
<DIV> </DIV>
<DIV>NCL is a widely used tool that handles both netCDF and HDF5</DIV>
<DIV> </DIV>
<DIV>Mary, how are you?<BR>How does NCL deal with the case of reading both pure
HDF5 files and netCDF files that use HDF5?<BR>Would you be interested in joining
a community based effort to deal with this, in case this is an issue for
you?</DIV>
<DIV> </DIV>
<DIV><BR>@David Pearah , CEO HDF Group</DIV>
<DIV> </DIV>
<DIV>I volunteer to participate in the effort of this RFC together with the HDF
Group (and netCDF Group). </DIV>
<DIV>Maybe we could make a "task force" between HDF Group, netCDF Group and any
volunteer (such as tools developers that happen to be in these mail
lists)?</DIV>
<DIV> </DIV>
<DIV>The "task force" would have 2 tasks: </DIV>
<DIV>1) make a HDF5 based convention for the future and </DIV>
<DIV>2) try to retroactively salvage the current design issue of netCDF<BR>My
phone is 217-898-9356, you are welcome to call in anytime.</DIV>
<DIV> </DIV>
<DIV></FONT><FONT size=2 face=Arial>----------------------<BR>Pedro
Vicente<BR><A
href="mailto:pedro.vicente@space-research.org">pedro.vicente@space-research.org</A><BR><A
href="https://twitter.com/_pedro__vicente">https://twitter.com/_pedro__vicente</A><BR><A
href="http://www.space-research.org/">http://www.space-research.org/</A></FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<BLOCKQUOTE
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; PADDING-RIGHT: 0px; MARGIN-RIGHT: 0px">
<DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
<DIV
style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B>
<A title=miller86@llnl.gov href="mailto:miller86@llnl.gov">Miller, Mark C.</A>
</DIV>
<DIV style="FONT: 10pt arial"><B>To:</B> <A title=hdf-forum@lists.hdfgroup.org
href="mailto:hdf-forum@lists.hdfgroup.org">HDF Users Discussion List</A>
</DIV>
<DIV style="FONT: 10pt arial"><B>Cc:</B> <A title=netcdfgroup@unidata.ucar.edu
href="mailto:netcdfgroup@unidata.ucar.edu">netcdfgroup@unidata.ucar.edu</A> ;
<A title=wfisher@ucar.edu href="mailto:wfisher@ucar.edu">Ward Fisher</A>
</DIV>
<DIV style="FONT: 10pt arial"><B>Sent:</B> Wednesday, March 02, 2016 7:07
PM</DIV>
<DIV style="FONT: 10pt arial"><B>Subject:</B> Re: [Hdf-forum] Detecting netCDF
versus HDF5</DIV>
<DIV><BR></DIV>
<DIV>I like John's suggestion here.</DIV>
<DIV><BR></DIV>
<DIV>But, any code you add to any applications now will work *only* for files
that were produced post-adoption of this convention.</DIV>
<DIV><BR></DIV>
<DIV>There are probably a bazillion files out there at this point that don't
follow that convention and you probably still want your applications to be
able to read them.</DIV>
<DIV><BR></DIV>
<DIV>In VisIt, we support >140 format readers. Over 20 of those are
different variants of HDF5 files (H5part, Xdmf, Pixie, Silo, Samrai, netCDF,
Flash, Enzo, Chombo, etc., etc.) When opening a file, how does VisIt figure
out which plugin to use? In particular, how do we avoid one poorly written
reader plugin (which may be the wrong one for a given file) from preventing
the correct one from being found. Its kinda a hard problem.</DIV>
<DIV><BR></DIV>
<DIV>Some of our discussion is captured here. . .</DIV>
<DIV><BR></DIV>
<DIV><A
href="http://www.visitusers.org/index.php?title=Database_Format_Detection">http://www.visitusers.org/index.php?title=Database_Format_Detection</A></DIV>
<DIV><BR></DIV>
<DIV>Mark</DIV>
<DIV><BR></DIV>
<DIV><BR></DIV><SPAN id=OLK_SRC_BODY_SECTION>
<DIV
style="FONT-SIZE: 11pt; BORDER-TOP: #b5c4df 1pt solid; FONT-FAMILY: Calibri; BORDER-RIGHT: medium none; BORDER-BOTTOM: medium none; COLOR: black; PADDING-BOTTOM: 0in; TEXT-ALIGN: left; PADDING-TOP: 3pt; PADDING-LEFT: 0in; BORDER-LEFT: medium none; PADDING-RIGHT: 0in"><SPAN
style="FONT-WEIGHT: bold">From: </SPAN>Hdf-forum <<A
href="mailto:hdf-forum-bounces@lists.hdfgroup.org">hdf-forum-bounces@lists.hdfgroup.org</A>>
on behalf of John Shalf <<A
href="mailto:jshalf@lbl.gov">jshalf@lbl.gov</A>><BR><SPAN
style="FONT-WEIGHT: bold">Reply-To: </SPAN>HDF Users Discussion List <<A
href="mailto:hdf-forum@lists.hdfgroup.org">hdf-forum@lists.hdfgroup.org</A>><BR><SPAN
style="FONT-WEIGHT: bold">Date: </SPAN>Wednesday, March 2, 2016 1:02
PM<BR><SPAN style="FONT-WEIGHT: bold">To: </SPAN>HDF Users Discussion List
<<A
href="mailto:hdf-forum@lists.hdfgroup.org">hdf-forum@lists.hdfgroup.org</A>><BR><SPAN
style="FONT-WEIGHT: bold">Cc: </SPAN>"<A
href="mailto:netcdfgroup@unidata.ucar.edu">netcdfgroup@unidata.ucar.edu</A>"
<<A
href="mailto:netcdfgroup@unidata.ucar.edu">netcdfgroup@unidata.ucar.edu</A>>,
Ward Fisher <<A
href="mailto:wfisher@ucar.edu">wfisher@ucar.edu</A>><BR><SPAN
style="FONT-WEIGHT: bold">Subject: </SPAN>Re: [Hdf-forum] Detecting netCDF
versus HDF5<BR></DIV>
<DIV><BR></DIV>
<BLOCKQUOTE id=MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE
style="PADDING-BOTTOM: 0px; PADDING-TOP: 0px; PADDING-LEFT: 5px; MARGIN: 0px 0px 0px 5px; BORDER-LEFT: #b5c4df 5px solid; PADDING-RIGHT: 0px">
<DIV>
<DIV>
<DIV>Perhaps NetCDF (and other higher-level APIs that are built on top of
HDF5) should include an attribute attached to the root group that identifies
the name and version of the API that created the file? (adopt
this as a convention)</DIV>
<DIV><BR></DIV>
<DIV>-john</DIV>
<DIV><BR></DIV>
<BLOCKQUOTE id=MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE
style="PADDING-BOTTOM: 0px; PADDING-TOP: 0px; PADDING-LEFT: 5px; MARGIN: 0px 0px 0px 5px; BORDER-LEFT: #b5c4df 5px solid; PADDING-RIGHT: 0px">
<DIV>On Mar 2, 2016, at 12:55 PM, Pedro Vicente <<A
href="mailto:pedro.vicente@space-research.org">pedro.vicente@space-research.org</A>>
wrote:</DIV>
<DIV></DIV>
<DIV></DIV>
<DIV>Hi Ward</DIV>
<DIV></DIV>
<DIV>As you know, Data Explorer is going to be a general purpose data
reader for many formats, including HDF5 and netCDF.</DIV>
<DIV></DIV>
<DIV>Here</DIV>
<DIV></DIV>
<DIV><A
href="http://www.space-research.org/">http://www.space-research.org/</A></DIV>
<DIV></DIV>
<DIV></DIV>
<DIV>Regarding the handling of both HDF5 and netCDF, it seems there is a
potential issue, which is, how to tell if any HDF5 file was saved by the
HDF5 API or by the netCDF API?</DIV>
<DIV></DIV>
<DIV>It seems to me that this is not possible. Is this correct?</DIV>
<DIV></DIV>
<DIV>netCDF uses an internal function NC_check_file_type to examine the
first few bytes of a file, and for example for any HDF5 file the test
is</DIV>
<DIV></DIV>
<DIV>/* Look at the magic number */</DIV>
<DIV> /* Ignore the first byte for HDF */</DIV>
<DIV> if(magic[1] == 'H' && magic[2] == 'D' &&
magic[3] == 'F') {</DIV>
<DIV> *filetype = FT_HDF;</DIV>
<DIV> *version = 5;</DIV>
<DIV></DIV>
<DIV>The problem is that this test works for any HDF5 file and for any
netCDF file, which makes it impossible to tell which is which.</DIV>
<DIV></DIV>
<DIV>Which makes it impossible for any general purpose data reader to
decide to use the netCDF API or the HDF5 API.</DIV>
<DIV></DIV>
<DIV>I have a possible solution for this , but before going any further, I
would just like to confirm that</DIV>
<DIV></DIV>
<DIV>1) Is indeed not possible</DIV>
<DIV></DIV>
<DIV>2) See if you have a solid
workaround for this, excluding the dumb ones, for example deciding on a
extension .nc or .h5, or traversing the HDF5 file to see if it's non
netCDF conforming one. Yes, to further complicate things, it is possible
that the above test says OK for a HDF5 file, but then the read by the
netCDF API fails because the file is a HDF5 non netCDF conformant</DIV>
<DIV></DIV>
<DIV>Thanks</DIV>
<DIV></DIV>
<DIV>----------------------</DIV>
<DIV>Pedro Vicente</DIV>
<DIV><A
href="mailto:pedro.vicente@space-research.org">pedro.vicente@space-research.org</A></DIV>
<DIV><A
href="http://www.space-research.org/">http://www.space-research.org/</A>
</DIV>
<DIV></DIV>
<DIV>_______________________________________________</DIV>
<DIV>Hdf-forum is for HDF software users discussion.</DIV>
<DIV><A
href="mailto:Hdf-forum@lists.hdfgroup.org">Hdf-forum@lists.hdfgroup.org</A></DIV>
<DIV><A
href="http://secure-web.cisco.com/1r-EJFFfg6rWlpQsvXstBNTjaHQaKT_NkYRN0Jj_f-Z3EK0-hs6IbYc8XUBRyPsH3mU3CS0iiY7_qnchCA0QxNzQt270d_2HikCwpAWFmuHdacin62eaODutktDSOULIJmVbVYqFVSKWPzoX7kdP0yN9wIzSFxZfTwfhU8ebsN409xRg1PsW_8cvNiWzxDNm9wv9yBf9yK6nkEm-bOx2S0kBLbg9WfIChWzZrkpE3AHU9I-c2ZRH_IN-UF4g_g0_Dh4qE1VETs7tZTfKd1ox1MtBmeyKf7EKUCd3ezR9EbI5tK4hCU5qW4v5WWOxOrD17e8yCVmob27xz84Lr3bCK5wIQdH5VzFRTtyaAhudpt9E/http%3A%2F%2Flists.hdfgroup.org%2Fmailman%2Flistinfo%2Fhdf-forum_lists.hdfgroup.org">http://secure-web.cisco.com/1r-EJFFfg6rWlpQsvXstBNTjaHQaKT_NkYRN0Jj_f-Z3EK0-hs6IbYc8XUBRyPsH3mU3CS0iiY7_qnchCA0QxNzQt270d_2HikCwpAWFmuHdacin62eaODutktDSOULIJmVbVYqFVSKWPzoX7kdP0yN9wIzSFxZfTwfhU8ebsN409xRg1PsW_8cvNiWzxDNm9wv9yBf9yK6nkEm-bOx2S0kBLbg9WfIChWzZrkpE3AHU9I-c2ZRH_IN-UF4g_g0_Dh4qE1VETs7tZTfKd1ox1MtBmeyKf7EKUCd3ezR9EbI5tK4hCU5qW4v5WWOxOrD17e8yCVmob27xz84Lr3bCK5wIQdH5VzFRTtyaAhudpt9E/http%3A%2F%2Flists.hdfgroup.org%2Fmailman%2Flistinfo%2Fhdf-forum_lists.hdfgroup.org</A></DIV>
<DIV>Twitter: <A
href="https://twitter.com/hdf5">https://twitter.com/hdf5</A></DIV></BLOCKQUOTE>
<DIV><BR></DIV>
<DIV><BR></DIV>
<DIV>_______________________________________________</DIV>
<DIV>Hdf-forum is for HDF software users discussion.</DIV>
<DIV><A
href="mailto:Hdf-forum@lists.hdfgroup.org">Hdf-forum@lists.hdfgroup.org</A></DIV>
<DIV><A
href="http://secure-web.cisco.com/1r-EJFFfg6rWlpQsvXstBNTjaHQaKT_NkYRN0Jj_f-Z3EK0-hs6IbYc8XUBRyPsH3mU3CS0iiY7_qnchCA0QxNzQt270d_2HikCwpAWFmuHdacin62eaODutktDSOULIJmVbVYqFVSKWPzoX7kdP0yN9wIzSFxZfTwfhU8ebsN409xRg1PsW_8cvNiWzxDNm9wv9yBf9yK6nkEm-bOx2S0kBLbg9WfIChWzZrkpE3AHU9I-c2ZRH_IN-UF4g_g0_Dh4qE1VETs7tZTfKd1ox1MtBmeyKf7EKUCd3ezR9EbI5tK4hCU5qW4v5WWOxOrD17e8yCVmob27xz84Lr3bCK5wIQdH5VzFRTtyaAhudpt9E/http%3A%2F%2Flists.hdfgroup.org%2Fmailman%2Flistinfo%2Fhdf-forum_lists.hdfgroup.org">http://secure-web.cisco.com/1r-EJFFfg6rWlpQsvXstBNTjaHQaKT_NkYRN0Jj_f-Z3EK0-hs6IbYc8XUBRyPsH3mU3CS0iiY7_qnchCA0QxNzQt270d_2HikCwpAWFmuHdacin62eaODutktDSOULIJmVbVYqFVSKWPzoX7kdP0yN9wIzSFxZfTwfhU8ebsN409xRg1PsW_8cvNiWzxDNm9wv9yBf9yK6nkEm-bOx2S0kBLbg9WfIChWzZrkpE3AHU9I-c2ZRH_IN-UF4g_g0_Dh4qE1VETs7tZTfKd1ox1MtBmeyKf7EKUCd3ezR9EbI5tK4hCU5qW4v5WWOxOrD17e8yCVmob27xz84Lr3bCK5wIQdH5VzFRTtyaAhudpt9E/http%3A%2F%2Flists.hdfgroup.org%2Fmailman%2Flistinfo%2Fhdf-forum_lists.hdfgroup.org</A></DIV>
<DIV>Twitter: <A
href="https://twitter.com/hdf5">https://twitter.com/hdf5</A></DIV>
<DIV><BR></DIV>
<DIV><BR></DIV></DIV></DIV></BLOCKQUOTE></SPAN>
<P>
<HR>
<P></P>_______________________________________________<BR>Hdf-forum is for HDF
software users
discussion.<BR>Hdf-forum@lists.hdfgroup.org<BR>http://lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org<BR>Twitter:
https://twitter.com/hdf5</BLOCKQUOTE></BODY></HTML>