[Dune] Problems with GMSH reader and ALUGrid

[Jö Fahlke]

Am Fri,  3. Feb 2012, 15:32:05 +0000 schrieb Sacconi, Andrea:
> I'm trying to build a grid of type ALUGrid starting from a .msh file.
> My computational mesh is made only of tetrahedra, and has Physical entities, since when I wrote that file I needed them.

What Dune version are you using?  Trunk?  2.1 (svn or tarball)?

> Anyway, I can't manage to understand why it doesn't work. This (criptic) error appears on my screen:
> 
> Reading 3d Gmsh grid...
> version 2.2 Gmsh file detected
> terminate called after throwing an instance of 'Dune::IOError'
> Abort trap

I can reproduce, with a somewhat more verbose error message (using trunk from
svn):
======================================================================
joe at paranoia:/tmp$ ~/src/dune-opt/dune-grid/src/gridinfo-gmsh/dune-gridinfo-gmsh-alusimplex-3d cube01_002.msh 
Reading 3d Gmsh grid...
version 2.2 Gmsh file detected
Caught exception of type Dune::Exception
Exception message: Dune::IOError [read:../../dune/grid/io/file/gmshreader.hh:310]: expected $Nodes
terminate called after throwing an instance of 'Dune::IOError'
[paranoia:13332] *** Process received signal ***
[paranoia:13332] Signal: Aborted (6)
[paranoia:13332] Signal code:  (-6)
[paranoia:13332] [ 0] [0xb76eb40c]
[paranoia:13332] [ 1] /lib/i386-linux-gnu/i686/cmov/libc.so.6(abort+0x182) [0xb5eb5d22]
[paranoia:13332] [ 2] /usr/lib/i386-linux-gnu/libstdc++.so.6(_ZN9__gnu_cxx27__verbose_terminate_handlerEv+0x14d) [0xb60f045d]
[paranoia:13332] *** End of error message ***
Abgebrochen
======================================================================

Notice that I didn't use your program, but a utility that comes with
dune-grid.  Looking at the beginning of your .msh:
======================================================================
$MeshFormat
2.2 0 8
$EndMeshFormat
$PhysicalNames
2
2 1 "Dirichlet"
3 2 "Regione_intera"
$EndPhysicalNames
$Nodes
27
1 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00
======================================================================

Physical entities are supported, in priciple.  But apparently naming physical
entities isn't supported by Dune.  At least dune-gridinfo-gmsh-alusimplex-3d
works if I delete the $PhysicalNames...$EndPhysicalNames-section.  So I
suppose this is a bug in the GmshReader: it should at the very least skip such
a section.

Until this is fixed, you should be able to work around the issue by simply
removing the offending section.

> 2) do Physical entities cause troubles in DUNE?

Physical entities are supported, but only by their number, not by their names.

Actually accessing the physical entity names requires additional support from
the GmshReader.  I suppose this could be achieved by providing an additional
object to fill with the physical-entity-name<->physical-entity-number relation
to the reader methods.  But I'm uncertain how such an object should look like
ideally.

> 3) what does the parameter "insert_boundary_segments = true" mean? Is there any relationship with the coding of the .msh file? Does selecting true or false make any difference in reading from a GMSH file?

There are a lot of read() methods in the GmshReader, but basically only two of
them make sense:

  static GridType *read (const std::string &fileName, bool verbose=true,
                         bool insert_boundary_segments=true);
  static void read (Dune::GridFactory< GridType > &factory,
                    const std::string &fileName,
                    std::vector< int > &boundary_id_to_physical_entity,
                    std::vector< int > &element_index_to_physical_entity,
                    bool verbose=true, bool insert_boundary_segments=true);

 * The first may be used if you're not interested in the physical entities.  I
   believe setting insert_boundary_segments=false should never lead to any
   problems for this method.

 * If you are only interested in physical entity numbers of the elements
   (codim-0-entities in Dune speak, e.g. volumes in 3D or faces in 2D) you can
   use the second method with insert_boundary_segments=false.  Anything
   returned in the vector boundary_id_to_physical_entity will be meaningless.

 * If you are interested in physical entity numbers on the boundary, you
   should use the second method with insert_boundary_segments=true.  In this
   case the factory object will be able to associate boundary intersections
   with their insertion index, which in turn can be used as a subscript to the
   vector boundary_id_to_physical_entity.  Not all parts of the boundary need
   to be present in the .msh-file (e.g. if you didn't assign a physical entity
   number), so you should always ask the factory whether a boundary
   intersection was actually inserted:

     if(!is.neighbor() && is.boundary()) {
       int physical_entity;
       if(factory.wasInserted(is))
         physical_entity =
           boundary_id_to_physical_entity[factory.insertionIndex(is)];
       else
         physical_entity = 0;
       // do something
     }

   Note: 0 is a special value used by gmsh to say "this entity doesn't belong
         to any physical entity".  It may appear in a .msh file in place of a
         physical entity number if you don't assign any physical entity, or if
         you force gmsh to write all entities, even if some of them don't
         belong to any physical entity.

   Note: If you call GmshReader::read() like this, you will get the physical
         entity information for the elements whether you want it or not.

 * All other kinds of physical entities (e.g. on interior codim-1-entities, or
   on entities of codim >=2 are not accessible using Dune's GmshReader.

Cheers,
Jö.

-- 
Jorrit (Jö) Fahlke, Interdisciplinary Center for Scientific Computing,
Heidelberg University, Im Neuenheimer Feld 368, D-69120 Heidelberg
Tel: +49 6221 54 8890 Fax: +49 6221 54 8884

Of all the things I've lost, I miss my mind the most.
-- Ozzy Osbourne
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: Digital signature
URL: <https://lists.dune-project.org/pipermail/dune/attachments/20120203/724f0123/attachment.sig>