Numbering After Webcutting

Coreform Cubit Meshing
#1

Is there a way to know how Coreform Cubit does some of the numbering of nodes after webcutting? I created a simple example.

brick x 2 y 1 z 1
move volume 1 x 1 y 0.5 z 0.5
block 1 volume 1
block 1 elem type hex27
block 1 name "two-element"
volume 1 size 1
mesh volume 1
nodeset 1 surface with x_coord 0
nodeset 2 surface with x_coord 2
nodeset 3 surface with y_coord 0
nodeset 4 surface with y_coord 1
nodeset 5 surface with z_coord 0
nodeset 6 surface with z_coord 1
nodeset 1 name "n_left"
nodeset 2 name "n_right"
nodeset 3 name "n_bottom"
nodeset 4 name "n_top"
nodeset 5 name "n_back"
nodeset 6 name "n_front"
export mesh "two-element.exo" overwrite

Then I created the same example except I webcut it.

brick x 2 y 1 z 1
move volume 1 x 1 y 0.5 z 0.5
block 1 volume 1
block 1 elem type hex27
block 1 name "two-element"
webcut volume 1 with plane xplane offset 1 
merge vol all
volume all size 1
mesh volume all
nodeset 1 surface with x_coord 0
nodeset 2 surface with x_coord 2
nodeset 3 surface with y_coord 0
nodeset 4 surface with y_coord 1
nodeset 5 surface with z_coord 0
nodeset 6 surface with z_coord 1
nodeset 1 name "n_left"
nodeset 2 name "n_right"
nodeset 3 name "n_bottom"
nodeset 4 name "n_top"
nodeset 5 name "n_back"
nodeset 6 name "n_front"
export mesh "two-element-split.exo" overwrite

When I use the exodus python module to look at the node connectivity for the two elements, I get the disparity.

For mesh without webcut

array([[ 1,  2,  3,  4,  5,  6,  7,  8,  9, 10, 11, 12, 13, 14, 15, 16,
        17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27],
       [ 5,  6,  7,  8, 28, 29, 30, 31, 17, 18, 19, 20, 32, 33, 34, 35,
        36, 37, 38, 39, 40, 23, 41, 42, 43, 44, 45]], dtype=int32)

For mesh with webcut

array([[ 1,  2,  3,  4,  5,  6,  7,  8,  9, 10, 11, 12, 13, 14, 15, 16,
        17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27],
       [ 6, 28, 29,  7,  5, 30, 31,  8, 32, 33, 34, 18, 17, 35, 36, 19,
        37, 38, 39, 20, 40, 41, 42, 23, 43, 44, 45]], dtype=int32)

Reason I am hoping to define a different node numbering scheme compared to the exodus defined 27 nodes hexahedron defined here Exodus: Exodus Element Types

Thank you for any help.

#2

To predict the node numbering after a webcut seems pretty impossible to me unless you control the whole meshing order. The normal mesh order is to first mesh the vertices, then the curves, then the surfaces and then the volume. And for the next volume this will be repeated.

It sounds like you want to map the connectivity for a element. For that you only need to know the node numbering for the isoparametric element that you want to map. The

cubit.get_expanded_connectivity(“hex”,1)

will always return the connectivity based on the exodus element type. When cubit exports the mesh in a different format the exodus element connectivity gets mapped to the chosen solver element type.

So for example if i want to map the connectivity from hex20 exodus to the c3d20 calculix

https://www.dhondt.de/ccx_2.22.pdf#subsubsection.6.2.4

I could do it like this with the python api.

#!cubit
reset
brick x 2 y 1 z 1
move volume 1 x 1 y 0.5 z 0.5
block 1 volume 1
block 1 elem type hex20
block 1 name "two-element"
webcut volume 1 with plane xplane offset 1 
merge vol all
volume all size 1
mesh volume all
nodeset 1 surface with x_coord 0
nodeset 2 surface with x_coord 2
nodeset 3 surface with y_coord 0
nodeset 4 surface with y_coord 1
nodeset 5 surface with z_coord 0
nodeset 6 surface with z_coord 1
nodeset 1 name "n_left"
nodeset 2 name "n_right"
nodeset 3 name "n_bottom"
nodeset 4 name "n_top"
nodeset 5 name "n_back"
nodeset 6 name "n_front"

#!python
import numpy as np

def map_hex_element(hex_element):
    nodes = np.array(cubit.get_expanded_connectivity("hex",hex_element))
    # swap position 13-16 with 17-20
    tmp_nodes = np.array(cubit.get_expanded_connectivity("hex",hex_element))    
    for i in range(12,16):
        nodes[i]=tmp_nodes[i+4]
    for i in range(16,20):
        nodes[i]=tmp_nodes[i-4]
    return nodes

nodes_cubit = cubit.get_expanded_connectivity("hex",1)
nodes_calculix = map_hex_element(1)

for i in range(len(nodes_cubit)):
 print(f"index {i+1} cubit {nodes_cubit[i]} <--> calculix {nodes_calculix[i]}")

grafik
grafik1052×891 20.4 KB

Do you need a export format that is not supported by cubit?

#3

I do have a different numbering that I am using for a solver I am testing out. What I am doing is exporting the exodus mesh, and using the exodus module to look at the connectivity. exodus module — SEACAS 2024/08/17 documentation

I am seeing a discrepancy also when I use the cubit.get_expanded_connectivity(“hex”,1") for the hex27 case compared to the element connectivity the exodus module produces.

For mesh without webcut

array([[ 1,  2,  3,  4,  5,  6,  7,  8,  9, 10, 11, 12, 13, 14, 15, 16,
        17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27],
       [ 5,  6,  7,  8, 28, 29, 30, 31, 17, 18, 19, 20, 32, 33, 34, 35,
        36, 37, 38, 39, 40, 23, 41, 42, 43, 44, 45]], dtype=int32)

image

For mesh with webcut

array([[ 1,  2,  3,  4,  5,  6,  7,  8,  9, 10, 11, 12, 13, 14, 15, 16,
        17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27],
       [ 6, 28, 29,  7,  5, 30, 31,  8, 32, 33, 34, 18, 17, 35, 36, 19,
        37, 38, 39, 20, 40, 41, 42, 23, 43, 44, 45]], dtype=int32)

image

I am unsure if this is an issue with the exodus module or how it’s exported.

#4

The ids gets mapped from cubit into the exodus format. I didn’t find a way to access the mapping out of cubit but you can for example view the mapping when you export with the hdf5 option with hdfview.

grafik

grafik
grafik1115×932 30.3 KB

But there should also be a method in the exodus module that can get you access to the mapping.

https://sandialabs.github.io/seacas-docs/sphinx/html/exodus.html#exodus.exodus.get_node_id_map