[Dune] hdf5 finite element data standard for Dune
Patrick Leidenberger
patrick.leidenberger at psi.ch
Mon Sep 25 10:24:55 CEST 2006
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: aqpsi2006mar22.pdf
Type: application/pdf
Size: 125764 bytes
Desc: not available
URL: <https://lists.dune-project.org/pipermail/dune/attachments/20060925/e6abf46f/attachment.pdf>
More information about the Dune
mailing list