Overview / Usage

This demonstration project simulates various computer fans to determine the best candidates for rapid prototyping (3D printing). This simulation process virtually validates theories about these fan designs, reducing the amount of physical trial-and-error in creating an efficient, computer fan shape that provides directional airflow.

Inspiration

I chose to write this demonstration project as part of "The Great Cross Architecture Challenge" to learn DPCpp while also applying DPCpp to an engineering problem. Additional inspiration for this project came from wanting to brush up on modern Cpp tooling, cleanup OpenGl graphics code from a previous project, and utilize under-utilized computing hardware.

Usage

Full details on how to build and run this project are on GitHub. In brief:

1. Get and build DPCDemo from the repository
2. Make a *.STL computer fan file (or use one of the test fans in the test-fans folder)
   1. If you make a fan, the fan should be the same size in the X and Y dimension and flat on the Z dimension
   2. DPCDemo will automatically center and scale the fan to fit within the simulation cube.
3. Run the application, specifying a *.STL computer fan file.
   1. To run with the default device and test fan, simply run DPCDemo.
   2. To specify a custom device and/or fan to test, specify --device and/or --input "FAN_FILE"
   3. DPCDemo will run for the default number of simulation steps, simulating the fan design on the device, outputting two scores at the end. Fan designs which result in higher scores are better!

Methodology / Approach

Infrastructure

The DPCDemo application consists of a simulation thread and a rendering thread. Both of these threads are launched from _DPCDemo.cpp, _with overall configuration stored in SimConstants.h

If ENABLE_GUI is disabled in SimConstants.h, the rendering thread will not be part of the compiled binary. There also will be no interactive user input (or rendering, besides console output) when DPCDemo is running.

The simulation thread:

• Loads a fan and sanitizes/standardizes it (ModelLoader.cpp)
• Starts simulating it, reporting results when done (Simulation.cpp)

The rendering thread:

• Gets updates from the simulation (Synchronizer.cpp)
• Displays the current fan position and particle positions (Renderer.cpp)

Several supporting classes (and libraries, see "Technologies Used") assist these primary classes.

Simulation

This application is not entirely physically accurate, but aims to instead be accurate enough to get results necessary to compare various fans. This simulation consists of three main parts:

1. Particle vs Particle collisions
   1. Particles collide with each other and bounce, if they get too close to each other.
      1. Gravity is not simulated.
2. Particle vs Fan Mesh collisions
   1. Particles collide with the fan mesh and bounce off of that mesh.
      1. While the fan mesh can add (or subtract) energy from the particles, the particles can't affect the fan. That is, the fan always moves at a consistent rate as defined in SimConstants.h
3. Particles move and are tracked when they exit the simulation cube.
   1. When particles exit the simulation cube, the energy they have is summarized in two scores.
      1. The first score measures how well the fan mesh transfers energy into the 'air'.
      2. The second score measures how well the fan mesh pushes the 'air' in a given direction.

Good fans should result in better measurements for both scores because a good fan mesh should push the particles in one direction while also transferring energy to it (providing airflow).

Results

I ran DPCDemo for a normal fan, a gear-like fan, and a wavy plane. All runs used 2048 particles with 3000 simulation steps, for a total of 15 milliseconds in real-time simulated.

Results, as posted on GitHub, were not what I was expecting. Essentially the larger meshes performed better, most likely because this simulation is not adequately accounting for different fan sizes.

Future Work

While this application is 'released', there's always more to do. Potential improvements include:

• Improve normalization of fans so that fans of different sizes can be fairly compared.
• Adding in more simulation parameters (gravity, E&M, inelastic collisions)
• Designing more fans and running them through the simulation.
• Changing how random particles are introduced to make flow patterns more visible.
• Determining what changes need to be made to run DPCDemo on an FPGA device

​

Development Process

This was my first time developing a DPCpp application. While several things went very well, there were also quite a lot of hiccups along the way. I definitely learned a lot about DPCpp technology/implementation, and will also be able to use that knowledge for future applications.

What went well

Writing essentially Cpp code that runs on the GPU is much more fun than writing kernel-specific code. The SYCL API reference guide, Data Parallel Cpp book, and DPCpp reference documentation were all great sources to use.

Notably, using buffer objects to transfer data to/from the host and device was amazingly simple to do. I also highly enjoyed using sycl::stream objects to diagnose the kernels that ran on devices, which greatly simplified the diagnostic process. Lastly, the **sycl::exception **messages (from .what()) are incredibly useful.

Once I was able to access DevCloud, building and running remotely went fairly well.

What didn't go well

I unfortunately had a few problems getting DPCpp setup initially

• An unrelated OpenCL install via 'vcpkg' pulled in headers which conflicted with the Intel oneAPI headers.
• The test system I had was using the wrong Intel drivers. The bad drivers appeared to support the Intel GPU, but wouldn't actually work. This was compounded by default_selector selecting the "Intel(R) Gen12LP" device (the GPU), instead of the (working) CPU.
  • Once I installed the right drivers, the GPU appeared as "Intel(R) Graphics [0x9a49]" and worked well!

After this initial hurdle, I enjoyed relatively smooth sailing, although I still encountered a few issues:

• Not all of the samples wrap queue calls in try/catch blocks. This resulted in exceptions being thrown that I thought were driver bugs, but really were bugs I had written by experimenting with the samples.
  • For instance, the GPU I had didn't support doubles and also didn't like the work group size I was providing to it.
• The Intel Compiler is much slower than the MSVC compiler and doesn't output what it's doing in the console.
• The Intel DevCloud tools don't have _man _help pages or argument-based -h, --h, /? help. Without enough documentation, I was only able to do queue-based runs, not queue-based builds.

Technologies Used

Development / Infrastructure

• Visual Studio Community 2019
• vcpkg
• argparse

Simulation

• Data Parallel Cpp (DPCpp)
• GLM
• libigl / Eigen

Rendering

• OpenGL / GLFW 3 / GLEW / Dear ImGui
• GLM

Repository

https://github.com/GuMiner/DPC-experiments

Other links

• The Great Cross Architecture Challenge