XCOMPUTE-SERVER#
Runtime Configuration#
Several config files are ingested upon program launch.
Administration#
Up to two system administrators can be defined in server.cfg. The first admin must be the email associated with the fingerprint in use, while the second admin can be any trusted user’s email with matching XCOMPUTE-CLIENT credentials.
admin=tech.lead@corporation.com
admin2=their.deputy@corporation.com
fingerprint=TECH_LEADS_ASSIGNED_RSA_FINGERPRINT
input=/path/to/fast/SSD/
output/path/to/fast/SSD/
Due to the possibility of sensitive information and work, it is recommended that prospective admins be restricted to those demonstratably proficient in Linux/Unix environments. They also need to be trustworthy. Questions about system adminstration should be directed to Xplicit Computing by the customer admin on file.
User Access#
To manage team access, edit users.cfg and enter the fingerprints and emails:
allow_guests=false
SOMEONES_XCCLIENT_FINGERPRINT=someone@somewhere.com
ANOTHERS_XCCLIENT_FINGERPRINT=helper@subcontractor.com
...
Set allow_guests=true to permit others (the public, with authenticated XCOMPUTE-CLIENT) to access your project/simulation (with read-only permissions and no file exports). If unspecified, the default is allow_guests=false. For WAN access, configure router port forwarding on external port 11235 to the desired server.
Host Collaborators#
To manage host connectivity, edit hosts.cfg to allow auto-discovery on LAN; specify any collaborating servers:
localnet=192.168.1 # optional, should be commented out if not used (takes a minute to search all addresses)
CLUSTER_XCSERVER_FINGERPRINT=192.168.1.2 # a local cluster's address
ANOTHER_XCSERVER_FINGERPRINT=anothercompany.com # some other domain hosting a public server (or an IP address)
...
An optional localnet entry sets a class-C subnet range to automatically scan for available XCOMPUTE-SERVER connections (between .2 and .254). In all cases, local and wide-area network IP and DNS names are resolved.
Note: the server-server protocol and load distribution are a work-in-progress. Upcoming xcserver releases will take advantage of this functionality.
Compute Defaults#
To manage compute defaults, edit compute.cfg. A few important params include:
ReservedThreads=1 # number of reserved CPU threads (to keep server responsive)
DefaultDevice=0 # 0: let application pick best default
Iterations=500 # default number of steps in iterative methods
Resolution=16000000 # shape resolution is typically between 1e6 and 1e8
ElementCount=40000 # default node or cell count for new meshes
...
Execution#
As with most services, XCOMPUTE-SERVER requires adminstrator (root) privilege.
Before shutdown, save your project via XCOMPUTE-CLIENT so the session can be recalled from storage.
System-managed service#
XCOMPUTE-SERVER can be managed as a service that starts or restarts when the host system boots up, and is shut down when the system is shut down, similar to Apache2 and other persistent host services.
For Ubuntu and Debian systems, the Debian (.deb) package in recommended. Like other Debian packages, adminstrator (root) privilege is required for installation. A new user xcompute is created to run XCOMPUTE-SERVER and manage team projects files. Following setup and restart, the service is managed by Linux systemd.
Check the systemd service status:
systemctl status xcompute
If the service is not running, start it:
sudo systemctl start xcompute
The service can also be stopped:
sudo systemctl stop xcompute
Or restarted:
sudo systemctl restart xcompute
User-managed service#
XCOMPUTE-SERVER can be run manually as an individual user application. No adminstrator (root) privilege is required as the software is installed in a user-owned directory. XCOMPUTE-SERVER runs as process owned by the user, and thus all data files consumed or generated by XCOMPUTE-SERVER are under control of the user. This is most suitable for individual use and where root privilege is not readily available.
Navigate to the executable working directory and start an interactive session:
./xcompute-server
Ensure the listening socket has been bound and at least one OpenCL device is available. Only one xcompute-server instance is permitted, so don’t attempt to run as a user if a systemd xcompute service is also running.
Batch mode#
It is also possible to execute a non-interactive “batch” session to process files without binding a socket, like so:
./xcompute-server --batch some_file.stl
The default configuration will (always) come from compute.cfg.
File I/O#
Client interfaces import/export external files to/from the server, while the server host saves/loads native XC files locally:
Input |
Output |
|
|---|---|---|
Server |
Load from host |
Save to host |
Client |
Import from remote |
Export to remote |
Save & Load#
XCOMPUTE-SERVER saves the project state to the output directory and loads from the input directory, all on the host machine. The project input/output directories should be specified in server.cfg, such as a fast SSD:
input=/path/to/project/
output=/path/to/project/
Project files are organized in a filesystem hierarchy with the definition and supporting files for each system within each folder. (In this manner, each system effectively maps to a folder.) A mixture of external and native formats can be present, with XC files accesssible with XC-Messages:
*.xcs/*.json - system setup
*.xcg - geometry
*.xco - data
By convention, each data property is saved to an *.xco file, which provides performant storage and access. For convenience, a standalone app xc2csv is provided to view data files in a spreadsheet format. Other apps will be inttroduced as the platform matures.
Import & Export#
XCOMPUTE-SERVER can import files locally (for testing or received from XCOMPUTE-CLIENT), including the following formats:
stl, obj, msh, sdf
XCOMPUTE-SERVER can also export files locally (for testing or to send to XCOMPUTE-CLIENT), including the following formats:
csv, vtu, stl, obj, msh, sdf
The default export types for geometries and systems can be defined in compute.cfg, such as the defaults:
SystemExportType=vtu
GeometryExportType=msh