XCOMPUTE-CLIENT

XCOMPUTE-CLIENT#

If you haven’t done so, download XCOMPUTE-CLIENT.

You will receive an email with your XCOMPUTE-CLIENT fingerprint.

Your fingerprints can be viewed in your Account Profile.

1. Request Access (as required)#

Unless visiting as a read-only guest (such as the public test server), send your fingerprint and email address to the admin of the server host you’d like to access. If approved, they will add your endpoint into the server’s users.cfg.

2. Run the App#

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

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

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

2a. Login#

i. 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). If XCOMPUTE-SERVER is running on the same computer as the connecting XCOMPUTE-CLIENT, enter localhost.

ii. The default and recommended port for xcompute service is 11235. If you leave the port number blank it will default to 11235.

iii. 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.

iv. It is recommended to set the input and output directories for easy import and export operations. If unset, it will default to your home directory. Save the config.

Note: Update speed is dependent on the upload/download speed and latency of the network between server and client.

2b. Interface#

Following successful login, interface.cfg is loaded for any optional UX settings and the interface window will appear as metadata and visuals buffer.

startingTab=0
dpi=100
panSensitivity=50
precision=3
rotateSensitivity=50
timeConstant=50
zoomSensitivity=50
groups=false
loops=false
surfaces=true
volumes=true

The main display window comes from the provided Qt5 framework libraries. After successful login and connection to XCOMPUTE-SERVER, XCOMPUTE-CLIENT buffers and renders server-side systems to visualize the scene (housed by the interface window). Once the window is closed, the connection is closed but the simulation remains unless otherwise closed server-side; teammates can reconnect to continue, or load from previous saved states.

  • Concurrently, users navigate around the system tree to work at varying levels of abstraction.

  • High-speed end-to-end networks result in faster updates and better collaboration.

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 file-ops 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).

Tabs#

The “operating mode” (available options) is controlled by the current tab (just above the scene):

Manage Systems Geometry Physics Conditions Solver Data Visuals

To resolve a system, one usually progresses from left to right. For example, one may setup the geometry, then define the physics, conditions, solver, and then examine the data.

Additional tabs will be unlocked as XCOMPUTE matures, including a functional Systems schematic.

Inspector#

The inspector is a dockable dialog window populated with relevant info and options depending on the active (or selected) system. The inspector’s visibility can be toggled with F1. It can be docked/undocked from the left or right sides of the main interface window.

2c. 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 from host

Save to host

Client

Import from remote

Export to remote

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#

All file types can be import/export to faciliate a single source-of-truth, going along for the ride (with benefits), residing on the server’s filesystem with each system’s folder. This is convenient as project files can be hosted and downloaded alongside a visual representation of their systems – towards a digital embodiment of whatever is being developed.

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, to be accessed via XC-Messages:

xcs, xcg, xco

Any file type can be associated with a shell command. By default, the OS’s open or xdg-open command is used to open the file, unless otherwise specified in extensions.cfg, like so:

vtu=paraview --special-options
# perhaps we may want to access XC files with python
xcs=python3 -i path/to/concept_pb2.py
xcg=python3 -i path/to/spatial_pb2.py
xco=python3 -i path/to/vector_pb2.py
# perhaps we just make python have access to XC-Messages:
py=python3 -i path/to/concept_pb2.py path/to/vector_pb2.py path/to/spatial_pb2.py

  • everything to the right of the = is interpreted as a shell command

  • spaces are not permitted on either side of the =, but after that spaces are permitted

2d. Render Scene#

The render scene is an OpenGL context; successive images are the result of graphics objects processed by a shader pipeline.

GL Pipeline#

Currently, a fairly straightforward explicit raster pipeline is implemented, comprised of two programmable stages:

vertex.glsl -> fragment.glsl

VAO layered processing#

There are two types of in-scene graphics (that contain one or more VAOs):

  • metaobjects & metaregions exist in 3D physical space, are visualizations of server-side systems & regions

  • ux elements usually exist in 2D screen space, are built client-side as onscreen text and tools

All in-scene graphics are composed of vertex array objects managing CPU-GPU render data and bindings. During graphics composition, VAOs are organized into layers and passed into the GL pipeline on each render cycle from back-to-front. Layer 0 is reserved for 3D physical space, while layers 1+ are used by UX elements to form a heads-up-display.

Graphics & Metaobjects#

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

To represent local-to-global and global-to-screen transformations, we conform to the standard M-V-P convention, where M is the model matrix (assgined server-side), V is the view matrix, and P is the projection matrix. When moving/rotating an object, its M changes (not the underlying position data). Upon in-scene click interaction, the inverse of this transformation is used to determine the ray intersection.

Users select metaregions by clicking on the visual representation and performing 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.)

  • Double-clicking a metaregion will activate the owning metaobject in the scene and interface.

  • Double-clicking on the background will navigate up a level (activating the parent).

Camera & Shaders#

To paint pixels on each render cycle, VAOs are processed by the render pipeline which then invokes OpenGL rasterization calls including the GPU program associated with shaders/vertex.glsl and shaders/fragment.glsl. Advanced users are encouraged to play with and improve these GLSL shaders (as an exception to our normal licensing terms).

  • Zoom: middle mouse wheel, or multi-touch up/down

  • Rotation: move the mouse while holding the middle button or by holding [Ctrl] (Linux) or [⌘] (Apple).

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.

Anyone connected can test the XC cmd line: test

Numerous XC shorthand functions exist and the list and semantics are continuously updating (spec is not finalized). Thus, these commands are not publicized at this time.

A few useful XC commands:

  • refresh invokes a server-side refresh on the active system, pushing metadata back to ensure everything is up-to-date.

  • reload loads the active system from the server filesystem

  • load users.cfg to updates the team roster on server

… many more to be documented following formalization…

3. Troubleshooting#

3a. Failed Authentication#

Cause:

  • Certificate has expired (failure to renew)

  • Credentials are corrupt or invalid

Fix:

  • Clear your current keys/certs (click button in Authenticatian Failure dialog)

  • In your account profile, unassign the fingerprint (to unassociate the mash).

  • Try again. The app will contact XWS for a new key and certificates

3b. Failed Login#

From the login screen, click the Help button for info and actions. The dialogs will display information to help understand the nature of the issue and suggested actions.

3c. Runtime Error#

Detailed information is available in the application message and error logs.

List the log files:

ls -al $HOME/.local/state/xcompute/xcclient/log/xcclient-*.log

List the error/warning files:

ls -al $HOME/.local/state/xcompute/xcclient/log/xcclient-*.err

Use a built-in text viewer, like so: vi $HOME/.local/state/xcompute/xcclient/log/xcclient-VERSION.err