System Definition

System Definition#

This tutorial assumes XCOMPUTE-CLIENT is connected to a live XCOMPUTE-SERVER session. The concepts here are central to projects hosted on XCOMPUTE-SERVER and accessed via XCOMPUTE-CLIENT.

Hierarchy#

Projects are assembled as systems-of-systems trees, enabling teams to scope, composite, and reuse systems. The hierarchy maps directly to filesystem folders on the host server, providing a digital embodiment and source-of-truth.

  • The Navigation Tree (top-left widget) is the primary way to switch between and activate systems.

  • Double-click region graphics in-scene to navigate/activate. Double-click background to move up the tree.

A system can parent subsystems (children). A parent envelops its children in space and time. Systems are designed for reuse across configurations and fidelities.

Subsystems can:

  • Resolve as an assembly or component

  • Act as a study or case (shallow geometry copy with varying physics/conditions)

Mathematically, for child C, parent P, and root R:

C(x,t) ∈ P(x,t) ∈ R(x,t)

Filesystem Mapping#

Each system’s setup (XCS/JSON) references local files and subsystem folders. If a resource isn’t found locally, the loader checks the server’s top-level input directory. This enables local overrides or shared global resources.

Management#

Within the Manage tab, system owners control:

Basic Info#

  • name: Unique identifier relative to siblings

  • owner: Responsible party

  • URL: Optional web resource link

Name restrictions:

  • Must be unique among siblings

  • _ and . prefixes are reserved

Referenced Files#

  • Auto-added on import

  • Manually add +, remove -, or export @

  • Configure extension behavior in interface.cfg to auto-open files post-export

System Notes#

Raw text field for directions, status, or to-do lists. Admins have elevated permissions to modify any system.

Schematic (Experimental)#

Within the Systems tab:

Requirements#

Enforceable inequalities checked manually or per iteration. Add +, remove -, edit @.

Format: PropertyKey Comparator Value Example: Temperature < 500

Coupling#

Define dynamic data exchange between regions/systems.

Contacts#

Define mechanical contact pairs and friction models.

Geometry#

Within the Geometry tab:

Systems assign optional geometry, unique or shared. Supported formats: STL, OBJ, PLY, MSH.

Geometry defines discrete elements: nodes, edges, faces, cells. Each supports numerical functions: neighbors, center, length, area, volume.

  • Unstructured meshes store positions/topology in memory.

  • Structured grids compute attributes procedurally.

  • Elements defined by type and corner nodes.

  • region ID assigns elements to user/algorithm groups. Default: 0. Positive: user-assigned. Negative: internal/empty.

  • Optional geometric data saves/loads to _geometry_data/.

Regions#

Dimension

Type

Elements

0D

Groups

Nodes

1D

Loops

Edges

2D

Surfaces

Faces

3D

Volumes

Cells

Boundary conditions bind to system instances and regions, not raw geometry (enabling patterned reuse).

Physics#

Within the Physics tab:

Physics models contain algorithms and physical constants. Auto-sequencing yields instruction sequences for desired outputs.

Physical Models#

Collections of algorithms defining system behavior (state equations, transport processes). Availability depends on server license.

Materials#

Referenced by name. Database accessible across all systems. Custom materials added at runtime.

Saved to input/materials/ as XCO files. Load at launch or via reload materials. Defaults to physics constants. Assignable to volume regions.

Conditions#

Within the Conditions tab:

Initial Conditions#

Required for transient systems. Typically a Dirichlet state executed once in the solver preprocessor.

Boundary Conditions#

Provide spatial closure. Applied in solver main sequence.

  • Select surfaces in-scene → right-click → choose condition → set values in inspector.

Coupling Boundaries#

Dynamic alternative to static BCs. Enables adjacent systems to communicate.

  • Select two surfaces → right-click → choose coupling.

  • Or prescribe visually via Systems tab schematic.

Solver#

Within the Solver tab:

Configure numerical methods, timesteps, convergence criteria, and execution sequences. Solver selection depends on physics model and problem type.

Data#

Within the Data tab:

Systems store floating-point vectors accessible by PropertyKey. Algorithms read/write data, typically per-node.

  • N nodes → N rows × C components per field

  • Scalars: C=1, Vectors: C=3, Tensors: C=9 (3D)

  • Transform matrices: 9 (3×3) or 16 (4×4)

  • Saves/loads to _system_data/

Inertial Properties#

Available per system and recursively down branches.

  • Integral: Scalar sum (volumetric) or flux sum (surface/median duals)

  • Mass: Volumetric/surface integral of Mass|Density, or user-defined

  • CG: Moment of Mass|Density / Mass, or user-defined Position|Reference

  • 1st Moment: Volumetric integral about rotation center (defaults to CG → zero vector)

  • 2nd Moment: Volumetric integral about rotation center (defaults to CG)

Visuals#

Within the Visuals tab:

Configure rendering options, field displays, transparency, clipping planes, and animation controls.