[Dune] hdf5 finite element data standard for Dune

[Oliver Sander]

Hi Patrick!
Without having read the proposed draft I'd like to make the
following comment.  Is there a need to define a new file format?
There are dozens of different file formats for finite element
problems out there, do we/you have to create yet another?
To me, creating a new format seems to be a nearsighted thing,
because
a) a lot (LOT!) of thought has gone into the design of
    other formats.  I don't think we will be able to match
    this.  I expect we quickly reach the limit of any format we are
    able to define.
b) no grid generator will write it
c) no visualization tool will read it
d) any new format needs to be documented well for anyone else
    to use it

Therefore I consider it a waste of time to design a new file
format; time that would be better spent implementing a standard
one.  UNLESS, of course, you have a special need that no other
format can fulfill.

The same applies, of course, to DGF.

Cheers,
Oliver

************************************************************************
* Oliver Sander                ** email: sander at mi.fu-berlin.de        *
* Freie Universität Berlin     ** phone: + 49 (30) 838 75217           *
* Institut für Mathematik II   ** URL  : page.mi.fu-berlin.de/~sander  *
* Arnimallee 6                 ** -------------------------------------*
* 14195 Berlin, Germany        ** Member of MATHEON (www.matheon.de)   *
************************************************************************

On Mon, 25 Sep 2006, Patrick Leidenberger wrote:

> Hi all,
>
> At PSI we (Patrick Leidenberger, Benedikt Oswald)
> want to use Dune for the implementation of computational
> electrodynamics problems which is why we have to deal
> with large and complex mesh structures.
> To give you an estimate, we foresee meshes of several
> millions of tets, maybe even tens of millions.
> As we work in the time domain, we wish to store electric
> and magnetic field vectors at every time step; the number of
> timesteps can be in the tens of thousands.
> Furthermore, we need physical materials models, e.g.
> Debye, Drude, Lorentz.
>
>
> To handle them, Benedikt has defined a data standard
> to store meshes, boundaries, dof and materials using the HDF5 data
> standard.
>
> I appended the draft of the standard. This draft is now open for
> discussion,
> Although its original specification has been motivated by computational
> eletrodynamics, we think it useful and attractive for other physical
> fields as well.
> We particularly welcome comments and suggestions which may improve
> consistency
> and simplicity.
>
> I have started to implement an API for this standard and
> integrate it into dune (in a first step only for ALUGrid with
> tetrahedrons). My idea is, to take the dgfparser and change it so, that
> it uses my API to read the hdf5fed file.
>
> But, I need a little help:
>
> The dgfparser writes a file (*.ALUgrid) for ALUGrid. Is there a way to
> init ALUGrid directly (without a file)?
>
> In the write routine for this file the boundary elements are written
> with the following code:
>
>  std::map<EntityKey<int>,int>::iterator pos;
>  for(pos= facemap.begin(); pos!=facemap.end(); ++pos){
>    if (pos->second == 0)
>      out << "E ";
>    else
>      out << -pos->second << " ";
>    if (dimw == 3)
>      out << pos->first.size() << " ";
>    for (int i=0;i<pos->first.size();i++)
>      out << pos->first.origKey(i) << " ";
>    out << std::endl;
>  }
> using the entitykey.hh. I don't understand that part. What is the
> fileformat ALUGrid expect?
>
> What is the reason, for writing for every node a number and a -1 at the
> end of the file with:
>
>  if (dimw == 3)
>    for (int n=0;n<nofvtx;n++) {
>      out << n << " " << -1 << std::endl;
>    }
>
> A very important question:
> How are elements, that I have read in ALUGrid, are numbered if I iterate
> over them with Dune?
> I want to import material parameters as user data in my Dune application
> and the data should belong to the correct element. Will there be
> problems using Dune and ALUGrid in parallel mode? (And for the future: Can
> ALUGrid handle to read files in parallel?)
>
> If I test my read in routine I get the message 'Aborted' from somewhere
> in   Dune::GridPtr<GridType> alusimplexgrid(inputFileName);
> I cannot find the part which produces this output. Some ideas?
>
>
> If you think that this work can be an improvement to dune I will check
> in my work to the dune-grid module. To make the Hdf5fed API in a modular
> way usable, I need some help:
>
> Can somebody integrate a Hdf5fed-switch to the Dune-build-system? I am
> not a expert with the autotools.
>
> The API and a tool to convert gmsh-files in the Hdf5file format is in a
> subdir of H5Part, it is available via svn:
> svn checkout
> svn+ssh://svn@savannah.psi.ch/afs/psi.ch/project/amas/svn/root/amas/H5Part/Hdf5fed/
>
> with password svn. (see: http://h5part.web.psi.ch/Downloading.html).
>
>
> Best wishes and thanks from Patrick and Benedikt
>