Web Interface for OpenLava

Openlava is a GPL fork of LSF 4, and as such is a pretty fully featured job scheduler.  I use frequently LSF in my day job, and use Openlava as a substitute when I just need a familiar environment to test things out.  I felt Openlava lacked a good scripting interface, as (like LSF) it provides only a C API for job management, so I wrote some Python bindings for Openlava.

To test it, I wrote a web interface to Openlava that enables users to view detailed information on jobs, queues, users, and hosts, and for administrators to perform management activities such as opening and closing queues and hosts.  Users can submit new jobs too using a web form.

In addition to the web interface, there is a RESTful API, that can be used to request information programmatically.  To test the API, I wrote a client tools package that removes any complexity from dealing with the remote cluster, and a bunch of command line tools that mimic the behavior of the Openlava CLI enabling remote submission and management of  the remote cluster.

You can view a demo of the web interface, view the documentation, or download the server or client tools from Github.

PXE Rescue Environment

Invariably, when something goes wrong, I can never quite find the correct CD with the rescue image on it, or the CD drive stops working, or I need to download it, or whatever. Something had to change, so I decided to create a PXE boot environment using pxelinux that would enable me to perform system rescue and hardware maintenance operations just by turning the machine on.

PXE is built into just about any network card firmware these days, even on home PCs, its great for performing remote installations, it is ubiquitous with HPC cluster installations and has been stable for about a decade.

There are plenty of useful tools around for hardware fault finding, maintenance, and system rescue, and I had no intention to create a new one, so I simply took the tools I normally use, and adapted them for PXE.

Features

  • SpinRite – Originally written to adjust the physical layout on the drive, SpinRite has evolved into a wonderful hard disk recovery tool that has some pretty amazing recovery testimonials.
  • CloneZilla – I primarily use this for creating a solid backup of systems that I know I can restore from. It can backup to remote servers over SSH, and i’ve found it to work pretty much flawlessly over the years. It is also good for cloning windows machines and deploying bare metal images in general, but mostly I just use it to create a backup prior to doing anything likely to toast the system.
  • MemTest86 – RAM testing suite, great for finding memory errors and verifying memory upgrades were successful.

DBAN – Probably my most common requirement for this tool, DBAN is a secure disk erasing suite that meeds DoD and other requirements. I resisted the temptation to make autonuke the default option for unknown MAC addresses.

SystemRescueCD – A pretty comprehensive linux environment for fixing things. Comes with various partitioning/recovery and backup/restore tools. I use this rarely, but when I do its pretty invaluable.

NTPasswd – Resets passwords from windows based systems that do not use whole disk encryption. Usually I use this when i need access to a corporate laptop when the help desk are unable to perform an action or fix a problem.

A number of these tools come with additional tools such as FreeDOS, and hardware inventory/diagnostic tools. I included most of them too even though its unlikely I’ll ne

ed them, it was almost no effort.

By default exit and boot from local media.  More common options are nearer the top.  Infrequently used options are in submenus below.
By default exit and boot from local media. More common options are nearer the top. Infrequently used options are in submenus below.

 

Configuration

Most of these tools are Linux based and it was simply a case of moving the files from the Iso to my tftpboot directory, and taking the appropriate configuration from the isolinux.cfg and putting them directly into the pxelinux.cfg/default file.

Most tools have many possible boot options, so I picked the common ones and put them at the top of my menu tree. The rest went into submenus in case they are needed.

tftpd-hpa supports the -s (Secure) option which sets the root to a specified directory, therefore all paths within the configuration are relative to the chroot environment. (/var/lib/tftpboot on Debian based systems)

All files in the tftpboot should be writable only by root, and the tftp daemon should run as an unprivileged user.

DHCPD needs to be configured to allow booting/bootp and with the next-server directive. There are many guides to doing this such as the PXE web site.

Download

I cannot distribute SpinRite as it is proprietary software and I do not own the copyright, however everything else is packaged up ready for download into your tftpboot directory.  To install SpinRite, download SpinRite from GRC, open the Exe and create an ISO.  Once you have created the ISO, put it in tftpboot/spinrite/SpinRite.iso.

Mesh refinement with SnappyHexMesh

Mesh refinement is probably one of the hardest components of OpenFOAM, for me this mainly revolves around snappyhexmesh and blockmesh, with one or more STL files exported from SolidWorks as the input.

The first thing to get right is the position in the the blockmesh, you can do this using a transform, or by changing the coordinates in the blockmeshdict.  Then check the refinement box is suitably sized, this one was too small so I made it larger using the refinementbox settings:

refinementBox
      {
          type searchableBox;
          min (-1.0 -1.4 0.0);
          max ( 8.0  1.4 2.5);
      }

Next up is to look at the basic refinement and improve that, currently, the basic mesh looks like this:

Using feature edge detection should align the cells better with the edges of the features.  First we run surfaceFeatureExtract on the STL file, then update snappyhexmesh to use edge detection.

   features
   (
       {
           file "seven.eMesh";
           level 10;
       }
   );

I also turn on feature snapping

nFeatureSnapIter 5;

This makes the edges much cleaner, but the mesh is still too course.

Adding more layers of refinement around the car should improve the mesh some more, to do this we use the addLayersControls settings below:

nSurfaceLayers 3;
expansionRatio 1.3;
finalLayerThickness 0.7;
minThickness 0.25;

Next I make the bounding box slightly finer using blockmesh

blocks
(
     hex (0 1 2 3 4 5 6 7) (80 32 32) simpleGrading (1 1 1)
);

At this point I also need to turn up the max cells a little, and add another refinement level

maxGlobalCells 12000000;
refinementSurfaces
{
     seven
     {
     // Surface-wise min and max refinement level
     level (5 6);
     }
}

 As you would expect, mesh size increases dramatically, as does the time to create the mesh.  The result is improved, however the quality of the mesh is still poor in places, this will need further effort.

Loguino support for DS18B20 temperature sensors

The Maxim DS18B20 digital thermometer provides 9-bit to 12-bit Celsius temperature measurements over a 1-Wire interface providing accurate and inexpensive temperature readings.

Kyle Gordon contributed some code that builds on Jim Studt‘s 1-Wire library and Jordan Hochenbaum’s DallasTemperature implementation to integrate into Loguino.

Now you can enable the DS18B20Poller and loguino will capture temperatures from any attached DS180 series sensors.

 

OpenFOAM rotating boundary conditions using rotatingWallVelocity

So far my model has used only a single STL file with no patches, and did not take into account the rotation of the wheels and tyres.  I figured out the OpenFOAM part from this thread on CFD-Online, and used paraview and solidworks to modify the model.

I’m working with a large assembly, with each component as its own part which makes getting things in the right format fairly easy.  The first thing to do is save the whole assembly as individual STL files.

As this created a few hundred files, all with spaces in the name, I opened them in paraview and used the Append Geometry filter to create a single object for the front axle, rear axle, and everything else.  For each of the new geometries, i added an Extract Surface filter.

As I managed to get my solid model in a strange location in Cartesian space, I performed a translation to rotate and move them to the middle of the bounding box.  I could have also moved the bounding box in blockmeshdict.  I then saved the three surfaces as chassis.stl, faxle.stl, and raxle.stl. Use the ascii file format.

Paraview calls the solids ascii (I’m assuming binary if you use the binary file format) since these dictate the name of the patch that snappy will create, it makes sense to rename these based on their file names.  These then need to be concatenated into a single file.  I used some sed foo to do this.

This then gives me three patches, seven_chassis, seven_faxle and seven raxle.  These need to be defined in the initial condition for U.

Originally there was just a single definition:

"seven_*"
    {
         type            fixedValue;    
         value           uniform (0 0 0);
    }

However, we now need to define the three patches explicitly.  The first is easy, as its the everything else part.

"seven_chassis"
    {
         type            fixedValue;    
         value           uniform (0 0 0);
    }

However, for the rotating boundary, we need to know a few more things.  The first is the origin of the rotation, I created a point in the center of the axle and manually applied the appropriate transformation to get the center of rotation.  As I’m assuming that there is zero toe and zero camber, this is trivial.  In the future I may wish to improve on the model in which case I will have four patches, and I’ll add some sketches to the model to work out the correct axis.

The axis of rotation in my model is the y axis, which again is trivial in this case.

Lastly I needed to work out the speed the wheels are rotating at.  I am modelling the car at a speed 40ms−1, and Omega, the boundary condition is measured in rads/second.

First we calculate the distance travelled in one revolution of the wheel.  I have 13 rims with 205×60 profile tyres. This gives a circumference of 1.8146Meters giving 22.04 revolutions per second.  1 Revolution is 2pi radians, giving 138.5rads/sec.

"seven_faxle"
      {
          type            rotatingWallVelocity;
          origin          ( 0.839 0 0.2775 );
          axis            ( 0 1 0 );
          omega           138.5;
      }
      "seven_raxle"
      {
          type            rotatingWallVelocity;
          origin          ( 2.753 0 0.2775 );
          axis            ( 0 1 0 );
          omega           138.5;
      }

Environmental Monitoring with Loguino

Whilst I originally designed Loguino to pull data from the MegaSquirt ECU in one of my cars, as a tool its grown way beyond that. Something I always wonder (Usually just after I’ve checked in on the ferry, or crossed into spain…) is ‘did I close the garage door?’ the door is electric, and its easy to forget to close it properly as depending on the state of the door, pressing the close button doesn’t always mean the door will close fully. To quench my paranoia I installed a web cam and used a 3G router and VPN to connect back to my private network. This means I can visually check the state of the garage door from anywhere, whilst I rarely leave the door open, the peace of mind is a wonderful thing.

Looking out of the garage via the webcam

Now that I also have a network connection to the garage, it gave me an opportunity to add some additional monitoring, whilst security is important, there are easier things to rob in the neighborhood, and that’s what locks, alarms, and security guards are for, however with the various leaks, fires, and other disasters that can happen in a garage, I thought it interesting to be able to monitor the temperature, (too cold – I need to turn off the water, too hot – I need to call the fire brigade) humidity, (leaky pipes?) and gas. (Interesting to know what I’m breathing in.)

Arduino Ethernet Board with POE supportUp until now I’ve been relying on the Arduino Mega, this is great for standalone logging as it has many pins, lots of memory, and is very forgiving, however for monitoring a remote site with a few sensors, it is somewhat overkill and lacks an ethernet controller built in. I could of used an Ethernet Shield, however since I don’t need the pins, the Arduino Ethernet makes much more sense, its relatively cheap, small, and has more than enough pins as well as a built in Ethernet controller.

HS1101 Sensor forms an RC circuit to measure relative humidityThis meant doing some work for Loguino, as whilst its modular and doesn’t assume anything in the code about the board, it always had the Arduino mega in mind, since I recently moved to CMake from ARSCons, I decided to get to grips with dependencies a little, and made it easier to use different boards, features which require a specific board are no longer included for other boards. This means selecting Arduino Ethernet as the target will disable things that require second serial ports etc.

From there it was onto the sensors, Antratek are based nearby, so I decided to give them a shot, they had a bunch of interesting sensors mainly from Parallax, for humidity I used a HS1101 which forms an RC circuit and is very easy to use, a CO2, and CO sensor which I haven’t got working yet, TMP102 temperature sensor, and BMP085 barometric pressure sensor, which also has a built in temperature sensor, together making a very nice package. In addition I added a motion sensor.

For the temperature, pressure and humidity sensors it was easy to write a simple poller plugin for each of them, the motion sensor was already supported by the Digital Poller, so required no extra code, however I added the ability to name the output from the digital poller to my todo list.

The ethernet controller required some work too, I made the decision that this would be a server rather than a client, and simply open a socket and print the metric values down the wire to any connected clients, this was easy to code, and works in the same way as the Serial Output Logger, only over a TCP connection. It would be fairly easy to write a client that pushes data to a server using a web service call, but this fits my immediate needs.

Soldering it together was also fairly simple, the BMP085 and TMP105 use I2C and just require a few wires, and the HS1101 uses a simple RC circuit. Once built, it looked like this:Connecting to the device gives the usual loguino CSV output, I wrote a small script that polls the data and puts it into a database which can then be queried with flot.  The TMP102 reads over temperature, so i need to do some work there but its consistent and has been up for about a week in the living room now.

Looking out of the garage via the webcam

Loguino 1.0

I’ve been working on Loguino for a few months now, and the first stable release is now available.  Loguino is a data-logging solution based around commodity(Arduino) hardware. Underneath is a powerful data-logging framework that can be adapted to log just about anything. Loguino focuses on data capture, rather than analysis or visualization. It was born out of the need to capture data from a Microsquirt ecu without a laptop connected, but has evolved into a more generic tool. 

Loguino can log from the following inputs:

  • Megasquirt Automotive Engine Control Units
  • LIS331 Accelerometers
  • ITG3200 3 Axis Gyro
  • NMEA Compatible GPS Devices
  • Analog Pins (Voltage)
  • Digital Inputs (High/Low)

Loguino writes output to the following outputs:

  • SD Cards
  • Serial Devices

Each poller and logger is optional, enabling and disabling features is easy using a configuration file at build time.

Loguino is built using cmake, and is designed around the arduino mega, although other boards will work just fine.

There are a few of us using it now, and I feel its stable enough that others might also find it useful. 

I have a few code improvements I want to roll out in the coming weeks to make things more pluggable as per the design, then I’ll focus on the following features:

  • Download from SD via Serial
  • Add a lifetime to metrics
  • Add throttling
  • CANBUS Support

Loguino is hosted on google code at: http://code.google.com/p/loguino/

I hope some of you find it useful, and I’d be delighted to hear from anybody who is interested in using loguino.

Automotive Arduino Power Regulator

Jonathon Oxer and Hugh Blemings describe an excellent power regulator for Arduino in automotive applications in their book “Practical Arduino Projects”. Loguino doesnt need to be notified about a power failure, but it did seem sensible to be able to provide a buffer which may help when the car is being started.

Parts List

  • IC1: LM294OCT-5 – An automotive grade 5v regulator
  • D1: 1N4001 Diode
  • F1: 3A Fuse
  • C1: 100uf Capacitor
  • C2: 47uf electrolytic capacitor ideally rated to 16v max
  • C3: 47000uf capactor, rated to at least 60v

 

Graphing OpenFOAM Convergence

Understanding convergence is important when modelling CFD, often its easier to understand this visually than it is to scroll through the log file manually.  I created a script that will take the log from simpleFoam, and dump the residuals into a CSV file, or create a HTML report.

The former can be read into excel and graphed, or the HTML report can be viewed directly.  It uses flot and provides a scrollable, zoomable interface to the data.

Flot graph of the residuals of a simpleFOAM Run
The same data zoomed in
Residual values shown using csv output and an excel chart

Scanning the car with an Xbox Kinect and Paraview

I have a pretty accurate drawing of the Seven, from the drawings i’ve created models in OpenFoam.  I want to do the same for the Fury, however I don’t have drawings of the bodywork.  Drawing freehand in Solidworks would take me forever, so I decided to try scanning the car using an Xbox Kinect and the openkinect libraries.

The first thing that you need to do is get a point cloud from the xbox kinect, this is not quite straightforward as it seems. First the sync_get_dept() returns a disparity image, not cartesian points, so some conversion is required.  The openKinect wiki has most of the background information required.  The calibkinect library can do most of the calibration work, this can be formatted into whatever format suits you best.  I chose wavefront’s format as it stores the point normals and can be read by both MeshLab and Paraview.

Getting a single disparity image is quite easy, however stitching many together is more challenging.  Fundamentally in order to scan an object you need to know the following:

  • Where the camera is relative to a fixed point in space
  • Which direction the camera is pointing.

Assuming you know these two things, you can do a fairly simple matrix transformation on the points to move them into the appropriate location. Initially I tried to find a clever way to triangulate the position and direction of the kinect, it would be great to be able use it like a wand, however this requires significant levels of accuracy, and the only sensor on board is a tilt sensor.  GPS wont cut it, I had some ideas about using a bunch of cameras, or ultrasonic sensors, but in the end I shelved that idea for now.

Instead I decided the easiest way to get a usable scan was to do things the old fashioned way.  I only need to scan half the car, as its symetrical.  As such I created a box around the car.  This allowed me to position the camera at a known location.  I used a tripod to hold the kinect, and took images at one meter intervals from about one and a half meters away from the car.

I then cleaned each mesh in MeshLab so that I just have the car, and no background.  Then loaded each one into paraview and applied transformations to each file until they were lined up based on the measurements I’d taken earlier.  This worked pretty well but required some manual adjustments for the first image in each direction.

The end result is good enough for a first attempt.  I’ll load the file into Solidworks and start drawing.