ICCFD10, Barcelona

PSA: Abstracts for ICCFD11 are due on 18 Feb 2020!

Amazing destination conference opportunity in Maui, Hawaii

Every two years, the International Conference on Computational Fluid Dynamics is held in a different iconic city across the globe. ICCFD conferences begun in 2000 as the merger of “Numerical Methods in Fluid Dynamics (ICNMFD), and the International Symposium on Computational Fluid Dynamics (ISCFD); which had been running since 1969 and 1985, respectively.” According to the ICCFD homepage.

In early 2018, I submitted two abstracts and was lucky enough to be invited to present a poster on “Scalable HPC Building-Block for Multi-Disciplinary Systems” and complete paper on “Unified Geometries for Dynamic HPC Modeling”. I’ve published a few papers before, but this felt like a new experience; here I was submitting for peer review intimate technical details on the inner workings of some of my original innovations. In the past it was always part of academic group. I worked for two months to bring together my 20-page paper, leaving the presentation until the week of the event…

Pretty familiar experience for most engineers — those minutes leading up to a big presentation…
This balanced tree approach to geometry type taxonomy permits nice inheritance and functional polymorphic optimizations. It is also really interesting to resolve the characteristic similarities and differences between types. There are embedded levels of orthogonality in many spaces. This yields a complete solution space to address all analysis challenges.
In the red, it says that across types we found on order: 50X span in memory usage, 60X span in IO usage, and about 20X speedup when running on GPU vs CPU. Not bad!
Now that the work part is done, I can now look around…
Barcelona is an absolutely gorgeous city, and maintains its own special timeless charm. This is pretty much a typical back alley.
Many interiors have simply stunning craftsmanship and taste. Visual inspiration all around!

The lovely coastal city of Sitges, Spain!
The world-famous multi-century construction project, Sagrada Familia.

Food. Okay let me just say that perhaps my favorite element about Spain was the food. Fresh, flavorful, and affordable. Tapas around great, but we made a point to try many different types of restaurants ranging from known tourist spots to tiny spots that only open for a few hours in the late evening to serve a couple families. Honestly, almost every place we tried had something special about it and several of them we just had to come back for a second or third time. Really, we should have taken more food pictures.

To make up for it, here are a few treats:

Hope to see you at ICCFD11 Summer 2020 in Maui, Hawaii!

high-performance schema for science & engineering

It’s advanced and universal?

Easy to use and FREE??


Wouldn’t it be great to be able to access data easily with any of your favorite languages?

Build advanced apps and workflows?

XCOMPUTE utilizes a new strategy (originally developed by Google) to express complex data between computers / sessions as protocol buffers.

When you save or load to disc or transmit something over a network, the associative data structures present in your computer’s RAM must be flattened (aka serialized), buffered, and eventually reconstructed (aka deserialized) so that they can be transmit in linear fashion across a wire or into a storage device and back again.

There are many ways to do this, but most are not suitable to big data.

We’ve elected to use a special protoc compiler to auto-generate compatible interfaces that provides native access across many languages. They’re essentially feather-weight code headers or libraries that allow you to tie into xcompute.

They also sport speeds approaching the theoretical limits of the attached devices and channels (PCIe, etc).

Messages™ by Xplicit Computing provides standard support for:

While xcompute-server remains a proprietary centerpiece of the XC ecosystem, we’re excited to announce our plan to release our other official Apps, free & open!

This way, everyday users do not have to worry about subscription to xcompute-client. It makes collaboration that much easier.

Hosts maintain their xcompute-server subscriptions and now can invite friends and colleagues freely, and share results as they please with said Apps.

You own and control your data, while Xplicit continues to focus on providing high-quality, unified technologies.

For a technical overview, please read this below excerpt from the README provided with the Messages™ bundle:

for complex systems, FEA, CFD, EDA, and computational geometry


These proto files provide direct access to xcompute messages (file and wire) by generating accessor functions for your favorite languages. This empowers xcompute users and non-users to be able to directly manipulate and access the setup and data to/from xcompute — in a high-performance universal way — suitable for integration with other applications and scripts. Theses four files are central to the xc ecosystem (e.g. both open and proprietary apps), organized as follows:

  • system.proto – domain-specific parameters, associations, references
  • vector.proto – arrays and linear attributes that benefit from packed arena allocation
  • geometry.proto – topological description of elements and regions for a specific domain
  • meta.proto – user profile and meta-data for a specific system

  • This protocol buffer format can deliever high-performance, elegant, and flexible numerical messaging across many domains of science and engineering. (e.g. single- and double-precision floating point data, etc)

  • universal formats for storage and transmission between demanding applications
  • cross-platform accessors and serialization utilities
  • flexible associative and vectorized data patterns
  • object-oriented modularity with reverse and forward compatibility
  • supports multi-threaded I/O within vectors and across files

  • Limitations:
  • maximum individual file size is 2GB, limiting individal systems to ~256M nodes (limited by Google’s 32-bit memory layout)

  • Large systems should be decomposed into several smaller systems if possible — for many reasons. It’s more efficient and accurate to specialize the physics, mediating across regions where required. Try to not solve extra DOF’s unncessarily by making one huge domain that solves everything. Memory requirements vary across methods, but is generally limited by your compute device memory…not the storage format or SSD. It is up to each workgroup to determine what is an appropriate resolution for each study. A top-down systems approach is the best way to resolve from low to high fidelity and maintain accountability across the team…


    Auto-generated bindings are provided for the following langauages: C++, Obj-C, C#, Python, Java, Javascript, Ruby, and Go. In your language environment, import the relevant files as headers or libraries. Statically-compiled languages such as C++, Obj-C, and C# may require linking to static library libxcmessages.a .

    In your environment, various classes should become available. In C++ they can be found under the namespace Messages:: . Refer to the *.proto definitions for how each attribute is defined, knowing that your access pattern is built from these assignments directly. You can access this associative database using getters and setters…

    In C++, the pattern for accessing primitives (bool, int32, int64, float, double, string) looks like:
    auto some_value = msg.something();

    Repeated fields (vectors, etc) can be accessed somewhat normally. Range-based iteration:
    for (auto entry : msg.vector() )
    something = entry;

    Or alternatively for parallel iteration:
    auto N = msg.vector_size();
    #pragma omp parallel for
    for (auto n=0; n'<'N; n++)
    something[n] = msg.vector(n);

    More complex data structures may require mutable getters:
    auto N = other.vector_size();
    //get a reference to mutable object
    auto& vec = *msg.mutable_vector();
    #pragma omp parallel for
    for (auto n=0; n<'N'; n++)
    vec[n] = other.vector(n);

    Please refer to the Proto3 Tutorials for typical programming patterns.


    If you’re an advanced application programmer, you may wish to build upon our bindings to customize against your own projects. This is encouraged as long as existing definitions are not altered. Use a Google Protobuf 3 Compiler to generate your new bindings. A protoc 3 compiler may be readily available in a package manager or installed from online sources or binaries. Proto2 will not work, must be Proto3+.

    After protoc is installed, make a directory for each language and run the compiler from shell or script:
    > mkdir -p cpp python java javascript ruby objc csharp go
    > protoc --cpp_out=cpp --python_out=python --java_out=java --js_out=javascript --ruby_out=ruby --objc_out=objc --csharp_out=csharp vector.proto system.proto spatial.proto meta.proto

    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.

    new GPU mesh generator

    Everyone hates meshing. Well that’s about to change…

    To give a brief taste of what’s to come (for you scientists and engineers), here’s a short intro to our brand-new hardware-accelerated mesh generator. What’s really cool about it is that it creates near-optimal tetrahedral (and eventually hybrid) meshes essentially automatically. There are only a few knobs to turn. It does this by defining shape with implicit Signed Distance Field (SDF) — other refinement controls (grading, curvature, feature size) can be derived directly from the background’s SDF. The SDF can be defined with analytical functions or with triangular faceted surface references. We describe the process in our recent ICCFD10-145 paper:

    So nodes use Delaunay triangulation to find associativity to repel neighboring nodes along each interior edge. Pseudo time integration displaces all node positions… though those near boundaries or SDF surfaces are iteratively projected back (normal) to the interface to conform. As the nodes rearrange and move more than a characteristic radius, the set is re-triangulated to update associativity and the process repeats. After many iterations, all elements are annealed to their local size function and the shape is resolved. The last step is to remove illegal hulls from the Delaunay-defined convex hulls in a surface unwrapping procedure.

    The process is illustrated with the infamous Stanford Bunny:

    Stochastic meshing process with 20K nodes, unrefined: a) Shape is defined by reference surfaces used to solve SDF background. b) Nodes are injected into valid SDF locations and equalized. c) Triangulation updates topology with over-wrapped mesh (comprised of convex hulls). d) Elements are evaluated and cleaned against SDF while surfaces are unwrapped. e) Original (darker) mesh superimposed over new mesh to visualize spatial deviation. f) Close-up showing error around high-curvature features.

    Assuming adequate background SDF resolution, this technique proves to be fairly agnostic to complexity. It’s a robust method, but requires some serious parallel computing when converting from discrete geometries. For F number of reference faces, the winding number calculation scales on order of F log F to determine inside vs outside — something very easy for humans but heavy for machines! Here’s a slightly more realistic engineering component example:

    In this test, a tet mesh of 40,000 nodes (about 200,000 cells) is generated for finite element analysis (FEA) of liquid hydrocarbon rocket engine injector (quarter). Slices through the SDF-derived size field are shown, followed by the resulting mesh. Curvature refinement is not present, showing lack of size refinement around fine features…

    To learn more, please visit www.xplicitcomputing.com/geometry