Elmer Discussion Forum

Hello,

I have run a simple case with the StatCurrentSolveVec solver:
- Geometry: Cylinder
- Mesh with second order elements (quadractic tetrahedrons, 510 type)
- Two boundary conditions: one end to 0 V and the other to 100 V

The calculation in ELMER is done correctly until the end.

However when I display the .VTU files in Paraview, there are several faces of the mesh missing... See the file "QuadraticTetrahedrons.PNG"

If I use linear tetrahedrons (504 type), I get good results. See the file "LinearTetrahedrons.PNG"

Is there a problem with the ResultOutputSolver during the export to .VTU file? Or maybe the problem is coming from Paraview...

Any ideas?

Thank you

Jeremie

Hi,

It would help if you would post an MWE, a minimum working example, with geometry and sif files.

Thanks, Rich.

Yes, I added the .sif file, the mesh files and the .vtu file in the .zip

Thanks

mesh.header file says they are 303 and 504 elements

1125 606 284
2
303 284
504 606

The mesh.element file says they are 510 type
the mesh.boundary file says they are 306 type

Hi

Just checked the numbering of second order tris/tets of vtk and they seem to be exactly the same as for Elmer. Now the observation of Rich makes me wonder where the mesh came from, and whether you're sure the initial ordering provided to Elmer follows the same convention. Gmsh, for example, has different ordering of quadratic tets which has to be dealt with.

-Peter

Thanks Kevin and Peter.

Yes indeed, there are different information between mesh files:

mesh.boundary -> 306 type
mesh.elements -> 510 type

However the mesh.header indicates linear types: 303 and 504.
I tested to edit the mesh.header by replacing 303 and 504 by 306 and 510 respectively, but no differences.

I did the mesh from a .step file for the geomtry by using NetGen 6.2.2004 (GUI) with the option "Second order elements".

Usually without second order elements, the mesh provided by Netgen works very well.

Thanks for help.

Jeremie

Hi Jeremie,

There is a bug in the Elmer export of netgen regarding 2nd order elements. The ordering is not correct. I sent a bug report some years ago but I guess Joachim has better things to do. The numbering convention is part of each mesh format so in that regard the problem is on netgen side.

You could perhaps try going via some other formats. Or maybe use p:2 elements. Or write a small script that reorders the numbering.

I tried to find out the internal numbering of netgen but could not find the info on documentation. You could perhaps try to make the smallest mesh and figure out the numbering from there.

-Peter

Hello,

Here's a link to Netgen source code, (at least I'm pretty sure it's the right link):
https://git.code.sf.net/p/netgen-mesher/git

Edit, the link above is for a mirror of the github repository.
For the proper location of the Netgen source, use this link to github:
https://github.com/NGSolve/netgen

In the netgen-mesher folder 'libsrc/interface' are two files, writeelmer.cpp and writegmsh2.cpp, both files are attached.

In writeelmer.cpp, the element types are hard coded into the header file:

outfile_h << np << " " << ne << " " << nse << "\n";
outfile_h << "2" << "\n";
outfile_h << "303 " << nse << "\n";
outfile_h << "504 " << ne << "\n";

Here's the intro to writegmsh2.cpp:

* Current features of this function include:
*
* 1. Exports Triangles, Quadrangles and Tetrahedra
* 2. Supports up to second order elements of each type

If you have a chance, please export your mesh from Netgen using the gmsh2 format, and then convert from gmsh to elmer using elmergrid. Let us know how this works for you.

Thanks, Rich.

Hi Rich,

Very helpful. Comparing the two you see Elmer version is missing the code for repermutation. For Gmsh this can be found to be (for 11 node tet):

int tetGmsh[11] = {0,1,2,3,4,5,8,6,7,10,9};

When you look at ElmerGrid code for Gmsh you see (for 10 node tet):

int order510[]={0,1,2,3,4,5,6,7,9,8};

So permutation to Elmer should be almost the same as for Gmsh except the last two indices.

-Peter

Thanks Peter, thanks Rich for this suggestion.

I exported the mesh in gmsh2 format and then I converted it in Elmer format with ElmerGrid.
I attached the mesh.

The mesh.header seems correct.

However the Body index in the mesh.element is wrong: there is 100001 instead of 1.

Therefore the Elmer calculation generates the following error:
"ERROR:: DefaultInitialize: No matrix exists, cannot initialize!"

I manually replaced the index 100001 by 1 and it works: Elmer calculation is well running and the .vtu file is well displayed by Paraview!

This allows me to compare the 2nd order mesh files generated by Netgen that are not working with the 2nd order mesh files that are working with this method (Netgen->GMSH2->ELMER).

Do you understand why ElmerGrid does not perform the conversion correctly (wrong index body) ?

Thanks

Jeremie