System definition

System definition#

This tutorial assumes XCOMPUTE-CLIENT is connected to a live XCOMPUTE-SERVER session. The concepts presented 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 project hierarchy maps xcompute systems to filesystems folders on the host server, providing teams a digital embodiment and source-of-truth.

  • In XCOMPUTE-CLIENT, the Navigation Tree (top left in-scene widget) is the main way to switch between and activate systems, defining the user’s working context.

  • Click the Systems tab to switch to the schematic view (in progress), which will enable system-specific tools in the context menu (right click in-scene).

Subsystems#

Within the Systems tab…

A system can be the parent to one or more subsystems (aka children). Typically, the parent system envelops child systems in space and time. In this manner, subsystems resolve things from high abstraction to low abstraction and systems can be reused in varying configurations and fidelity.

Subsystems can:

  • resolve a system as an assembly or component.

  • be a study or case (a shallow copy of a parent system’s geometry, with varying physics and conditions).

File Resources#

As systems map to local folders on the host filesystem, system setups (defined in an XCS or JSON file) can contain file resources and subsystem folders. If the file resource is not found in the system’s local folder, shared resources can be housed in the top level of the input directory. In this manner, systems can specify their own local attributes or point to shared resources (enabling patterning of geometries, code, etc).

  • On the Systems tab, the inspector panel displays system information and high-level system attributes. Referenced files can be added +, removed -, or exported/edited @. To take advantage of this feature, set the desired file associations in interface.cfg.

System names must:

  • be unique within a given parent system/folder

  • not start with _ or . – these prefixes are reserved for internal data folders

  • match the XCS or JSON file name with the containing folder

Note: If a name already exists in sibling systems, XCOMPUTE-SERVER will automatically rename the system (by appending an incremented integer). Within XCOMPUTE-CLIENT, subsystem names are listed in alphanumeric order.

Data#

Within the Data tab…

A system has data as the main record of floating-point vectors accessible by PropertyKey. Systems and bound algorithms read/write this data, usually assigned on a per-node basis. For storage, data is serialized and deserialized into XCO files for each PropertyKey in the record.

  • If there are N nodes in a system, by convention, a given field data property will have N rows and C components (columns), and the entry has a total size of N x C values.

  • Scalar values have 1 component, vectors have 3 components, and tensors typically have 9 components (assuming 3D). Transform matrices may be expressed with 9 (3x3) or 16 (4x4) components for homogenous transformations.

  • The save/load location of system data is in the system’s folder in a directory named _system_data/.

Requirements#

Enforceable inqualities can be defined for system data (to be checked upon each iteration). In the requirements list, add + a new requirement, following the form: PropertyKey Comparitor Value. For example, Temperature < 500. Remove a requirement with -.

Geometry#

In the Geometry tab…

A given system may assign an optional geometry, which can be unique to that system or referenced by multiple systems. Recognized geometry formats are focused on neutral discrete surfaces (that can be export from any CAD program), including: STL, OBJ, PLY, MSH.

An assigned geometry can define discrete elements: nodes, edges, faces, and cells. Each element have low-level functions to compute numerical attributes such as: neighbors, center, and other metrics such as length, area, and volume.

Unstructured meshes define underlying positions and topology in memory, while structured grids procedurally compute these attributes (for efficient background grids).

  • Elements are defined by their type and the nodes that comprise the corners of the element.

  • Each element has a region ID to define regions for the end user and algorithms (e.g. to apply boundary conditions). By convention, the default region ID is 0. Positive integers are for user assignment. Negative ID’s are for internal processing and can be used to indicate empty elements (to be skipped).

  • Optional geometric data has a default save/load location under _geometry_data/.

Regions#

Regions and corresponding geometric element types (by dimensionality):

  • 0D: Groups of Nodes

  • 1D: Loops of Edges

  • 2D: Surfaces of Faces

  • 3D: Volumes of Cells

A geometry can define regions: groups, loops, surfaces, and volumes. A geometric region is defined by its topological dimensionality and its assigned intrinsic ID. Underlying elements are gathered during use.

  • Boundary conditions and coupling are not applied to the geometry directly, but rather are refer to region instances within each system (as a geometry can be patterned across systems).

  • Internal procedural approach minimize the chance of out-of-date information and maximize the flexibility of constructed systems. Regions are intended to interface systems independent of geometry definition.

Physics#

In the Physics tab…

Physics is a type of model that contains other models. It also contains default physical constants data, saved within the XCS/JSON file.

Models#

A model is a collection of algorithms (aka calculation rules) to define the behavior of a system - usually as state equations and a spatial transport process. Available models are dependent on the XCOMPUTE-SERVER license type.

  • Models are often compatible with related models and can be combined into multi-physics, requiring similar solver methods and is handled on a case-by-case basis.

  • Algorithms are run through the model’s auto-sequencer to construct an instruction sequence that achieves a desired set of data outputs given a set of inputs and constants.

Materials#

Materials are referenced by name; the materials database is accessible across all systems. New and custom materials can be added to the material database at runtime.

The database is saved to the input path as XCO files within a folder named materials/, which can be loaded at launch or with the XC command reload materials.

  • Default material data come from the physics constants.

  • Materials can be assigned to specific regions, namely volumes in 3D.

Inertial Properties#

Inertial properties are available for a single system and recursively for all systems on that branch.

  • Integral computes the scalar field sum using volumetric methods or the vector field (flux) sum using surface methods (via median duals).

  • Mass computes the volumetric or surface integral of {Mass|Density}, or defaults to user-defined {Mass}.

  • CG computes the moment of {Mass|Density} divided by the {Mass}, or defaults to user-defined {Position|Reference}.

Rotational moments of inertia can also be calculated. The rotation point defaults to the CG unless otherwise specified.

  • 1st Moment computes the volumetric integral for any property (such as {Mass|Density}) about any rotation center, returning the zero vector by default about the CG.

  • 2nd Moment computes the volumetric integral for any property (such as {Mass|Density}) about any rotation center, by default about the CG.

Conditions#

Within the Conditions tab…

Initial Condition#

Initial conditions are only necessary for transient systems, typically a Dirichlet state executed once within the solver’s preprocessor.

  • In the inspector panel, set the initial conditions (if any).

Boundary Conditions#

Boundary conditions are required to provide spatial closure to the numerical domain, typically applied within the solver’s main sequence.

  • In the render scene, select one or more surfaces and right click for the context menu. The available boundary conditions will appear. Set the desired values in the inspector panel.

Coupling Boundaries#

Coupling provides a dynamic alternative to static boundary conditions, enabling adjacent systems to communicate information to provide a global solution.

  • In the render scene, select two surfaces and right click for the context menu. The available couplings will appear.

  • Alternatively, coupling can be prescribed visually via the schematic in the Systems tab (work in progress).

Solver#

Within the Solver tab…