File Operations

File Operations#

Systems map to folders on the XCOMPUTE-SERVER host.

  • Each virtual system encapsulates a concept and organizes files (e.g. code, design, geometry, data, docs, etc) into a hierarchy of sub-systems as sub-folders.

  • Folders and files are read and interpreted into high-performance memory objects to be computed and/or rendered during runtime.

I/O Configuration#

To define the import/export/save/load path, set input and output in client.cfg and/or server.cfg:

input=/path/to/project
output=/path/to/project

  • Usually, input and output are set to the same directory. Make sure you or user xcompute has ownership with rw (read/write) permissions, else you will get a critical error when trying to save or load. On Unix OS, check with:

ls -al /path/to/project

  • XCOMPUTE-SERVER saves the project state (setup, geometry, and data) of each system using native XCS/JSON, XCG, and XCO files. These files can be accessed via almost any programming language with XC-Messages.

  • Unless otherwise named, the top-level “root” system defaults to the session’s launch timestamp (to avoid accidental overwriting of work).

The Active System#

Within an XCOMPUTE-CLIENT session, file operations are performed within the active system.

  • The interface’s active system can be changed by clicking its name in the Navigation Tree (top left in-scene), or by double-clicking on its spatial representation in-scene.

  • Typically, only one system is operated upon at a time, dictating the information and operations available. This optimizes concurrent teamwork for multiple people (or agents) as projects get more complex.

Importing Files#

Importing typically transmits a file from user’s XCOMPUTE-CLIENT to a connected team’s XCOMPUTE-SERVER filesystem.

Geometry Files#

To import a geometry file from your XCOMPUTE-CLIENT session onto a connected XCOMPUTE-SERVER, in the file menu click Import Geometry, or right click in the scene to show the context menu via Import>Geometry.

  • In order to provide a common basis for CAE workflows, currently XC recognizes tesselated inputs such as STL, OBJ, PLY, and MSH formats.

  • Imported surface reps are processed into internal discrete meshes and signed-distance fields for volumetric computation. Some numerical methods such as mesh generation can start from an imported SDF file defined by Messages::SparseMatrix (found in vector.proto).

Other Files#

In the XCOMPUTE-CLIENT file menu click Import File, or right click in the scene to show the context menu via Import>File.

  • All file types can be imported (aka attached) into systems to organize a source-of-truth for the team’s digital project. All files can then be exported via XCOMPUTE-CLIENT and worked upon with other software.

Exporting Files#

When the export command is received by XCOMPUTE-SERVER, the server host creates (or finds) the requested file and stages it in its output path. The file is then transmit over network to XCOMPUTE-CLIENT and written to the output path defined in client.cfg.

System Files#

XCS (native), JSON (native), VTU (paraview)

Data Files#

XCO (native), CSV

Geometry Files#

XCG (native), STL, OBJ, PLY, MSH, SDF

External Files#

From XCOMPUTE-CLIENT, it is possible to graphically navigate, export and launch files in external software. To do so, set the file type extension association in interface.cfg to the program command. For example, if Paraview, GMsh, Excel, and Matlab are installed, one might add:

vtu=paraview
msh=gmsh --some-option
csv=excel
mat=matlab --headless

  • Ensure that the other software is installed and in your OS’s path (e.g. /usr/bin/). Everything following the = is evaluated as a shell command. Upon the next launch or load interface.cfg, the context menu will then show an entry open in .... This is an easy way for XCOMPUTE to act as a project hypervisor.

Save#

When save is invoked, XCOMPUTE-SERVER writes native JSON text (or XCS binary) setup, XCG geometry binary, and XCO binary data files for the given system and its subsystems to the output path defined in server.cfg. These native files can be accessed via XC-Messages.

  • When loading a resource, XCOMPUTE-SERVER firsts look into the designated system folder. If the expected resource is not there it will look in the top-level of the input path. This prioritizes hierarchical (local) resources whilst permitting referencing of flat (global) resources as desired.

Setup#

From XCOMPUTE-CLIENT, the save button in the file menu performs the action upon the active system and its subsystems. The save all button performs the action starting at the root system and progressing through all systems. The produced XCS/JSON file is simply the standard file steam of Messages::System (found in concept.proto).

  • Folders encapsulate systems, but XCS/JSON files acts as the nuclei to specify the setup and parameterization of the associated files and folders. This includes the physics, conditions, and solver sequence as well as references to associated geometry and data files. An XCS/JSON file will have the same name as folder containing it.

Data#

When a solver is executed, XCOMPUTE-SERVER invokes the solver’s instruction sequence one or more times (defined by its execution_count). Depending on the system’s save_interval, XCO are produced in the server’s output path.

  • Data files are organized by iteration and Property Key, making them handy for humans and machines whilst permitting optimal parallel write/read patterns. The produced XCO file is simply a standard file stream of Messages::Vector64 (found in vector.proto).

  • Each XCS/JSON system and XCG geometry can reference XCO data stored within each system as a hidden folder, such as _system_data or _geometry_data; else it may be named _default_data.

Note: To represent all different data here, for illustration we’ve abbreviated the possible PropertyKeys with *. It’s worth noting the preceding _ provides a directive to load these folders as data rather than subsystems.

System data is organized for each iteration 0, 1, 2, ... , I , as:

_system_data/0/*.xco
_system_data/1/*.xco
_system_data/2/*.xco
...
_system_data/I/*.xco

Similarly, geometry data follows suit:

_geometry_data/0/*.xco
_geometry_data/1/*.xco
_geometry_data/2/*.xco
...
_geometry_data/J/*.xco

The customizable materials database is saved to the input directory:

materials/<MATERIAL>/_default_data/0/*.xco

  • System XCO files can be deleted manually by the server administrator or via XCOMPUTE-CLIENT’s interface in the Data tab. Likewise, the current system’s data state can be changed by loading XCO files.

Geometry#

Geometric assets are saved in the native geometry format, following the patterns established above except the following:

  • Due to its potential size, the produced XCG file is encoded stream of Messages::Topology (found in spatial.proto). The geometry file contains the nodal positions and element indices, and/or other embedded spatial data.

Load#

Setup#

Data#

Geometry#