Which Mesh Entities Carry the AI Input Values?

Identify the entity behind each feature row

An engineering AI input described as a mesh with a scalar field leaves an essential question unanswered: does each scalar belong to a point, a triangle or some other entity? Start with the consuming interface's answer. For a graph input, also establish what each graph vertex represents. A graph vertex can represent a mesh cell even though the mesh itself has geometric points.

The VTK XML format documentation distinguishes Points and Cells from PointData and CellData. In an UnstructuredGrid piece, point coordinates are explicit, and cells carry connectivity and cell types. Attribute arrays have their own point or cell association. These format details come from the living documentation checked October 21, 2026; the conversion behavior discussed below is separately pinned to VTK 9.5.2.

A scalar attached to a triangle describes that cell under the producer's stated meaning. A scalar attached to one of its points describes that point under its own stated meaning. Neither the array name nor a shared display color makes these attachments interchangeable. The related CAD representation guide addresses the underlying surface geometry; this decision concerns the values and relationships delivered with a mesh.

References: [MX]

MESH-FAN4: five points, four triangle cells

MESH-FAN4 is an original mathematical example. Place O at the center of a planar fan and A, B, C and D in order around its boundary. Its four triangles are T1 = OAB, T2 = OBC, T3 = OCD and T4 = ODA. Shared letters identify the same mesh points. The example contains no physical field, measured geometry or model execution.

Give the points identifiers O = 0, A = 1, B = 2, C = 3 and D = 4. The ordered triangle connectivity is then T1 = (0, 1, 2), T2 = (0, 2, 3), T3 = (0, 3, 4) and T4 = (0, 4, 1). Connectivity says which points define each cell; it supplies no scalar feature values by itself.

A scalar array attached to these cells has four tuples, ordered here as T1, T2, T3, T4. One attached to the points has five tuples, ordered here as O, A, B, C, D. These are entity counts. A multi-component feature would also need its component meaning specified; adding components would not change which entity owns each tuple.

Choose point adjacency or cell adjacency explicitly

Define a first graph whose vertices are the five mesh points. Join two vertices when they form an edge of a triangle. Its distinct undirected edges are OA, OB, OC, OD, AB, BC, CD and DA: five graph vertices and eight edges. An edge shared by two triangles is counted once.

Define a second graph whose vertices are the four triangle cells. Join two vertices only when their cells share a complete mesh edge. T1 joins T2 across OB; T2 joins T3 across OC; T3 joins T4 across OD; T4 joins T1 across OA. This gives four graph vertices and four undirected edges. Each triangle has two neighbors under this rule.

T1 and T3 share O but no complete edge, so they are not adjacent in the second graph. The same holds for T2 and T4. Changing the rule to any shared point would connect every pair of these triangles, giving six undirected cell-graph edges. The word adjacent therefore needs its actual rule.

These are expressly defined point-based (primal) and cell-based (dual) input graphs. They are not automatic VTK output or a graph neural network default. Both counts exclude self edges and count an undirected pair once; any directed representation needs its own declaration. Under a one-feature-row-per-graph-vertex requirement, the first graph needs five rows and the second needs four, aligned to different entities.

Follow the cell values through a stated point mapping

Now supply two alternative, unitless cell scalar fields on the same fan. In triangle order T1, T2, T3, T4, cellA = [10, 30, 10, 30], while cellB = [20, 20, 20, 20]. They describe different cell inputs despite having identical geometry and connectivity.

For this example, define a derived value at each point as the arithmetic mean of every incident triangle's scalar. The VTK 9.5.2 vtkCellDataToPointData class documents cell-to-point averaging; its implementation also provides a count-based averaging path. MESH-FAN4 stipulates one complete piece, ordinary numeric scalars and all incident triangles, with no extra contributors or alternative weighting.

For cellA, O receives (10 + 30 + 10 + 30) / 4 = 20. Point A belongs to T4 and T1, giving (30 + 10) / 2 = 20. Point B uses T1 and T2, giving (10 + 30) / 2 = 20. Point C uses T2 and T3, again giving 20; point D uses T3 and T4, also giving 20.

For cellB, each incident value is already 20. O therefore receives 80 / 4 = 20, and each boundary point receives 40 / 2 = 20. Both alternatives produce the same point array [20, 20, 20, 20, 20] in O, A, B, C, D order.

The retained connectivity is also identical. A recipient given only these derived point values and the known fan cannot determine whether the original cell field was cellA or cellB. This is a constructive ambiguity for the stated mapping. It does not establish that every mesh conversion loses information.

References: [M1][M3]

Keep original attributes and reverse mapping separate

A deliverable can include the original cell arrays alongside a derived point array. The VTK 9.5.2 cell-to-point class documents optional pass-through of input cell data. Establish whether the actual handoff retains the required original arrays and their entity mapping. The presence of a derived point field alone does not answer that question.

Contributor policy is another part of the transformation's meaning. The class distinguishes All, Patch and DataSetMax: all cells, the highest-dimensional cells attached to each point, or the highest cell dimension across the dataset. MESH-FAN4 contains only triangles. An offer involving mixed-dimensional cells needs its own contributor definition before its derived values can be compared with this example.

The reverse-named vtkPointDataToCellData class documents default averaging of the points defining each cell, with a separate categorical alternative. Applying ordinary point-to-cell averaging to MESH-FAN4's five values of 20 returns four values of 20, because each triangle receives (20 + 20 + 20) / 3. That matches cellB and fails to recover cellA. Reversing the direction of association is not a general inverse of the earlier averaging operation.

References: [M1][M2]

Compare the handoff with the consumer's requirement

Suppose consumer C represents triangles as graph vertices and requires the original cell scalar plus complete-edge cell adjacency. For MESH-FAN4 it needs four scalar rows aligned to T1 through T4 and the four-edge cell graph. A delivery containing only the five derived point values fails that stated feature requirement, even if it includes all triangle connectivity. A supplier could retain the original cell array to resolve the demonstrated feature omission.

Consumer P instead represents mesh points as graph vertices and explicitly requires the all-contributor derived scalar and triangle-edge point adjacency. For that requirement, five rows of 20 and the eight-edge point graph can be appropriate. P has deliberately chosen the derived representation. Calling it incomplete merely because it differs from C's input would ignore P's actual task.

Ask the appointed data or software provider to identify the mesh version, point and cell populations, tuple-to-entity mapping, selected feature arrays, component meanings, numeric representations, units and missing-value treatment. A reordered export can remain usable if the feature and connectivity mappings remain consistent; preserving a familiar row count alone is insufficient. Record each transformation and whether original attributes remain available. If the consumer instead requires edge or face features, identify those entities and their attributes explicitly.

Have the recipient trace representative feature rows to their entities and show the declared neighbor relationships. In this example, T1's original value and its neighbors T2 and T4 distinguish C's requirement from O's derived value and four point neighbors in P's graph. This comparison establishes what input is being promised. Any model-quality assessment still needs evidence for that consumer and task.

Scope any separate equipment installation

If the selected compute or storage hardware also needs physical installation, Leviathan's Rack & Stack / Colocation service covers an agreed package of equipment mounting, IT cabling, labels and physical installation records. Use the related service and project inquiry for that separate requirement.

Share a nonconfidential equipment list, rack plan, site constraints, intended work window and physical handoff needs. Mesh preparation, feature conversion, graph construction and model acceptance remain with the appointed data and software providers.

References: [L1]