Issue with GridIn::read_msh

[krishan...@gmail.com]

I am trying to read a mesh (.msh file) generated by Gmsh (version 4.7.1), but getting an error. I am using the following commands:

      GridIn<dim> grid_in;
      grid_in.attach_triangulation(triangulation);
      std::ifstream input_file("ma_mesh3.msh");           
      grid_in.read_msh(input_file);

The issue is occurring while executing

grid_in.read_msh(input_file)

This is the error message:

Exception on processing:

--------------------------------------------------------
An error occurred in line <1534> of file </home/krishanu/Google_Drive/dealii/dealii_920/dealii-9.2.0/source/grid/grid_in.cc> in function
    void dealii::GridIn<dim, spacedim>::read_msh(std::istream&) [with int dim = 2; int spacedim = 2; std::istream = std::basic_istream<char>]
The violated condition was:
    n_physicals < 2
Additional information:
    More than one tag is not supported!

Am I doing something wrong, or is there any particular version of Gmsh that should be used to generate meshes that are compatible with deal.ii?

Thanks for any help or advice.

[krishan...@gmail.com]

After looking at my .msh file it seems to me that the error might be pointing to the number of physical groups I have in the mesh. I have 4 physical groups which are 4 parts of the boundary with different IDs. If that is the case, I am not sure why n_physical should be less than 2 according to the condition that is violated here.

[luca.heltai]

The error message is telling you that you specified more than one physical tag for the same object. This is not compatible with deal.II, at the moment, as the physical tags are used by deal.II to specify what material id (on cells) or boundary id (on faces and possibly edges) to assign to each element.

Make sure you only assign a single physical id to each volume (surface), and a single physical id to each object on the boundary.

Luca.

> --
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en
> ---
> You received this message because you are subscribed to the Google Groups "deal.II User Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to dealii+un...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/7760fdd1-43b7-41a2-a49c-3ae1e0d6bf7en%40googlegroups.com.

[krishan...@gmail.com]

Hi Luca,

Thanks for the response. I recreated the mesh to make sure that there is no two physical tag for the same object. I found that if I do not set any physical tag, my code is able to read the mesh without any issue. But when I am setting 4 different physical tags to 4 parts of the boundary, I am getting a new error message:

An error occurred in line <2028> of file </home/krishanu/Google_Drive/dealii/dealii_920/dealii-9.2.0/source/grid/grid_in.cc> in function

    void dealii::GridIn<dim, spacedim>::read_msh(std::istream&) [with int dim = 2; int spacedim = 2; std::istream = std::basic_istream<char>]
The violated condition was:

    cells.size() > 0
Additional information:
    (none)

[Daniel Arndt]

Krishan,

Do you have minimal input file to share that shows your problem?

Best,

Daniel

To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/5618975d-f6a4-4c81-8925-d69a1b2734d9n%40googlegroups.com.

[luca.heltai]

Gmsh is a bit arbitrary on how elements are oriented. Deal.II, on the contrary, requires elements to be consistently ordered. If you have generated your geometries with some elementary geometry types, by specifying the bounding faces, make sure you list the faces always in the same order (i.e., clockwise, or anti-clockwise).

The error you see is related to the fact that different physical entities are meshed separately in gmsh, and their orientation is not guaranteed to be consistent. You have to make sure this is consistent by somehow forcing gmsh to use the same orientation everywhere.

L.

> To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/5618975d-f6a4-4c81-8925-d69a1b2734d9n%40googlegroups.com.

[krishan...@gmail.com]

Hello Luca,

Thanks for your suggestion. I was able to figure out an issue regarding the order of elements in the mesh. After fixing that and without using physical groups, I am able to read the mesh, but during computation, it seems at some point deal.ii is finding a negative volume fraction, which I believe could be caused by how Gmsh is storing the node information for the elements. This is the error message:

an error occurred in line <2858> of file </home/krishanu/Google_Drive/dealii/dealii_920/dealii-9.2.0/source/fe/mapping_q_generic.cc> in function

    dealii::CellSimilarity::Similarity dealii::MappingQGeneric<dim, spacedim>::fill_fe_values(const typename dealii::Triangulation<dim, spacedim>::cell_iterator&, dealii::CellSimilarity::Similarity, const dealii::Quadrature<dim>&, const typename dealii::Mapping<dim, spacedim>::InternalDataBase&, dealii::internal::FEValuesImplementation::MappingRelatedData<dim, spacedim>&) const [with int dim = 2; int spacedim = 2; typename dealii::Triangulation<dim, spacedim>::cell_iterator = dealii::TriaIterator<dealii::CellAccessor<2, 2> >; typename dealii::Mapping<dim, spacedim>::InternalDataBase = dealii::Mapping<2, 2>::InternalDataBase]
The violated condition was:
    det > 1e-12 * Utilities::fixed_power<dim>( cell->diameter() / std::sqrt(double(dim)))
Additional information:

    The image of the mapping applied to cell with center [0.219334 0.973857] is distorted. The cell geometry or the mapping are invalid, giving a non-positive volume fraction of -0.000390158 in quadrature point 3.

I am using the GUI of Gmsh to create the mesh, and not sure if there is any way to force Gmsh to store data in the particular format required by deal.ii. So, I was wondering if there is any other meshing softwares that is able to generate mesh data file in the format required by deal.ii. Please let me know if there is any such meshing software whose mesh output is compatible with deal.ii.

Thanks,

Krishanu