On 6/26/20 11:05 AM, Victoria W. wrote:
This fixed my problem in 2d, but I'm still having issues in 3d.  Any other suggestions for getting a .msh file read in when it's a 2d mesh in 3d space? Posting the mesh I want to use here, with the type 15 elements removed.  I've also tried other software and file formats, running into the same issue previously posted about .unv files produced with Salome, so I appreciate any suggestions on reading in a mesh!

I assume that you are talking about the following error:

-------------------------------------------------------- An error occurred in line <2674> of file </home/bangerth/p/deal.II/1/dealii/source/grid/tria.cc> in function static void dealii::internal::TriangulationImplementation::Implementation::create_triangulation(const std::vector<dealii::Point<dim> >&, const std::vector<dealii::CellData<2> >&, const dealii::SubCellData&, dealii::Triangulation<2, spacedim>&) [with int spacedim = 3]
The violated condition was:
    line->boundary_id() != numbers::internal_face_boundary_id
Additional information:
The input data for creating a triangulation contained information about a line with indices 9 and 33 that is described to have boundary indicator 0. However, this is an internal line not located on the boundary. You cannot assign a boundary indicator to it.

If this happened at a place where you call Triangulation::create_triangulation() yourself, you need to check the SubCellData object you pass to this function.

If this happened in a place where you are reading a mesh from a file, then you need to investigate why such a line ended up in the input file. A typical case is a geometry that consisted of multiple parts and for which the mesh generator program assumes that the interface between two parts is a boundary when that isn't supposed to be the case, or where the mesh generator simply assigns 'geometry indicators' to lines at the perimeter of a part that are not supposed to be interpreted as 'boundary indicators'.

The issue here is similar to the previous one, just that now you have a *line* in the interior of a 2d mesh (where previously you had a vertex interior to a 1d mesh) for which the input file specifies boundary values -- even though that line is not actually at the boundary. These lines are now "type 1" entities in the language of the GMSH and look like this:
  33 1 0 1 2 10 34
(GMSH numbers vertices starting at 1, whereas deal.II uses 0, so this is the line that the error message above complains about: the one with vertices 9 and 33.)

In your file, there are 208 such lines (listed under the "$ELM" line, and numbered 33 to 240). If you remove these lines and adjust the number under $ELM from 802 to 594, the file can be read successfully and looks like the one attached.


Wolfgang Bangerth          email:                 bange...@colostate.edu
                           www: http://www.math.colostate.edu/~bangerth/

The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
--- 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 

Reply via email to