XCOMPUTE-CLIENT#

If you haven’t done so, download XCOMPUTE-CLIENT for free. You will receive an email with your XCOMPUTE-CLIENT fingerprint. Your fingerprints (and any machine assignments) can be viewed in your Account Profile.

Access Control#

To connect to a project, send an email to the trusted admin of the XCOMPUTE-SERVER you’d like to access, including your fingerprint (so that they can add it to users.cfg). Listed teammates can edit the simulation and become system owners, while guests may have restricted read-only access (feature coming soon).

Execution#

  • If XCOMPUTE-CLIENT has been installed, it should be available in your OS’s launcher.

  • Or, run from commandline: xcompute-client or ./path/to/xcompute-client

  • Upon initialization, client.cfg will be loaded and the login window will appear.

  • For convenience, custom configs can also be loaded, e.g.: ./xcompute-client configs/presentation.cfg.

Login#

  1. Enter the host address of the server you wish to connect with. It can be a DNS-resolved address such as xplicitcomputing.com, or an IPv4 address on LAN or WAN (if enabled). IPv6 addresses should also work but are not thoroughly tested yet. If XCOMPUTE-SERVER is running on the same computer as the connecting XCOMPUTE-CLIENT, enter localhost.

  2. The default and recommended port for the IANA-registered xcompute service is 11235. If you leave the port number empty it will default to 11235.

  3. In order to log into the XCOMPUTE network, credentials must be provided: email and fingerprint. This only needs to be entered once on any given account/device. It is recommended to set the input and output directories to faciliate convenient import and export operations. If not, they will default to your home directory.

  4. Following successful login, interface.cfg will be loaded and the interface window will appear. The various metadata will buffer. Higher speed networks (end-to-end) means less waiting for large updates to occur.

Note: For a given XCOMPUTE installation, your fingerprint remains the same. If you want to connect to a different server host you only need to change the host address (and maybe port number if it’s non-standard). If you require a new XCOMPUTE-CLIENT fingerprint (and key), you can get a new one for free by downloading XCOMPUTE-CLIENT again and receiving a new fingerprint in your email mapped to the new key.

Interface#

The main window displaying XCOMPUTE-CLIENT comes from your installed or existing Qt5 framework. After a successful login to a connected XCOMPUTE-SERVER, XCOMPUTE-CLIENT buffers and renders loaded systems (repesented by metaobjects, see below) to populate the scene (housed by the interface window). Once the window is closed, the connection is closed. Assuming the project was not closed on the server, teammates can always reconnect to continue, or load from previous saved states.

People work on one system at a time – moving up and down the systems tree to work at different levels of abstraction. The interface displays the active system in multiple locations to indicate context if actions are being performed (and nothing is selected otherwise). Teammates can be connected to the same XCOMPUTE-SERVER via their own XCOMPUTE-CLIENT apps running on laptops, working on different systems concurrently with minimal conflict.

Note: More tools and indicators planned in future releases. Focus on basics first…

Qt Widgets#

The interface is comprised of dialog widgets, buttons, and text fields used to display info or list operations that can be performed upon the active system in your XCOMPUTE-CLIENT session. Many features have yet to be populated in the GUI. (Note: as specific implementations of Qt may vary, there may be variation in display style across operating systems.)

File Menu#

Various useful client and interface options are available in the file menu (near top):

  • File - core functionality fileops Import, Export, Save, Load, and Load Directory.

  • Settings - useful configuration controls for default parameters for compute.cfg and interface.cfg

  • Assets - condensed project resources and tools in different categories (in progress)

  • View - interface and scene controls for the current session

  • Help - links to documents and contacts

Various hotkeys are assigned for convenience (see menus for key bindings).

File I/O#

The client interface can import/export external files to/from the server, while the server host saves/loads native XC files from its own filesystem:

Input

Output

Server

Load

Save

Client

Import

Export

Save & Load#

When one presses the Save button in XCOMPUTE-CLIENT, a command is sent to XCOMPUTE-SERVER to write one or more system(s) setup and state to its output directory (such as a fast project SSD).

Conversely, when selecting a folder or XCS file to Load, a command on the server reads the file(s) from its own input directory (which will then update the client once loaded).

In both Save and Load cases, no file I/O occurs within the client filesystem as these are server-side only filesystem ops.

Import & Export#

XCOMPUTE-CLIENT imports files from its local filesystem and sends the files to be loaded in the connected XCOMPUTE-SERVER session, including neutral types:

stl, obj, msh, sdf

XCOMPUTE-CLIENT exports neutral files to the local filesystem after receiving from a connected XCOMPUTE-SERVER session, including types:

csv, vtu, stl, obj, msh, sdf

Native file types can also be import and export in order to be accessed via XC-Messages:

xcs, xcg, xco

Any file extension can be associated with a shell command (callable from XCOMPUTE-CLIENT’s context menu). Ensure the 3rd-party app/command is installed, and in interface.cfg add something the key=value pairs :

py=python3
vtu=paraview
msh=gmsh
csv=numbers --some-special-options

Other project files (such as CAD designs, docs, codes, spreadsheets, etc) can also be import/export to faciliate a single source-of-truth. They essentially just go along for the ride (with aforementioned benefits) and reside on the server’s filesystem in an organized and associated fashion. This is very convenient as files can be hosted and downloaded alongside a visual representation of the systems of interest – towards a team-centric digital embodiment of whatever you’re developing.

Note: update speed dependents on the upload and download speed and latency of the network between server and client.

Tabs#

Your CAE “operating mode” is controlled by the tabs near the top of the interface:

Geometry Physics Conditions Solver Data Visuals

The general idea is that one naturally progresses from left to right during most workflows. You might setup the geometry, then define the physics, conditions, solver, and then examine the data. Which tab your on will dictate the context and what options are available.

Additional tabs will be unlocked as XCOMPUTE matures, including a functional Systems schematic and other high-level engineering capabilities.

Inspector#

The inspector is a Qt dialog window populated with relevant info and options depending on the active system and the current tab. The inspector’s visibility can be toggled with F1. It also automatically appears if you change tabs.

Render Scene#

The 2D overlay’s visibility can be toggled with F2, while the 3D render visibility can be toggled with F3.

GL Pipeline#

VAO render unit#

All in-scene graphics are composed of vertex array objects that manage CPU-GPU render data and texture bindings. During graphics composition, VAOs are organized into layers and passed into the GL pipeline on each render cycle from back-to-front.

Graphics & Metaobjects#

Most graphics objects are interactive which means that the cursor and selection tool can search them, handling some callback action. Graphics can be 2D or 3D depending on type. Most of the 3D objects rendered in-scene are metaobjects comprised of one or more metaregions, representing associated server-side geometry and regions.

You selects a metaregion by clicking on it and then perform some operation that then affects the actual region server-side. You can also select it from the region list in the inspector panel (while using the geometry tab). (Currently, only interactive selection based on surfaces and faces are enabled.)

For convenience, double-clicking a metaregion will activate the owning metaobject in the scene and interface. Double-clicking on the empty background will navigate you up a level (activating the parent).

Camera & GLSL#

On each render cycle, VAOs are processed by the render pipeline which then invokes OpenGL rasterization calls including the GPU programs associated with shaders/vertex.glsl and shaders/fragment.glsl to paint pixels. Advanced users are encouraged to play with and improve these GLSL shaders (and share as fit).

During runtime, render stats can be printed to console by pressing the R key.

During runtime, the render pipeline and scene can be dynamically reloaded using Ctrl + R (or Cmd + R on Mac), permitting rapid customization of shaders for custom graphics effects.

Context Menu#

Right click in-scene to show a context-driven menu (utilizing the Qt framework). The options depend on the current tab and selection.

XC command bar#

Clicking the XC button in-scene enables a dynamic interpreter for additional manual (and experimental) commands.

For example, if for some reason data isn’t updating in XCOMPUTE-CLIENT, you can enter refresh and that will invoke a server-side refresh on the active system context, which will push metadata back to ensure everything is up-to-date. You can also reload systems from server storage or load users.cfg to update the team’s roster.

Other commands will be shared in the near future.

Hotkey summary#

Coming soon.