[Gmsh] how can I check node number order

[Christophe Geuzaine]

Roland Tollenaar wrote:
> 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.
> 

Yes, the numbering is difefrent in .med and .msh files.

The numbering in .unv files (as defined by the IDEAS folks) is also 
different.

All these numberings are defined in the "getVertex()" functions in 
Geo/MElement.h.



> 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
>>>
>>>
>>
> 
> _______________________________________________
> gmsh mailing list
> gmsh at geuz.org
> http://www.geuz.org/mailman/listinfo/gmsh
> 
> 


-- 
Prof. Christophe Geuzaine
University of Liege, Electrical Engineering and Computer Science
http://www.montefiore.ulg.ac.be/~geuzaine