Hi
Elmer should follow the same node ordering as VTK and therefore permutation has not been needed. Now for elementtype 827 we may have chosen ordering before it was available in VTK and therefore there is of course a change that they differ. Maybe you can find numbering order for VTK somewhere. Gmsh seems to follow a different logic and hence there the permutation exists for most elementtypes.
-Peter
3D '827' elements Gmsh -> ElmerGrid
-
- Posts: 30
- Joined: 26 May 2014, 12:37
- Antispam: Yes
Re: 3D '827' elements Gmsh -> ElmerGrid
Hi peter,
You might also add Gmsh to ElmerGrid info for this 827 element at elmergrid/src/femfilein.c
https://github.com/ElmerCSC/elmerfem/bl ... in.c#L3065
With this you may be able to generate H27 in GMSH -> 827 ElmerGrid -> ElmerSolver -> VTU output.
Thanks again for your help on this.
You might also add Gmsh to ElmerGrid info for this 827 element at elmergrid/src/femfilein.c
https://github.com/ElmerCSC/elmerfem/bl ... in.c#L3065
Code: Select all
static void GmshToElmerIndx(int elemtype,int *topology)
...
int order827[]={0,1,2,3,4,5,6,7,8,11,13,9,10,12,14,15,16,18,19,17,21,23,24,22,20,25,26};
....
case 827:
reorder = TRUE;
porder = &order827[0];
break;
Thanks again for your help on this.