Ever since a friend in highschool explained to me that computer programs are written by mortals, something that I had never before considered, I have enjoyed the entertainment of programming. I particularly remember trying to recreate a submarine game in Qbasic, with animated introduction and everything, working on it for months on end never to actually quite finish it ─ thus setting somewhat of an unfortunate personal trend. Switching from DOS to linux, I acquainted myself with C, C++, and finally Python, which till today is my language of choice after Dutch. Most of these early programming steps have long been lost, including, to my regret, the submarine game. I take comfort in thinking that some things are best remembered in the glory of lost potential.
On that historical note, below is an account of a few of my more recent undertakings.
The Nutils project, short for Numerical Utilities, is a Python framework for building Finite Element computations. Identifying features are a heavily object oriented design, strict separation of topology and geometry, and CAS-like function arithmetic such as found in Maple and Mathematica.
The project started in 2011 as the "Beam" code; a preliminary rewrite of the heavily specialized finite element code that had grown out of my PhD. Passing by the names "HOM" and "Finity", by which time the code had gotted in use by my colleagues at Eindhoven university, we eventually settled on "Nutils" as being both reasonably descriptive for the scope of the project, and available in the .org domain ─ a rare combination. Pronounced as "noodles", the name inspires a particular version naming system and several other references on food.
The primary design goals of the nutils project are:
- Readability. Finite element scripts built on top of nutils should focus on work flow and maths, unobscured by finite element infrastructure.
- Flexibility. The nutils are tools; they do not enforce a strict work flow. Missing components can be added locally without loosing interoperability.
- Compatibility. Exposed objects are of native python type or allow for easy conversion to leverage third party tools.
- Speed. Nutils are self-optimizing and support parallel computation. Typical scripting inefficiencies are discouraged by design.
The nutils are under active development, and are presently in use for academic research by Phd and MSc students. Painfully lacking at this point is documentation. This is certainly something I intend to fix, but currently other priorities rank higher. Hopefully the example scripts included in the repository are at least partly self explanatory. For more information about nutils visit the project website, or jump to the github repository directly.
Halfspace is a python module that models displacements of a semi-infinite, isotropic, homogeneous, linear elastic medium, loaded by any configurable number of displacement sources. Its main purpose is to compute flat earth approximations of displacement, strain, and stress, as resulting from faulting or extraction processes.
This project is a result of my PhD work. Its main purpose of this project is to evaluate the analytical expressions published by Okada in 1992 (paywall), solving the equations of elasticity for arbitrarily rectangular dislocation sources in an elastic halfspace, and make them accesible in python. Similar libraries exists written in fortran, such as dc3d or Tim Wright's oksar3, and in retrospect it would have made more sense to interface any of those and save the trouble. But it is here now, and trouble it has been, so I will keep it here in case anybody finds specific use of a C code.
The code along with some example scripts can be found on github, along with a quite extensive readme demonstrating its use. The C module should compile without any prerequisites, but to interface with python it requires the CFFI module. As explained in the readme, the python module implements a Source object that enables linear operations. The Okada source is the only derived class for now, which can thus be superposed to form more complex geometries. I hope to find the time to add an inflation source as well to make for a more complete tool, though I have no use for that myself at present.
Replicator is a general purpose http and ftp (no https) caching proxy server written in python. It reduces bandwidth by merging concurrent downloads and building a local 'replicated' file hierarchy, similar to wget -r. The cache is also accessible through a web interface.
This is my oldest living project. I tried but failed to trace back exactly when I started working on it, but it must have been some time near the start of the millenium, the days that the internet involved a 65k dail-up modem and a sense of anxiety whenever that meter was ticking. I had just been introduced to debian linux and looked for a way to keep two systems up to date without having to download the same package more than once. Existing solutions like squid seemed overly complex for such a modest task, and a proxy server seemed like a nice little project to get my feet wet with my other recent find, the python scripting language. It would stay with me for years to come.
By 2004 the code had grown into something I was comfortable in putting online, and I registered it at freshmeat, nowadays freecode, to give it some publicity. Predating any knowledge of version control systems, the release notes are still the best historical account I have of the project. To my surprise it got picked up by a guy Tom Poplawski, who contacted me requesting some modifications to make the proxy better suited for caching gentoo linux's portage packages. He set up a forum thread which soon counted many pages, and actually managed to get replicator accepted into gentoo as an official package. Not sure if anybody is using it today, but it's certainly nice to still find it there.
In May 2007 I moved replicator to sourceforge and started using its svn service, so things are easier to follow from that point. Unfortunately, by that time I had started my PhD and time dried up. The project reached 4.0alpha and stayed there. End 2013 I moved it to github in an attempt to organize the internet. Every so often somebody sends me a patch that I will consider for merging, but, realistically speaking, it's the only kind of activity that the project remains to see. It's functional though, and reasonably documented in form of a brief readme, so don't let its vegetative state keep you from using it for simple caching needs.
Before discovering jekyll, I have had a post-commit hook active on my university's svn server that converted markdown formatted text into html using the excellent pandoc. I liked to think of it as a wiki with proper revision control and convenient off-line editing. All the more pleasantly surprised I was to learn of github's readily available jekyll hook, which carries all of the same advantages and more. If you are interested to learn about jekyll I recommend their quickstart as a good place to start, and feel free to shop around in the template to get yourself up to speed.