Space Access 2019

The most interesting space tech conference you’ve never heard about.

Turns out crazy comes in many different forms:

Lady and Gentlemen gather on the last eve of Space Access 2019. We were actually kicked out of the hotel bar because we were too excitable. On several occasions, I was approached with the pickup line “want to see my rocket/engine?” (See below)
I was pretty busy piloting my own XCOMPUTE spaceship. It is powered by high performance computers and good vibes. We were there celebrating our official product launch! Check out emerging capabilities and special offers with our partners R Systems and Rescale.
Hosted by ERPS and SAS, these events run long and hard, all day. It’s exhausting to soak it all in…each talk is so different and interesting…it feels terrible when you must pick and choose. On Thursday night I had a brief 15 minutes slot to introduce the new platform.

Here most’s of the video: (though there wasn’t any music in real life, just me talking)
This short musical montage looks back at our development over the last 5-6 years (from a graphical UI perspective) as we have iterated toward the current enterprise platform. The early 2D FDM prototype codes were truly impressive and beautiful. We’ve taken a detour into more complex 3D FVM, FEM, and other essential methods first before expanding once again. We think this new architecture will give us 100x the power and flexibility of our early numerical codes. Further, we’re looking into the future of advanced machine design and operating systems.
An incredible spectrum of people were in attendance, spanning advanced amateurs, university researchers, aerospace start-ups, and even notable legends such as directors for major US agencies such as DARPA.

The event was structured in a way to maximize people connections to facilitate business in space sectors. The first day was focused on practical space entrepreneurship and business activities. The second day was more ambitious trans/cis-lunar and deep-space exploration. The last day was high-risk high-reward concepts with a keen eye on energy/power systems. Probably more than 50% of attendees held an engineering degree and/or industry experience.
After another long day of talks we were excited to get an exclusive update from SpaceIL founder and recent attempts at landing their Beresheet spacecraft on the lunar surface. Huge inspiration to all, despite the terrible connection and A/V issues.
This is how we have fun and put our bench-top rocket fuel pumps to use when not on exhibit or moving hypergols. Explosions were controlled, mostly. Two ranging margarita parties fueled some of the leading rocket scientists to get belligerent and bash scramjets. Because we’re all so agreeable…
Going into the event I didn’t really have anything good to show. Long story short, the night/morning before I set up my computer in my hotel room and ran a 6.7M element CFD with the A/C directly into that Titan-Z going at full blast. I saved 1/10 of the 10,000 iterations to yield 350 GB of data in about 4 hours. (Each frame is about 350 MB)

unified graphics controller

XCOMPUTE’s graphics architecture is built on OpenGL 3.3 with some basic GLSL shaders. The focus has always been on efficiency and usefulness with large engineering data sets – it is meant to visualize systems.

However, along the way we recognized that we could unify all graphics objects (technically, vertex array objects) in our render pipeline as to not only handle 3d objects, topologies, and point clouds, but provide a powerful framework for in-scene widgets and helpers. We’ve barely started on that:

A basic in-scene color bar utilizes multiple graphics components: Text is rendered with glyph texture atlases, the color legend uses a similar texture technique but with PNG infrastructure. The pane itself is also a graphics object, each with unique definition and functions but unified stylistic and graphics controls. Note, that behind the color bar is the simulation and its meta-regions are also graphics objects with similar capabilities and controls.

As we’re getting ready to launch the product, I’m connecting modules that perhaps didn’t have priority in the past. The other night, I spent a few hours looking at what easy things we could do with a unified “appearance” widget, built in the client with Qt in about 130 lines:

XCOMPUTE’s Appearance Widget allows users to customize color, transparency, textures, and render modes. Style control flags are updated instantly, not requiring any data synchronization!

I then imported a complex bracket geometry and applied a wood PNG texture with RGBA channels projected in the Z-direction:

Triply-periodic bracket structure (held on left, loaded on right) imported as STL and meshed in XCOMPUTE with 440K cells in about 10 minutes. Shown is a highly-computable finite element mesh based on Per-Olof’s Perrson’s thesis.

This looks pretty good for rasterization (60fps @ 1440×2560), but it isn’t perfect….there are a few artifacts and shadowing is simplified. I think the space between the wood slats is really cool and makes me want to grab this thing and pull it apart. Those gaps are simply from the alpha-channel of the PNG image…just for fun. We’ll expose more bells and whistles eventually.

Soon, I’ll show the next step of analyzing such a component including semi-realistic displacement animations.

In the future (as we mature our signed distance infrastructure), we make look at ray-tracing techniques, but for now the focus is on efficiency for practical engineering analyses.


server-client protocol buffer specs

It’s no secret around here that I’ve been burning the candle from both ends in order to complete “The Great Server-Client Divide” as we call this year-long task. A task that has been in planning since the very start.

With big-data applications, its challenging to get a server (simulation state machine) to interact (somewhat generically) with any number of clients without compromising on performance. We studied the principles and the mechanics of this issue and slowly arrived at a viable solution requiring extreme software engineering care.

For our engineering analysis software, we navigated many performance compromises. One notable compromise (compared to game engines) has been on maintaining both high (FP64) and low precision (FP32) data sets for computation vs render — every iteration we must convert and buffer relevant results from device to host in order to maintain a global state with which clients can interact.

(Still, we are finding that proper software design yields a compute bottleneck in GPU-like devices, rather than I/O bandwidth limitation over PCIe — so this extra process is not responsible for any slowdown. We’re measuring and reporting more than 25x speed-up over CPU-only).

A sever-client architecture utilizes a central sever host with any number of OpenCL-compatible devices and filesystem. One or more clients can connect to the server through a network connection, communicating needs and accepting pre-packaged data from the server. The client renders the data using local GPU device.

XCOMPUTE has gone through several thousand iterations to get where we are, and along the way we developed high-level and low-level optimizations and generalizations to further expand our capabilities and performance. For instance, we are approaching the minimum number of operations to synchronize arbitrary numerical data — and our C++ code syntax makes all these operations very clear and human-readable.

It should bit little surprise that eventually there would be a high degree of data structure unification (via dynamic compile-time and run-time tricks), and that the messages required to save/load could possibly be reused in wide-scale communication protocols. After all, both messages require serialization and de-serialization infrastructure, so if the encoding/decoding format is flexible and nearly run-time optimal, why not unify all I/O? Especially if it is easily parallelized and permits flexible usage and sharing with users.

That is exactly what we did; we implemented “protocol buffers” using a schema file definiton to build an array of sources, headers, and libraries that are later linked by the larger application during compile. There are no run-time libraries…it’s essentially a code generator.

The protobuf definition file assigns variable names to types and a specific integer spot; repeated and embedded messages are also possible. Developers have a clear way to package messages and the proto definition file can be made publicly available to bind external applications (to almost any language) to natively interface without compromising the legal intellectual property of the actual code-base. It’s just an interface.

I’m only aware of two good protocol buffer libraries, both authored by the same person (first at Google, then on his own). The only major limitation I’ve encountered is that for both libraries (for various reasons), the maximum message size is limited to about 2^30 bytes, or about 1GB. This presents a challenge to the size of any one system, but should work well for most as large problems should be decomposed into manageable systems, not one huge homogeneous domain with poor numerical complexity.

I could talk for days about message design and how it sort-of parallels your class structures — and how it also is sort of its own thing! Being introspective on “what constitutes a message” can yield huge optimizations across your application in practice. This is because if messages are not well-encapsulated, they will tend to have repetitive or unnecessary data per the context. Ideally, you’d only transmit what is needed, especially given bandwidth constraints. If you can constrain this to a finite set of messages, you’re off to a great start.

Another really neat byproduct of sever-client message unification is that servers already expect self-contained protobuf messages in order to perform operations, such as creating new objects (geometries, algorithms, etc). A command line interface (CLI) could also construct protobuf messages and invoke macro-level commands, just like a client. One could access a simulation via client, CLI, or through files on disk.

Applied to numerical computing, we developed four protocol buffer definition files, each applicable to specific contexts:

  • vector – array-like data that can benefit from arena allocations
  • geometry – topological information specific to a domain
  • setup – numerical system configuration data and associativity
  • meta – user preferences for a specific system

XCOMPUTE has implemented these messages for finite element, finite volume, and are formalizing support for finite difference, lattice-Boltzmann, and advanced geometric representations. The following unified XCOMPUTE file types that somewhat correspond to the aforementioned messages:

  • *.xco – numerical data array for a specific property-key (parallel CPU)
  • *.xcg – topology data for a specific geometry (structured / unstructured)
  • *.xcs – system setup (main project file, recursive directories)
  • *.xcm – metaobject media profile (technically a new 3d media format)

RSA or other encryption can wrap the serialized byte-stream as necessary. When you purchase an XCOMPUTE license, you receive a copy of these definitions along with a Creative Commons Attribution Non-Derivatives license to allow anyone to use them for their own projects and hopefully integrate with ours!