GMesh 1D mesh input error

[Victoria W.]

Hello, 

I've been getting the following error message when I try and input a 1D mesh in 2D space for a boundary element method simulation.  I'm working with step-34 tutorial program to model an electric field on an electrode, but I can't get past this mesh input step.  I have tried all of the mesh types that gmsh can output and that dealii will except.  Has anyone seen this before, and does anyone have advice for me?  Thank you to anyone who can help or give advice! 

[David Wells]

Hi Victoria,

It's difficult to tell what is going on without seeing some code but this looks like a bug in deal.II: that's the correct GridIn function and everything should be at the boundary but the assertion still fails for reasons that appear to be wrong.

Can you reproduce the same error if you use that mesh with step-34, where you only modify the call to gi.read_ucd() to gi.read_msh()? If so, would you please post the mesh to this thread?

Best,

David

--
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/63e62794-13a9-4562-9d60-4568681c077eo%40googlegroups.com.

[Victoria W.]

Hi David, 

I've been using read_msh() with a version 1 gmsh 1D mesh for the boundary definition.  Attaching the code snipped of my read_domain() function and the mesh here.  Thank you for your help.

Best, Victoria 

On Thursday, June 18, 2020 at 9:35:59 AM UTC-4, David Wells wrote:

Hi Victoria,

It's difficult to tell what is going on without seeing some code but this looks like a bug in deal.II: that's the correct GridIn function and everything should be at the boundary but the assertion still fails for reasons that appear to be wrong.

Can you reproduce the same error if you use that mesh with step-34, where you only modify the call to gi.read_ucd() to gi.read_msh()? If so, would you please post the mesh to this thread?

Best,

David

On Wed, Jun 17, 2020 at 1:28 PM Victoria W. <wied...@gmail.com> wrote:

Hello, 

I've been getting the following error message when I try and input a 1D mesh in 2D space for a boundary element method simulation.  I'm working with step-34 tutorial program to model an electric field on an electrode, but I can't get past this mesh input step.  I have tried all of the mesh types that gmsh can output and that dealii will except.  Has anyone seen this before, and does anyone have advice for me?  Thank you to anyone who can help or give advice! 

--
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 dea...@googlegroups.com.

[David Wells]

Hi Victoria,

This is definitely a bug with our gmsh reader - the problem is it assigns the boundary ids of 0 to all nodes (since they are associated with a material id of 0), which doesn't make sense since none of the given elements are actually boundary elements. My best guess is that we never tested this code with 1D meshes with nonzero codimension.

The fix to the GMSH code is not immediately obvious. As a temporary workaround, would it be possible for you to convert your mesh to a .inp? That reader seems to work correctly for the dim = 1 spacedim = 2 combination.

Best,

David

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/0c04e288-82dd-4f2b-b873-ebafbe49987co%40googlegroups.com.

[Victoria W.]

Hi David, 

Thank you for getting back to me.  I've tried with a .inp mesh produced by both gmsh and freeCAD, but I get the same error with my .inp gmsh export and when I use the FreeCAD export I have to use the read_abaqus() read in method which has been giving me a bad_alloc error message.  I even tried writing the 1D mesh from scratch by looking at the tutorial mesh, but that also produced a GridIn error.  Do you have any other program suggestions for exporting the mesh?  I'm currently installing Salome and looking to try that next, but please let me know if there's something else I should be using. 

Thank you and all the best, 

Victoria 

To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/0c04e288-82dd-4f2b-b873-ebafbe49987co%40googlegroups.com.

[luca.heltai]

This may be a problem with your physical ids. Can you remove all physical ids from the geo file, and try to export a “bare” mesh, without material id/boundary id information?

I currently use vtk for all my needs.

L.

> On 24 Jun 2020, at 14:53, Victoria W. <wied...@gmail.com> wrote:
>
> Hi David,
>
> Thank you for getting back to me. I've tried with a .inp mesh produced by both gmsh and freeCAD, but I get the same error with my .inp gmsh export and when I use the FreeCAD export I have to use the read_abaqus() read in method which has been giving me a bad_alloc error message. I even tried writing the 1D mesh from scratch by looking at the tutorial mesh, but that also produced a GridIn error. Do you have any other program suggestions for exporting the mesh? I'm currently installing Salome and looking to try that next, but please let me know if there's something else I should be using.
>
> Thank you and all the best,
> Victoria
>
> On Tuesday, June 23, 2020 at 12:36:01 PM UTC-4, David Wells wrote:
> Hi Victoria,
>
> This is definitely a bug with our gmsh reader - the problem is it assigns the boundary ids of 0 to all nodes (since they are associated with a material id of 0), which doesn't make sense since none of the given elements are actually boundary elements. My best guess is that we never tested this code with 1D meshes with nonzero codimension.
>
> The fix to the GMSH code is not immediately obvious. As a temporary workaround, would it be possible for you to convert your mesh to a .inp? That reader seems to work correctly for the dim = 1 spacedim = 2 combination.
>
> Best,
> David
>
> On Thu, Jun 18, 2020 at 10:17 AM Victoria W. <wied...@gmail.com> wrote:
> Hi David,
>
> I've been using read_msh() with a version 1 gmsh 1D mesh for the boundary definition. Attaching the code snipped of my read_domain() function and the mesh here. Thank you for your help.
>
> Best, Victoria
>
>

> On Thursday, June 18, 2020 at 9:35:59 AM UTC-4, David Wells wrote:
> Hi Victoria,
>
> It's difficult to tell what is going on without seeing some code but this looks like a bug in deal.II: that's the correct GridIn function and everything should be at the boundary but the assertion still fails for reasons that appear to be wrong.
>
> Can you reproduce the same error if you use that mesh with step-34, where you only modify the call to gi.read_ucd() to gi.read_msh()? If so, would you please post the mesh to this thread?
>
> Best,
> David
>
> On Wed, Jun 17, 2020 at 1:28 PM Victoria W. <wied...@gmail.com> wrote:
> Hello,
>
> I've been getting the following error message when I try and input a 1D mesh in 2D space for a boundary element method simulation. I'm working with step-34 tutorial program to model an electric field on an electrode, but I can't get past this mesh input step. I have tried all of the mesh types that gmsh can output and that dealii will except. Has anyone seen this before, and does anyone have advice for me? Thank you to anyone who can help or give advice!
>
>

> --
> 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 dea...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/63e62794-13a9-4562-9d60-4568681c077eo%40googlegroups.com.
>
> --
> 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 dea...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/0c04e288-82dd-4f2b-b873-ebafbe49987co%40googlegroups.com.
>
> --
> 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/688f383d-d44c-47de-819c-fced52432518o%40googlegroups.com.

[Wolfgang Bangerth]

On 6/24/20 6:53 AM, Victoria W. wrote:
>
> Thank you for getting back to me.  I've tried with a .inp mesh produced by
> both gmsh and freeCAD, but I get the same error with my .inp gmsh export and
> when I use the FreeCAD export I have to use the read_abaqus() read in method
> which has been giving me a bad_alloc error message.

That too sounds like a bug. If you give me the file, I'll investigate that as
well.

Was the file you sent earlier the one you're trying to read, or was that just
an example? We know what the offending parts of that file are (all of the type
15 entities) and we can strip those out by hand.

Best
W.

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

[Victoria W.]

Hi Wolfgang, 

That was the file I wanted to use - I also tried this 2D mesh in 3D space attached.  What is a type 15 entity and why did it cause an error?  The same error appeared to be in this .msh file as well. 

Thank you and all the best, 

Victoria 

[Wolfgang Bangerth]

Victoria,

> That was the file I wanted to use - I also tried this 2D mesh in 3D space
> attached.  What is a type 15 entity and why did it cause an error?  The same
> error appeared to be in this .msh file as well.

As mentioned before, it may be possible to remove the "physical entity" things
in gmsh to avoid the problem.

As for the type 15: If you open the mesh file, it has a section that looks
like this:

$ELM
58
1 15 0 1 1 1
2 15 0 2 1 2
3 15 0 3 1 3
4 15 0 4 1 4
5 15 0 6 1 5
6 15 0 7 1 6
7 15 0 8 1 7
8 15 0 9 1 8
9 15 0 10 1 9
10 15 0 11 1 10
11 1 0 1 2 10 11
12 1 0 1 2 11 12
13 1 0 1 2 12 13
14 1 0 1 2 13 5
...

The first column is just a counter, the second column is the "type" of the
object being described. 15 represents individual points, 1 are lines. The
problem is with these 15s, for which we can't figure out what gmsh wants to
tell us with these entries. I suspect that if you remove these 10 lines and
reduce the 58 at the top to 48, that it might actually work. That could give
you a way forward.

[Victoria W.]

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!  

Best, Victoria 

[Wolfgang Bangerth]

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.