StressSolver problem using Comsol mesh

[mark smith]

Hi All,
I'm trying to do a thermal stress problem using a mesh imported from Comsol. To check that it seems to be read OK I have a sif file that only uses the ResultOutputSolver to wite a vtu file where I save the geometry ids. The geometry displays OK in paraview with the colours corresponding to the body numbers once I apply the threshold filter on GeometryIds, so I thought all was good.
When I add the stresssolver I get a bunch of error messages telling me I have degenerate 2D elements see snip below

StressSolve: Bulk assembly done
ERROR:: ElementMetric: Degenerate 2D element: 1890849
ElementMetric: DetG: -2.407E-35
ElementMetric: Node: 1 Coord: 3.597E-02 0.000E+00 -5.830E-04
ElementMetric: Node: 2 Coord: 3.600E-02 0.000E+00 -5.830E-04
ElementMetric: Node: 3 Coord: 3.600E-02 0.000E+00 -6.300E-04
ElementMetric: Node: 4 Coord: 3.600E-02 0.000E+00 -5.830E-04
ElementMetric: Node: 2 dCoord: 3.305E-05 0.000E+00 0.000E+00
ElementMetric: Node: 3 dCoord: 3.305E-05 0.000E+00 -4.700E-05
ElementMetric: Node: 4 dCoord: 3.305E-05 0.000E+00 0.000E+00
ERROR:: ElementMetric: Degenerate 2D element: 1890849
........

now the mesh.header file is this
753649 1658579 438059
6
303 163967
404 274092
504 1110885
605 128125
706 27615
808 391954

so there are only 1658579 elements so element 1890849 is out of range, has anyone any idea what the problem might be?
the full logfile is attached. Admittedly the build is not upto date ;-(

Any suggestions?

Regards
Mark

[mzenker]

Hi,

I have almost exactly the same problem at the moment: Elmersolver complains about degenerate 2D elements. Example log extract:

Code: Select all

ERROR:: ElementMetric: Degenerate 2D element: 1
ElementMetric: DetG:  -1.323E-23
ElementMetric: Node: 1 Coord:   0.000E+00  -3.120E+00   2.495E+01
ElementMetric: Node: 2 Coord:   0.000E+00  -3.103E+00   2.494E+01
ElementMetric: Node: 3 Coord:   0.000E+00  -3.102E+00   2.496E+01
ElementMetric: Node: 2 dCoord:   0.000E+00   1.705E-02  -9.800E-03
ElementMetric: Node: 3 dCoord:   0.000E+00   1.883E-02   1.330E-02
ERROR:: ElementMetric: Degenerate 2D element: 1

I am trying to prepare a testcase (cannot share my "real" geometry) which I will post as soon as I can reproduce the problem.
I use the HeatSolver, and my mesh was built with gmsh using a Salomé partition exported as brep. So neither the solver modules nor the specific meshers are to blame.Both meshes seem to have the same problem. The strange thing is that the elements I have examined seem not to be distorted. My mesh width is between 0.02 and 5 units in gmsh, and I do use Coordinate Scaling = 0.001.
I will try to build and post my testcase tomorrow. In the meantime if someone has an idea...

Matthias

[raback]

Hi

Difficult to say without a case. Both seem to be problems with 2D boundary elements. And indeed the output does not immediately imply degenerate element. Closer inspection is needed.

-Peter

[mzenker]

Hi Peter,

here is a test case reproducing the problem. I think I have an indication where to look for possible causes: The test geometry lies in the yz plane, just as my "real" geometry does. If I take the same test geometry in the xy plane and mesh it, the case runs without problems. I did not turn the mesh itself, however. I am running out of time for today - on monday, I will turn my "real" geometry, see if this makes the problem go away, and report back.

So in the attachment you will find a test case producing lots of "Degenerate Element" errors. I also attach the gmsh file "Test_geo_degenerate.msh" which has been used in the testcase. If you replace it by the second gmsh file "Test_geo.msh", convert and run (case.sif is identical), the errors do not occur.

If really the problem has to do with the 2D mesh not lying in the xy plane, then it would at least be good to know that this is definitively the case.

Thanks,

Matthias

[mark smith]

Hi All,
Well I have tracked down something which may or maynot be a problem.
In my mesh I have a transitional layer of pyramids and tets which mate up a hexahedral mesh above with a tetrahedral mesh below, now some of the outer faces of this transitional layers lie on the boundary conditions faces and these are not picked up by elmersolver in particular resultoutputsolver shows no BC (geometry IDs) in the vyu file for this layer, could this be responsible for the degenerate 2D error? might this be a failure in elmergrid?

I have produced a simple test case that generates the same errors which I've attached.
Regards
Mark

[mark smith]

Hi,
I exported the comsol mesh in nastran format from comsol for the test case I posted, read this into Gmsh then exported as a gmsh mesh. Then using elmergrid 14 2 mesh_test_for_elmer.msh I obtained an elmer mesh. On inspection The quad faces for the pyramid elements are present in the gmsh file but are omitted in the elmer mesh.boundary file, so I think there is a problem with elmergrid mesh conversion routine, as using either gmsh or comsol meshes elmergrid fails to write out these boundary elements ;-(
Gmsh mesh file attached for test geometry.
Regards
Mark

[mzenker]

Hi,

on monday, I will turn my "real" geometry, see if this makes the problem go away, and report back.

I did as I said, and indeed the "Degenerate Elements" error is gone.
So...

If really the problem has to do with the 2D mesh not lying in the xy plane, then it would at least be good to know that this is definitively the case.

I might add that a bugfix or at least a warning message telling the user what the problem is (both in elmergrid and ElmerGUI) would be even better...

Matthias

[raback]

Hi Matthias

The mesh was really assumed to be in (x,y) plane if 2D when using the automatic detection of space dimension. If you would have given the "Cartesian 3D" coordinate system it would have been ok even now.

Anaway, this is fixed now in the svn. Thanx for reporting!

-Peter

[mzenker]

Hi Peter,

If you would have given the "Cartesian 3D" coordinate system it would have been ok even now.

I did not know that there is a "Cartesian 3D" coordinate system as opposed to "Cartesian" (which I have given in my sif, it's the default in ElmerGUI). Moreover, I have just seen that in the example in the Solver manual, the coordinate system is "Cartesian 2D". None of these are given as possible choice in ElmerGUI, and I did not find any explanation in the Solver Manual. If there is a difference between "Cartesian", "Cartesian 2D" and "Cartesian 3D", would it be possible to add an explanation in the documentation and implement it in the GUI...?

Thanks anyway for the clarification and the fix!

Matthias

[raback]

Hi

The "3D" in the cartesian case should not be needed. However, in this case the automated logic failed. The new logic should work, I hope.

-Peter