Problem to display results from second order elements

Numerical methods and mathematical models of Elmer
jeremie
Posts: 28
Joined: 11 Jul 2019, 11:31
Antispam: Yes

Problem to display results from second order elements

Post by jeremie »

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
Attachments
Example.zip
(126.92 KiB) Downloaded 130 times
LinearTetrahedrons.PNG
(85.01 KiB) Not downloaded yet
QuadraticTetrahedrons.PNG
(172.1 KiB) Not downloaded yet
Last edited by jeremie on 14 Sep 2021, 16:46, edited 2 times in total.
Rich_B
Posts: 421
Joined: 24 Aug 2009, 20:18

Re: Problem to display results from second order elements

Post by Rich_B »

Hi,

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

Thanks, Rich.
jeremie
Posts: 28
Joined: 11 Jul 2019, 11:31
Antispam: Yes

Re: Problem to display results from second order elements

Post by jeremie »

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

Thanks
kevinarden
Posts: 2237
Joined: 25 Jan 2019, 01:28
Antispam: Yes

Re: Problem to display results from second order elements

Post by kevinarden »

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
raback
Site Admin
Posts: 4812
Joined: 22 Aug 2009, 11:57
Antispam: Yes
Location: Espoo, Finland
Contact:

Re: Problem to display results from second order elements

Post by raback »

Hi

Just checked the numbering of second order tris/tets of vtk and they seem to be exactly the same as for Elmer.
VtkTet.PNG
VtkTet.PNG (6.36 KiB) Viewed 1955 times
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
jeremie
Posts: 28
Joined: 11 Jul 2019, 11:31
Antispam: Yes

Re: Problem to display results from second order elements

Post by jeremie »

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
raback
Site Admin
Posts: 4812
Joined: 22 Aug 2009, 11:57
Antispam: Yes
Location: Espoo, Finland
Contact:

Re: Problem to display results from second order elements

Post by raback »

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
Rich_B
Posts: 421
Joined: 24 Aug 2009, 20:18

Re: Problem to display results from second order elements

Post by Rich_B »

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.
Attachments
writegmsh2.cpp
(8.62 KiB) Downloaded 118 times
writeelmer.cpp
(2.95 KiB) Downloaded 123 times
Last edited by Rich_B on 17 Sep 2021, 01:14, edited 1 time in total.
raback
Site Admin
Posts: 4812
Joined: 22 Aug 2009, 11:57
Antispam: Yes
Location: Espoo, Finland
Contact:

Re: Problem to display results from second order elements

Post by raback »

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
jeremie
Posts: 28
Joined: 11 Jul 2019, 11:31
Antispam: Yes

Re: Problem to display results from second order elements

Post by jeremie »

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
Attachments
GmshToElmer.zip
(31.49 KiB) Downloaded 118 times
Post Reply