Showing posts with label python. Show all posts
Showing posts with label python. Show all posts

Sunday, October 4, 2020

Desktop Software API's in Python (KiCAD, FreeCAD, Blender, QGIS)

Python wraps around everything

For the last couple of years I have mostly written Satellite Data Processing code in Python and plenty of Flask/Django web services. However Python is also an excellent automation tool for GUI based applications allowing custom plugins to be written and functionality provided out of the box extended by users.

The first desktop application I seriously looked at Python plugins for was QGIS. It was early days of learning how to wrap C++ code using SWIG/SIP etc. In the old mailing list you can find a much younger me making inane comments about mixing wrapper metaphors in QGIS with SWIG + SIP. We have come a long way since then and SIP based bindings are the mainstay of QGIS plugins.

QGIS

QGIS has so many Python plugins that they need a registry of their own. Occasionally QGIS Python gets twisted around itself due to multiple Pythons in the user enviroment. You can also flip the python API around and instead of building a plugin you can turn QGIS into a custom desktop application. Which is what I have done with my basic Airport Viewer demo.

QGIS being a fairly extensive and complex C++ application which takes hours to compile, being able to make small quick changes in python is invaluable.

KiCAD

At the time of writing KiCAD has an extensive Python API for processing the automating the PCB layout part of the workflow and this has lead to many innovations in automating traditionally laborious hand layout or even performing complex simulations / optimization to set trace lengths. For example Josh Johnson has one for laying parts out in a circle and Greg Davill has several for length matching and rendering file generation. My personal favourite among the KiCAD scripts is the one for generation of Interactive BOM.

I am really looking forward to Python script support in the Schematic Editor. Meanwhile programmatic Schematic generation tools like Skidl provide schematic oriented Python fun.

The rendering of the PCB's is often done in Blender. Which has its own set of Python nicities.

Blender

My first foray in creating a Blender API based application was during the Kinect USB protocol hacking days. The data stream had just been decoded and I wanted an easy pipeline to a commonly installed / open-source 3D display software. The Python API is mature enough for people these days to quickly put together motion capture plugins for Blender. This plugin however demonstrates the challenges for creating native plugins for blender, the .pyd files for Python have to be recreated for different versions of Blender for ABI compaitibility.

Getting the binaries working has had me thrashing about and posting in forums, then sticking to a working Blender build with Python 2.7 for about 5 years since I did not want to touch it and break it. My integration actually reversed the embedding process, i.e. instead of using additional modules in the Blender embedded python I embedded Blender in a 3D GIS automation.

Native plugin weirdness aside, Blender Python API is a really powerful tool for creating procedural objects from waves / fluid simulation to astrophysics with amuse.

FreeCAD

FreeCAD is sort of the third part of my physical electrical / mechnical design triumvirate. I occasionally design parts for KiCAD in FreeCAD, or bring multiple boards together to test enclosure fit. FreeCAD also has an extensive python library which is leveraged by KiCAD part library maintainers to parametrically generate parts.

The scripting in FreeCAD can be used much like the PCB layout scripts in KiCAD to create this with circular symmetry, like ball bearings which are difficult and repetitive to do by hand.

Final words

There are lots of other pieces of desktop software I have used that have started shipping with Python API's to address the never ending demand from users to easily automate repeated tasks. The live process for making this blogpost in somewhat recursive fashion can be found here.

I have even made videos withs a proprietary one, I will live that here for anyone interested in my attempts at a voiceover.

Wednesday, July 22, 2020

Microservices the hard way - folders in EC2 Instance

For day to day work I wrangle containers in EKS these days. However when doing personal projects EKS is a luxury (baseline cost being $70 or so per month). So I decided to do microservice development for the rain radar project using no Docker, no Kubernetes but using:

  • multiple venvs
  • multiple service folders
  • environments in .env files (secrets in plain text)
  • web service start using @reboot in Cron
  • scheduled services using ... ya Cron

The whole thing started with noble intentions to use lambda's all the way however I got stuck in using S3-SNS to trigger the lambda and decided to scan the S3 bucket using timestamps to find latest files to process. More on the pitfalls of that later.

The major microservices handle are:

  • Raw radar data preparation using custom hand crafted algorithm, being ported to Rust here.
  • Inserting prepared data to DynamoDB as a sparse array and serving this via Flask.
  • Nowcasting using the timeseries of sparse array of rain observations also serving results via Flask.
  • Capturing rain events and nowcasts and creating text and gif to send to twitter.

Each of these applications consumes the other to some extent and is sort of separated in responsibility. I decided to deploy them with basic a folder per application on the /home/ubuntu directory, with a venv per folder.

I had it like this for a while. Then I got tired for sshing into the box and git pulling in each folder. So I decided to write a fabfile per application which would do this for me and created deployment keys which would be used to pull the code to this folder. Then I got tired of running multiple fabfiles and decided to setup a polled process which run the fabfiles and git synced the code from a master pipeline.

Eventually I got around to bootstrapping the whole VM using Packer + Ansible playbooks. The development work for it was done locally using Vagrant with Hyper-V as the VM provide to test the same Ansible playbooks. I will follow up on this with a few characters on twitter.

Once the initial Packer AMI is established the choice is to either keep building this image or to move away from the whole VM based old-school stuff to a more modern/fun Kubernetes way.

Saturday, April 4, 2020

Distributed Locking from Python while running on AWS

In the day and age of eventually consistent web-scale applications the concept of locking may seem very archaic. However in some instances attempting to obtain a lock and failing to do so within a limited window can prevent dogpile effects for expensive server side operations or prevent over-write of already executing long running tasks such as ETL processes.
I have used 3-basic approaches to create distributed locks on AWS with the help of built-in services and accessed them via Python which is what I build most of my sofware in.

File locks upgraded to EFS

File based locks in UNIX file-systems are very common. They are typically created using the flock command, avalaible in Python under os-specific flock API. Also checkout the platform independent filelock. This is well and good for a VM or single application instance. For distributed locking, we will need EFS as the filesystem on which these locks are held, Linux-Kernel and NFS will use byte-range locks to help simulate locally attached file system type locks. However if the client loses connectivity the NFS lock-state cannot be determined, better run that EFS with enough replicas to ensure connectivity.
File locking this way is very useful if we are using EFS for holding large file and processing data anyway.

Redis locks upgraded to ElastiCache

Another popular pattern for holding locks in Python is using Redis. This can be upgraded in the cloud-hosted scenario to Redis-Elasticache, This pairs well with the redis-lock library.
Using redis requires a bit of setup and is subject to similar network vagaries and EFS. It makes sense when using Redis already as an in-memory cache for accelration or as a broker/results mechanism for Celery. Having data encrypted at rest and transit may require running an Stunnel Proxy.

An AWS only Method - DynamoDB

A while ago AWS published an article for creating and holding locks on DynamoDB using a Java lock client. This client creates the lock and holds it live using heart-beats while the relevant code section executes. Since then it has been ported to Python and I am maintaining my own fork.
It works well and helps scale-out singleton processes run as Lambdas to multiple lambdas in a serverless fashion, with a given lambda quickly skipping over a task another lambda is holding a lock on. I have also used it on EC2 based stuff where I was already using DynamoDB for other purposes. This is possibly the easiest and cheapest method for achieving distributed locking. Locally testing this technique is also quite easy using local-dynamodb in a docker container.
Feel free to ping me other distributed locking solutions that work well on AWS and I will try them out.

Wednesday, August 14, 2019

Open-source Sustainability (The tale of 2 package managers)

Last weekend I had the priviledge to attend the 10th PyconAU and listen to some amazing speakers. I went with my I will write markdown on the fly and make a blog-post at the end of the day mindset. Even though I did write a lot of markdown on the fly, I haven't gathered the courage to push these unedited notes into a public post. Excellent examples of live-blogging from conferences here.
What did happen was that the niggling doubts I had around how open-source works in the real world outside of just the code crystallized. This was as a result of 2 very good talks , one about how the PyPi project works and another around Open-source sustainability beyond money.

For the last year I have been writing and reviewing a lot of React Frontend, Python backend (Flask/Django) and Notebooks code. Both frameworks are super easy to buy batteries for where the included ones are running out of juice. Simply via pip install and npm install you can climb onto the shoulders of giants who are library maintainers and the life-blood of lean start-ups everywhere. However the maintainer burnout is a thing and start-ups when building their stack should be highly cognizant of this. Package repository burnout is also a thing. In my time in the software industry I have seen Maven repositories disappear. More recently NPM go through an identity crisis and the left-pad incident.

The PyPi talk gave me great background on a tool I use every single-hour without too much thought. It takes some dedicated volunteers to keep the dream alive. Who according to Dustin Ingram are :

  • Unemployed and bored and poor (but super talented) 
  • Paid for by their employer (thanks employers who support FOSS) 
  • Not getting enough sleep (or in my case time with the family)


Vicky's talk covers another aspect. Developers and maintainers need more than money to keep going, they need back-up. The community need insurance against the bus-factor and burn-out. I have been guilty of this myself, putting a few dollars behind features I would like to see in BountySource instead of diving in. This has become more so as I have progressed in my career and become increasingly time-poor. Talking about this would anyone at VSCode like to claim the few dollars we put here ?

I love the longevity and discipline of project warehouse and will find some time to contribute to it. I also look forward to a similar alternative to npm, rather than a caching proxy with community behind it.

Sunday, November 25, 2018

Onion IoT module Python SPI

Some say China is the country of 80-20, things are complete and great to 80% , the remaining 20% of polish is left hanging. The Mediatek CPU used in the Onion IoT modules suffers from a similar shortcoming. There is an working SPI bus, but it is simplex ( OUCH!!) . Simplex means only receive and transmit can take place at a time.

For interfacing the Onion Module with Energy Monitor IC's this is a huge blocker since the typical communication flow with this IC's runs as:

  1. Write a 8 or 16 bit register address to the SPI bus
  2. Immediately read-back a 16bit value over the SPI bus while the chip-select is held low.
The proposed remedy to this after a bit of debugging and probing with logic analyzers is to directly use the user-space SPI c-library or to fix the python-spidev library with an xfer3 method which does a special write where the clock keeps going, the first bytes are written and next bytes are read.

I have started on the path for fixing the Python library on my fork. OpenWRT build system seems happy with my efforts so far. It remains to be seen if we can communicate with the energy monitor ASIC's. Contributions are much appreciated.



Sunday, September 16, 2018

PyconAU 2018 - Keep Notes

This is a raw dump of notes I took on keep while attending PyconAU. Each to be fully expanded to an article on its own. Suitably redacted to keep my intrusive thoughts to myself. 

Documentation and Technical Writing
  • Persuasive, Referential, Literary, Expressive. Writing pull requests. Foucault on discourse.
  • Think goals, Think audience, Write (structure, conventions). Active vs Passive (active is shorter). Bullets.
  • Plain English, easy words. Edit. Find good writing.
API Design
  • Forestry Data. User interface for developers. Access control , pagination. API versioning. Break in controlled fashion. Deprecation schedule.
  • Accept versioning header. URL Path versions. Less emotional versions. Small changes version transformer. Django middleware.
  • Auth- Token. OAuth.
  • Standardized (familiarity, avoid pitfalls, standards win) - jsonapi.org (next,.previous), graphql, Basecamp. Swagger.
  • Larger data sets out of band
  • Documentation. Selling page. Dev account, demo key, root url. Encodings, formats
  • OpenAPI, Swagger, tools, docs/code, reduce friction, automation.
Working with Spatial data in Python
  • Routing. Isochrones, Latte line.
  • Db spatial extension. Point in polygon.
  • Basemaps, JS library.
  • Geomesa.
Multi-lingual Python
  • i18n, l10n, language_code, locale, po (files translation). Language session choice flow. Url-conf.
  • trans and trans block tag. Every file must have the i18n tag. Use lazy in models.py.
  • makemessages in all depencies. Zh_cn.
  • Model fields to enter data. Keep tables in _zh_cn. Transifix.
Web without Javascript
  • Intercooler.js. CSOF… use web 1.0 submissions in a 2.0 way.
  • Large data. Out of-band.
Database optimization
  • Write amplification. Partial index. Hash, GIN(generalised inverse index) , BRIN (min/max)
Design for non-designers
  • Choose few fronts. Use different spacing. Curated fonts. Beautiful Web Type. Fontpair.co . Google Fonts. Making things clean (whitespace). Data analytics. Less is more. Unsplash, Photopin, Fiverr. Importance of imitation.
Designing environments with Docker
  • Front end builder. Task queue/Celery. Postgres. Docker compose .
Hypothesis to replace auto-manual tests
  • Hypothesis for testing by schema. Always true unless there is a bug. Fuzz the code with variety of input. Faker. Django integration push model and clean up. Quick check.
  • Generators.
  • Use lib2to3 parse through Python code and refactor / reformat. Bowler, safe refactoring for Python. Reuse refactoring code.
Tom Eastman - Keynote
  • koordinates, geospatial data. Effective learning for programmers. Effortful retrieval.
  • Fixed vs Growth mindset.
Lightning talks
  • DRF model pusher. Ably, Django Channels.
  • Claire Krause, GA satellite imagery analysis
  • Wrapt, allows introspection of wrapped functions. Context manager.
Many Python Web Frameworks
  • Cherrypy, Class based views. Falcon API first framework , fast, returns json for microservices. Hug with syntactic sugar. CCBV. Tornado, Async. Sanic.
Women in Python
  • Jason Fagon.
  • Katherine Johnson.
  • Carol Willing (Jupyter)
Celery and alternatives
  • Celery message formats, task chaining. Disable pre-fetch, long running. Own task queue. RQ (redis queue). Huey. TaskTiger(distributed locking). Dask (pydata), scheduler distributes pandas and numpy dataframes. Task chaining, celery import chain. RQ failed queue.
Trouble with sensor data
  • Kafka stream processing. React and Socket.io. HTML5 gyroscope API.
Pub conversations
  • RNN (Fast.ai), pre-trained model zoo.

Sunday, August 13, 2017

PyconAu 2017 - Melbourne

I recently attended my first PyconAu - a cauldron of programming goodness. It was held in cloudy and grey Melbourne at the convention center. The exact same venue I attended the Nvidia conference a while ago. It was three days of information flow and meeting very interesting people. I jotted down some quick notes in my Keep and I will flesh them out here for my own reference.

These were the sessions where I had more detailed notes and some photos:

GnuRadio Python bindings and simulator. SoapySDR. HackRF simplex hardware including a freaky demo of using playback attack to unlock cars by copying car remotes.
An update on the state of MicroPython. A live demo with I2C read from gyroscope controlling a servo. New stuff like help('modules'), upip install, VFS , assembler, Zephyr RTOS etc. Really got into this one. The idea of having line by line firmware building convenience and a REPL on an embedded device is oh so appealing.
The Murchison Widefield Array(MWA) and sampling the universe at 655MSPS - Rocket IO to Xilinix. FPGA Fourier variants and finaly 24 of 256 spectral channels trickling back to Perth at 10Gbps. The processing electronics is double Faraday caged to prevent RF feeding back into the telescope.
The messaging of data from IoT devices while minimizing data usage and allowing convenience and transfer of state. Various contenders are JSON, Avro, Protobuf and MQTT over Websockets or simple HTTP, with advantages in HTTP v2 due to header compression via HPACK.

Presentation featuring GUI's for IoT devices and a glowing orb seen in a famous Trump photograph. With interesting details about Progressive Web Apps and Javascript based IoT controls.
Another very very impressive demo came from Russell showing Python running on 6 different platforms on a few minutes. After that I should really checkout our BeeWare. Will have to write a full length article on it as well with a proper usage tutorial to earn these great looking challenge coins.

During the breaks people were leaving notes seeking jobs, offering jobs or setting a topic for a lightning talk. The looking for employees board was slightly daunting but I put up a brave little ad featuring Aerometrex anyway. I also gave a brave little talk about my LSTM and energy monitoring time series adventures.
The last day had this fun little guy controlled via Python and a Jupyter Notebook. On my list of toys to get to play with my son.
I also enjoyed the end of the day talk from Xavier on scientific data cleaning using Pandas was great as well. I quickly put it to use to clean my Tindie buyers list to send out a MailChimp Promo, not very scientific, but useful when you are running a crowd funding campaign. After that it was a couple of days of sprints and getting ATM90E26 to play nice with ESP32 and Micropython, that is another blog post altogether.

Thursday, July 4, 2013

A simple ray tracer in Python - with CGKit and RTree

First of all I am over-reaching by calling this a ray-tracer, it is more appropriately called a "Splatter". I am simply projecting all the top-triangles in an OBJ model onto a raster for True Ortho generation purposes. It was a fun project for playing with Kd-trees and line-triangle intersections. The OBJ models are geo-referenced so it does not make sense to take them into a purely CG/Game oriented ray-tracer like Blender and lose the geographic context, as well as fiddle around with setting up orthographic cameras and render resolution to match ground-sampling distance. Doing it through a proper ray-tracer typically also requires setting up appropriate lighting, while I just want to sample the pre-exisiting texture in the model.
Direct vertical projection render from script
Properly lit render using Terragen

As usual a bit of googling located the python batteries that will perform the intersection as well as parse the obj mesh I have at hand. CGKit fits the bill perfectly both in terms of parsing as well as ray-triangle intersection.

However testing every triangle for intersection for every grid-cell quickly becomes horridly slow and begs for a hierarchial index to speed up the look-up and only process the triangles in the path of the ray. Here I picked up RTree to build a 3D index , a kD-Tree of Bounding volume hierarchy to speed up intersection testing.

After building the tree I went back to only testing relevant triangles in CGKit and dug through the parsed OBJ data structure to extract the texture co-ordinates of the intersected face. The barycentric description of the intersection point is sufficient to sample the texture for the right pixel colour and transfer it to the raster grid. For those interested in the implementation, the code follows, improvement suggestions are welcome. Multiprocessing is thrown in for tile-by-tile processing.

The point of the ray-tracer was to generate true-orthos for GIS use, as a side effect of implementing the ray tracer we can now generate true-orthos from both the top and the bottom of the model. The main article about true-orthos can be found here.

Thursday, November 8, 2012

Blender as a Python module, happy coding from Eclipse

This post is going to be a reminder to self in-case I ever need to do this again, or I am cloned and the clone is wondering how the original spent his time.

Get Blender source
Set options as pointed by IdeasMan to build as Python module
Compile with Visual Studio
Set BLENDER_SYSTEM_SCRIPTS as an environment variable, small undocumented caveat where reading the source actually helps.


Import Bpy and Python 3.2 in Eclipse and use Blender algorithms in headless mode.

Friday, July 13, 2012

Lots of images to lots of OBJ to lots of images

Working with Structure from Motion and Dense matching can be a lot of fun. If the project get sufficiently big though, the reconstructed models is broken up into multiple Wavefrom Object files and can be difficult visualise and render. I like doing most of my rendering in Blender, and the handy Python API for loading OBJ files makes the job of getting all the files in easy.

To grab a bunch of obj files from a folder into Blender simply script this in the console:

import glob
objects = glob.glob("Filepath\*.obj")
for obj in objects:
    try:
        bpy.ops.import_scene.obj(filepath=obj, axis_forward='X', axis_up='Z')
    except:
        print("Failed "+obj)

Just like that you create a scene with 100's of object tiles. Make sure they are viewed in outline mode, so that the display is zippy while setting up lights, cameras and animation action. Start off the render and go get a beverage.


Tuesday, June 28, 2011

GSOC 2011 - PyOssim

The awesome Ossim library has served me (and disaster situations in New Orleans and Haiti) in getting large amount of imagery processed accurately and without too much manual messing around.

OSSIM already sports a JNI wrapper tying the rich C++ library to the JVM (I loathe to say Java - it is such a verbose and bureaucratic language). Coming from C++, an Ossim wrapper should attach to a more dynamic language. Indeed the OMAR developers chose to write it mostly in Groovy+Grails.
Ship Tracks in OssimPlanet

This year the GSOC project is aiming to wrap some important bits of the vast library using SWIG for use in CPython. Writing a SWIG wrapper can be painful at the best of times as I found out during my Kinect SWIG work. In spite of the hurdles Vipul has made decent progress and made some of the previous work with JNI + SWIG compile in the Python context. Now he is starting fresh from a purely Python perspective, we will figure out which functions are important and should form the seed for a python wrapping project.

If it all becomes too hard to do with CPython, we might stick with the link to JVM and script Ossim with Jython.

Tuesday, November 23, 2010

Python Bindings for Accidental API - and vivi.c

I started a couple of Kinect related projects. Firstly, writing linux kernel driver based on v4l2 and cloning vivi.c to act as a stub. The responses indicate that a gspca based approach might be better, but I had a lot of fun hand hacking the vivi.c code and adding 2 video devices from 1 driver. I will have to wait till someone puts some gspca stub code out.
Secondly, I completed a first working version (as in can get some image buffers) of the win32 python binding from Zephod's code. I followed the swig how-to's and had to resort to typemapping to extract the image and depth buffers, but it all worked out in the end. Not quite as well as I had expected on the 1st attempt but I can replicate some of the early work on Linux in windows now. The colour's in the RGB image are flipped, I will have to change the data order. A lot of frames are dropped so the response is not as smooth as it could be.
Kinect Python on Windows

Sunday, November 21, 2010

Hooking Kinect into Languages - Python and Matlab

I spent the morning wading through SWIG to hook up Zephod's win32 Kinect code into Python. After getting the interface file and Cmake in place, I got unsupported platform type from the MSVC compiler.

I will also need to get some Matlab integration via Mex files in place to allow classic academic usage and student projects rolling. With my budget constraints and time constraints I can offer a small bounty to get this done. Contact me if interested.

Also on the todo list is v4l2 integration and a gstreamer plugin. The principle of operations of these drivers is simple, allocate a buffer, fill it up with data from the kinect and push it up the chain for further processing instead of just displaying as current things do.

rainbow depth

The new python wrappers for libfreenect allow me the luxury of using matplotlib colourmaps to redisplay the depth as I see fit. It introduces lags, but who cares we have depth in Python for $200.

Monday, September 20, 2010

Processing TerraSAR-X in Python and R

Finally some 12GB of TerraSAR-X Quad-pol data finished downloading. I have essentially 3 PolInSAR capable sets (if the notorious X-band coherence holds up). I can process them in RAT but that requires converting them to floating point and more bloat, the TSX data is in a CInt32 form. Solution was to use GDAL's TerraSAR-X Cosar support and read subsets directly into Python. I took this opportunity to do some nice unit testing in Python. The result was the simple monstrosity here. It extends tsx_dual class I had implemented before.
R von Mises

Then I moved onto some phase difference statistics and encountered for the n-th time the nicely non-Gaussian von Mises distribution. Trying to use R Circular Statistics from Python became the bane of my existence tonight. RPy2 current code is unsupported on windows so I am lacking package import. At least I managed to hack it into compiling with the following tricks:
  1. Copied Rinterface.h from R source distro
  2. Hacked Rinterface.h to remove uintptr_t typedef
  3. Hacked na_values.c to remove dynamic allocations (compile time non-constants)
  4. Copied R dll's from "bin" to "lib" in R install
This makes rpy2 build and install, but I am left with - Assertion failed: PyType_IsSubtype(type, &PyLong_Type), file rpy\rinterface\/na_values.c, line 166  - at runtime obviously due to my hacks. Well I am missing this code block in my hand hacked things:

/* on some platforms these are not compile-time constants, so we must fill them at runtime */
+  NAInteger_Type.tp_base = &PyInt_Type;
+  NALogical_Type.tp_base = &PyInt_Type;
+  NAReal_Type.tp_base = &PyFloat_Type;
+  NACharacter_Type.tp_base = &PyString_Type;


Now to figure out where to put it and von Mises are in Python.

PS: So it is "Talk like a Pirate Day" so "R - ARRR in".

Sunday, September 5, 2010

Building a PID controller for the Quadcopter

My students have finally taken some inspiration from the mechanical engineering folks and started on building a PID controller for the quadcopter using simulink blocks and various experiments to measure the angular acceleration produced by the motors. They are still far from having a rigid-body simulation of the system but apparently the PID controller in simulink can be stabilized. Another challenge will be to port the PID controller to Python, building a rigid-body simulation can be attempted with PyODE.

Quadcopter System DiagramThey had also been asking for a block diagram and/or circuit diagram. So I obliged with an Inkscape block diagram, circuit digrams are best left to the manufacturing professionals of Arduino and Gumstix.

Quadcopter test rig ended up being not so fancy and brick based at least it worksThe measurement of angle with time shows non-constant angular acceleration, but the curves can still be fitted with a second order polynomial. The angular rate curves look even more quadriatic, indicating increasing acceleration with time.

Quadcopter Magnetometer YExtracting the acceleration from this should be pretty straight forward as long as we fit a polynomial to a relatively safe part of the dataset. I think a fair number of reptitions and logs of the same experiment will be needed to smooth out the wiggles.

Monday, September 7, 2009

Scaling Python applications - Parallel Python easy heterogenous clustering

Python is often accused of being a slow interpreted language, inspite of all the proof of being very easy to accelerate critical sections with native code and large projects such as Youtube being written in Python. Python is a great glue language holding together disparate bits of code and providing easy interface to multiple languages, an invaluable proto-typing tool.

I write some naive inverse distance weighted interpolation for a set of field data and it ran painfully slowly (taking 1 second per interpolated point). So I looked into accelerating this with Parallel Python , this was surprisingly easy to set-up and to recode the algorithm in parallel mode. It is embarassingly parallel with the same operation being done on each grid point. Extending from 1 laptop to 7 different machines resulted in around 3 times increase in execution speed. Admittedly I ran the job over wireless and some of the machines were windows desktops with little dedicated resource while others were servers running linux. However the excercise demonstrates the flexibility of Python.