[Gmsh] how can I check node number order

[Roland Tollenaar]

Hi Christophe,
>> I have established that theoretically the node numbering of gmsh is 
>> identical to calculix for 1st and 2nd order tetrahedral elements.
> 
> Ok. When we implemented the UNV export we followed the spec from IDEAS, 
> and the UNV node ordering is definitely different from the one used in 
> the MSH file format (look at MElement::getVertexUNV() to see the mapping).
> 
> Could it be the case that Calculix does not use the standard UNV mesh 
> ordering? Is anyone on this list using Calculix?
I think calculix uses the same ordering as gmsh from what I can gather 
from documentation.

It appears that for C2D4 elements the vertex numbering remains constant. 
But for C3D10 which are of interest to me there is indeed a remap. This 
map differs to that which the Salome converter is using so I will have 
to unshuffle this to get it back into the gmsh/calculix order.

inp_map_C3D10=[1,3,5,10,2,4,6,7,8,9] is the map used to invert unv from 
Salome. The value map in gmsh is 0,4,1,5,2,6,8,9,7,3 which means to 
invert would require:

0,2,4,9,1,3,5,8,6,7 if I am not mistaken.

up this by 1 for the same base => 1,3,5,10,2,4,6,9,7,8 and we see that 
the mapping is the same up to the 7th vertex.

-Either there is a typo in Gmsh, Salome or the unv2abaqus tool.
-Or the vertex numbering differs between .med format and .msh format.

Whatever the case, unv-Salome is not equivalent to unv-Gmsh unless I am 
overlooking something.

I can sort this out for myself outside gmsh, but it should not be too 
had to implement a function that outputs .inp files for calculix. If 
this mod were made (even if not too perfect) would the gmsh developers 
consider touching it up and implementing it into the project?

Just a thought, I will not have time for it in the near future and 
anyway let me first see whether the numbering issue finally allows gmsh 
meshes to be processed successfully in calculix.

Regards,

Roland.

> 
> 
> 
> 
> 
>>
>> If I convert the unv file from gmsh and retain the order of the nodes 
>> defining the elements, then cgx reports 95%) bad elements (negative 
>> jacobian).
>>
>> Since it is unlikely that the elements from the meshinc process are so 
>> bad, it seems as though there is a good chance that the element order 
>> as gmsh builds the unv file is not consistent with its own (according 
>> to the documentation) node sequence format.
>>
>> Is this known, or if I have to check this, where in the code would the 
>> reordering be done?
>>
>> Kind regards,
>>
>> Roland
>>
>> _______________________________________________
>> gmsh mailing list
>> gmsh at geuz.org
>> http://www.geuz.org/mailman/listinfo/gmsh
>>
>>
> 
>