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!
Victoria,
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.