Solarian Programmer

My programming ramblings

Compiling Xfoil on OS X

Posted on January 23, 2014 by Sol

If you are into airfoil analysis as an amateur or as a professional you will need a quick way to estimate the aerodynamic characteristics (lift, drag and momentum coefficients) of a given airfoil. The classical approach to calculate the performance of an airfoil is to use a coupled inviscid/viscous flow solver. On a modern computer this analysis will usually take less than a minute. Compare this with a full CFD approach that uses the Navier-Stokes equations for the laminar part of the flow and the Reynolds Averaged Navier-Stokes equations for the turbulent part of the flow. In the former case a typical analysis can run from a few minutes to a few hours on a modern PC.

Xfoil is an open source interactive program for the design and analysis of subsonic isolated airfoils. Xfoil uses a potential flow solver coupled with a Boundary Layer solver to calculate the flow field around an airfoil. The author, Mark Drela, provides a Windows binary on Xfoil’s web page. If you are a Linux user building Xfoil from sources is straightforward. For OS X, well, it is a bit more complicated to build the code from sources.

►  Continue reading


OpenGL 101: Matrices - projection, view, model

Posted on May 22, 2013 by Sol

The code for this post is on GitHub: https://github.com/sol-prog/OpenGL-101.

This is the fourth article from my OpenGL 101 series, if you need to refresh your memory you can find a list with my previous articles at the end of this post or, you can click on the OpenGL category from the right sidebar.

Until now we’ve used the default OpenGL view for drawing our geometries and textures. While it is possible to draw any 2D geometry we can think of using the default [-1, +1] x [-1, +1] space that OpenGL sets for us, it will quickly became cumbersome and inefficient. Consider the problem of drawing four equilateral triangles, with different positions and orientations, like in the following figure:

►  Continue reading


OpenGL 101: Textures

Posted on May 17, 2013 by Sol

The code for this post is on GitHub: https://github.com/sol-prog/OpenGL-101.

This is the third article from my OpenGL 101 series. In the first two articles we’ve seen how we can open a window and draw OpenGL primitives: points, lines and triangles. We’ve also seen how we can assign a particular color to a vertex and use this to paint a two-dimensional surface with a smooth color.

Suppose now that we want to draw something more complex like the ruins of an ancient building, think a bit about how we can draw something as close as possible to what we can see in the real world. Theoretically, we can model everything with triangles and calculate the colors corresponding to each vertex, but this quickly gets out of hand - we are limited by the memory of our graphics card and by the speed of our graphics processor. A much practical approach to create the illusion of reality is to use textures that can be glued on the geometrical representation of our computer world.

In this article, we will concern ourselves only with two-dimensional textures, OpenGL can use other type of textures: 1D, 3D, cube textures etc … Technically a texture is just a container for data, you can store any numerical values in a texture, usually color values, and process this data in your shaders, usually in the fragment shader.

►  Continue reading


OpenGL 101: Drawing primitives - points, lines and triangles

Posted on May 13, 2013 by Sol

The code for this post is on GitHub: https://github.com/sol-prog/OpenGL-101.

This is the second article from my OpenGL 101 series. In the first article we’ve seen how to open a window for our OpenGL application with the GLFW library and how to compile and run the code on Windows, OS X and Linux. It is time to actually draw something using OpenGL.

First, let me mention that OpenGL is a low level API, this means that it has no support for drawing complex geometrical objects. It is the programmer’s job to combine the geometrical primitives from OpenGL in complex shapes and bodies. The basic geometrical primitives that the core OpenGL profile provide to us are points, lines and triangles.

►  Continue reading


OpenGL 101: Windows, OS X and Linux - Getting Started

Posted on May 10, 2013 by Sol

The code for this post is on GitHub: https://github.com/sol-prog/OpenGL-101.

This is the first in a series of articles that will get you up to speed with programming in modern OpenGL. I have no claim about being an expert in the area, this is an edited version of the notes I took working on various OpenGL projects in the last year. I think the best way to really understand a subject is to try to teach it to another person. Constructive comments are welcome and I will update this series based on your comments.

First step in creating an OpenGL code is the creation of a window, using the underlying OS, and to attach an OpenGL context to it, OpenGL by itself can’t open a window. Using a particular OS APIs to create a new window will make our code non-portable; the usual approach is to use a library that abstracts the process of creating/destroying windows on a given OS and also manages the user’s inputs through mouse, keyboard or touch. There are a number of libraries that can abstract the process of creating an window for us, like, in no particular order, GLUT, Freeglut, SDL, GLFW and many others.

In these notes, we are going to use GLFW because it is a small, flexible and modern library, portable on all major operating systems.

Other useful libraries that we are going to use are GLEW - this will let us use the latest OpenGL functions in a portable way, GLM - a small mathematical library and FreeImage for reading and writing images in various formats.

►  Continue reading


The Mandelbrot set in C++11

Posted on February 28, 2013 by Sol

The code for this post is on GitHub: https://github.com/sol-prog/Mandelbrot_Set.

Yet another how to draw the Mandelbrot set article ? Well, yes and no, on the one hand fractals are fun and on the other hand, it could be instructive to play with complex numbers and lambdas in C++11. Also, the article presents a not so common continuous coloring procedure based on a slight modification of the Bernstein polynomials.

Please note, that calculating the Mandelbrot set can be done more efficiently if one uses the GPU (using OpenGL shaders for example) and not the CPU.

►  Continue reading


Sorting data in parallel CPU vs GPU - In which we show more graphics

Posted on February 7, 2013 by Sol

The code for this post is on GitHub: https://github.com/sol-prog/Sort_data_parallel/tree/TBB in the TBB branch.

This is a sequel to my last article in which we’ve shown that you can, relatively easily, implement a parallel merge-sort algorithm using only functions from the standard library of a programming language, C++11 in this case. We’ve also compared our implementation with a state of the art sorting function from the CUDA 5.0 SDK thrust::stable_sort.

Following some concerns, raised by a commenter - snk_kid, I’ve made a new set of tests based on a state of the art CPU parallel sorting function from Intel’s TBB. His main these was that my previous comparison between CPU and GPU was misleading, because the use of raw threads in merge-sort is not efficient and, in general, I should refrain myself from writing about this subject unless I use task based parallelism or high level parallel libraries.

►  Continue reading


Sorting data in parallel CPU vs GPU

Posted on February 4, 2013 by Sol

The code for this post is on GitHub: https://github.com/sol-prog/Sort_data_parallel.

You can read the second part of this article.

For many programmers sorting data in parallel means implementing a state of the art algorithm in their preferred programming language. However, most programming languages have a good serial sorting function in their standard library. It appears to me, that the obvious thing to do is to first try to use what your language library provides. If this approach is not successful, you should try to find an existing library that is used, and consequently well debugged, by other programmers. Only as a last resort, you should implement a new sorting algorithm from scratch.

In the case of C++, we have a well tested sorting function in the STL, std::sort, unfortunately std::sort will use only a fraction of the processing power available in a modern multicore system.

►  Continue reading


Building Clang and libc++ on Ubuntu Linux

Posted on January 17, 2013 by Sol

Updated on 26 January 2014 for Ubuntu 12.04.4 and Clang 3.4.

Clang with libc++ represents today a viable alternative to GCC for C and C++ programmers. I make no claim that Clang with libc++ is necessarily superior to GCC with libstdc++, but it is definitely a more feature complete C++11 alternative. According to the libc++ website, libc++ is 100% complete C++11 implementation on Apple’s OS X and, from my tests, works equally well on Linux. Even if you plan to ship your C++ application compiled with GCC, I think it is a good test to check your app for errors by building it with a different compiler and library.

In this short post, I’m going to show you how to build the latest Clang and libc++ on a Linux box. I’ve tested this procedure on Ubuntu 12.04.4, Ubuntu 12.10 and Linux Mint 14.

►  Continue reading


Building Lua 5.3 on macOS

Posted on January 12, 2013 by Sol

Updated 7 October 2017

If you want to build yourself the latest Lua on macOS there is a simple recipe for this:

  • Start by downloading the Lua source code from http://www.lua.org/ftp/.
  • Extract the archive (I did this in my Downloads folder).
  • Open a Terminal and navigate to the Lua source code:
1 cd Downloads
2 cd lua-*

►  Continue reading


C++11 sort benchmark

Posted on October 24, 2012 by Sol

The code for this post is on GitHub: https://github.com/sol-prog/Sort_benchmark.

A good sorting routine is a building block for many numerical algorithms and, because of this, most modern programming languages provide one or more sorting algorithms in their standard library. C++ is not an exception. What varies, from one C++ implementation to another, is the performance of the sorting algorithm.

C++11 lets you use three sorting functions std::qsort, std::sort and std::stable_sort. While std::qsort comes from the C roots of C++, std::sort and std::stable_sort are provided by C++’s Standard Template Library. The new C++11 standard requires that the complexity of std::sort to be in the worst case. Historically, in the C++98 standard std::sort was defined as on average, with a possible worst case scenario of .

►  Continue reading


C++11 async tutorial

Posted on October 17, 2012 by Sol

For a few years now, we live in a multiprocessor world, starting from the phone in my pocket to the parallel quad-core beast I have on my table. Today, you could easily buy a six or twelve core machine that is several orders of magnitude more powerful than the super computers from a decade ago.

As programmers, we need to be able to use at full capacity the available computing power, you can’t buy a new computer and expect that your serial code will run faster. You need to write code that can run on multiple core machines or you will deliver a low quality product to your potential clients.

The new C++11 standard allows us to maximize the use of the available hardware directly from the language. Today, you could write portable multithreading code using only the standard library of the language.

►  Continue reading


C++11 timing code performance

Posted on October 14, 2012 by Sol

Prior to the release of the C++11 standard, there was no standard way in which one could accurately measure the execution time of a piece of code. The programmer was forced to use external libraries like Boost, or routines provided by each operating system.

The C++11 chrono header file provides three standard clocks that could be used for timing one’s code:

  • system_clock - this is the real-time clock used by the system;
  • high_resolution_clock - this is a clock with the shortest tick period possible on the current system;
  • steady_clock - this is a monotonic clock that is guaranteed to never be adjusted.

►  Continue reading


Building Cling (the C++ interpreter) on Windows

Posted on September 2, 2012 by Sol

11 September 2012 update

The last revision of Cling, r45925, doesn’t need any modifications in order to compile on Cygwin, I’ve removed some outdated instructions about manually editing the libcling.exports file.

3 September 2012 update

After a discussion with the main developer of Cling I’ve removed a paragraph about adding some hard codded paths in the Clang sources, this was an unnecessary complication. I’ll keep updating this article if we’ll find any other simplifications.

In my last article I wrote about Cling, the C and C++ interpreter. If you want to have a taste of what Cling can do for you, read my earlier post or this one. In short, Cling is a C++ REPL that uses Clang and LLVM for just in time compilation and parsing of your code. Currently, Cling can be officially compiled only on Unix like operating systems (e.g. Linux or OSX). What if you can’t, for various reasons, use a Unix like OS ? Well, this post is for you, the Windows user!

In principle, you could use Visual Studio to compile Cling, however because of the incompatibilities between Clang and Visual Studio, the resulting interpreter will let you use only C code. At the time of this writing, a Visual Studio compiled Clang is not able to build C++ executables … A C only interpreter, while useful, is not so attractive, at least not for me.

►  Continue reading


Cling a C++11 interpreter

Posted on August 14, 2012 by Sol

A C++11 REPL may sound strange, after all C++ is generally seen as a compiled language. However, any programming language can be implemented as a compiler or as an interpreter and Cling happens to be an interactive C++ interpreter based on LLVM and Clang.

If you’ve ever programmed in a language that can be used in a Read-eval-print-loop or REPL you already know what productivity boost can be to be able to test an idea without waiting for your build system to compile your code. Even with tools like make you need sometimes to wait from a few seconds to a few minutes just to see the effects of some small change in a particular piece of code.

►  Continue reading