How much tax is paid on your landfill?

/0 Comments/in , /by
What do you know about Landfill Gas Emissions? I’m betting not much if you’re not directly working in the industry. As you’ve stared forlornly at the departing garbage truck at 5am after being awoken by its imminent arrival only to recall that you didn’t put the bins out last night, you probably haven’t given too much thought to where it’s going and what happens to the garbage.
Well let me ease your mind and put you off your breakfast. After leaving you in its dust (and your pyjamas), that truck was heading to one of about 450 landfills all around Australia. When it dumps its load of garbage, bacteria are going to start a feast on your leftover spaghetti bolognese and while doing so will emit gas. That gas they emit while eating your garbage is about half methane (CH4) and half carbon dioxide (C02), both of which are greenhouse gasses.
Heard of the carbon tax? Well in basic terms the Clean Energy Regulator, part of the Department of Climate Change and Energy Efficiency, maintains a database of entities expected to pay a carbon price. Landfills will have to pay a carbon price on new waste deposits from 1 July 2012 to encourage them to capture their methane emissions, which can then be used to produce heat or electricity. If a Landfill produces more than 25,000 tonnes of C02-equivalents a year they must report their emissions under the National Greenhouse and Energy Reporting (NGER) Scheme by 31 October 2013.
So if you operate a landfill how on earth do you calculate your emissions? Well it’s pretty tricky business and the National Greenhouse and Energy Reporting (Measurement) Determination 2008 provides methods and criteria for calculating greenhouse gas emissions and energy data under the National Greenhouse and Energy Reporting Act 2007 (NGER Act). Check out some of it here if you have trouble sleeping.
The government doesn’t expect you to know all that detail however and handily provides a calculator that you can use, which you can download on this page. It does the job but is pretty basic and doesn’t do things like show you the waste generated by each deposit in isolation of the totals. It also doesn’t give you anyway to visualise your data or change the parameters used in the calculation, which I’d be pretty interested in given the impending election in September.
The breakdown by deposit and visualisation is why Boral reached out to us for a better calculator last year to calculate emissions on the Boral Western Landfill, located west of Melbourne. So we made one for them. You can read about that here.
We only recently started to ask ourselves how other landfill operators were handling the same problem and whether they also wanted the greater capability of the Biarri Landfill Gas Emissions Calculator. So we did some research and reached out to some people we thought would know better than us about the industry. We were surprised to hear that the government tool was the only option.
So we looked into their tool further and found that they give users a handy guide, the “Solid Waste Disposal On Land User Guide V2.2”. Just don’t use it for calculating your emissions this year! As they say on page 6 “this estimate is not based on the NGER (Measurement) Determination for 2012/13. For 2012/13 reporting you will need to download an updated version of the Calculator when it is available”. And I’m sure it will be made available at some point but it isn’t available yet!
So we decided to make our tool more broadly available (yes, it is compliant with NGER (Measurement) Amendment Determination 2012/13 for the upcoming reporting period).
We’ve set up a site at http://landfill-emissions.biarri.com/ where you can download a trial of the tool and of course also buy it.
So now you know what happens to your rubbish and, if you’re a landfill operator, how to calculate your emissions this year. And by the way, it’s bin night!

Biarri Landfill Gas Emissions Calculator Screen Shots

Non-Legacy Quantity Generated

Annual Generation

Annual Non-Legacy Generation

Annual Total Generation

Forecast Landfill Qty (input)

 

The BAM (Biarri Applied Mathematics) 2012

/2 Comments/in , /by

The second Biarri Applied Mathematics conference, or BAM, was hosted by the University of Melbourne over two days, November 12 to 13. The conference was a big success, with around 80 people attending, including industry representatives, academics and students.

All the talks (given by Operations Research practioners from both Biarri and from industry, as well as academics) were informative and interesting and generated discussion and questions.

Biarri once again thanks those who attended as well as those behind the scenes who helped make the event a success.

Download all presentations

Biarri Optimisation - 09 Biarri Optimisation - 08 Biarri Optimisation - 13 Biarri Optimisation - 12 Biarri Optimisation - 10 Joe Forbes at BAM Conference - Biarri Applied Mathematics

Biarri provides Network Design Optimisation to NBN Co.

/0 Comments/in , /by

NBN Co today announced that they awarded an 8 year contract to Biarri to supply network design optimisation to support development of efficient, lower cost network construction plans.

Biarri is to provide optimisation technology to NBN Co for fibre network design optimisation. The optimisation engine quickly generates low-cost fibre network designs based on the requirements of the reference architecture. It can determine optimal fibre area boundaries, the position of fibre hubs, and the layout and route of distribution and local fibre.

See the NBN Co site for more detail.
Logic of the Fibre Optic Network Design Tool

Optimisation: Striking the Right Balance

/0 Comments/in , , /by

One of the guiding principles we use in commercial mathematics is to “Model Conservatively, but Optimise Aggressively”. This means that the problem domain should be modeled with sufficient “fat” in the data to ensure that the results are both legal and robust; but given this, we should then seek to apply the best (fastest and highest quality) solution approach that we can get our hands on.

Optimising aggressively can sometimes have it’s downfalls, though, if taken too literally. I’ve been doing a few experiments with numerical weightings of the objective function in a Vehicle Routing problem, where this issue is readily apparent. (Actually it is a Vehicle Routing problem with time windows, heterogeneous fleet, travel times with peak hours, both volume and weight capacities, and various other side constraints).

Our Vehicle Routing uses travel times (based on shortest paths through the street network) that are characterised by distance and duration. Durations can vary due to different road speeds on different types of streets (highways vs suburban roads for example). This leads to the question of how (on what basis) to optimise the vehicle routes – given that the optimisation has already to some extent minimised the number of vehicles and created well-clustered routes – what is the most desirable outcome for KPIs in terms of duration and distance?

In one experiment I’ve tried three different weightings for the duration (cost per hour) while keeping the cost per distance constant. I’ve run three values for this cost per hour – low, medium, and high weightings – on real-life delivery problems across two different Australian metropolitan regions.

Region 1
Total Duration Driving Duration Distance
Cost/hour
Low 74:47 24:38 708
Medium 72:45 23:55 712
High 72:58 23:42 768
Region 2
Total Duration Driving Duration Distance
Cost/hour
Low 113:54 46:44 1465
Medium 107:51 41:36 1479
High 108:51 43:49 1518

From these results, there is a (more-or-less) general correspondence between distance and the driver cost per hour as you would expect. However, if you push one weighting too far (ie. optimise too aggressively or naively), it will sometimes be to the detriment of all the KPIs as the optimisation will be pushing too strongly in one direction (perhaps it is outside the parameter space for which it was originally tuned, or perhaps it pushes the metaheuristic into search-space regions which are more difficult to escape from). This is most acutely seen in Region 2 when using the high cost per hour value. Conversely if you drop the cost per hour to a low value, the (very modest) reduction you get in distance is very badly paid for in terms of much longer durations. What is most likely happening in this case is that the routes are including much more waiting time (waiting at delivery points for the time windows to “open”), in order to avoid even a short trip (incurring distance) to a nearby delivery point that could be done instead of waiting.

The problem of striking the right balance is most acute with metaheuristics which can only really be tuned and investigated by being run many times across multiple data sets, in order to get a feel for how the solution “cost curve” looks in response to different input weightings. In our example, an in-between value for cost per hour seems to strike the best balance to produce the overall most desirable KPI outcome.

Successfully Implementing Commercial Mathematics

/0 Comments/in , , /by

We have grown Biarri based on successfully bringing the power of mathematics to bear on business. We try hard to make operations research easier for business to digest.  Over the last few years there are a few things we have learned that are worth pointing out.

1. Target businesses that need analytical support and know they need it. Many businesses now have lots of data but that they lack the analytical ability to utilise that data. The businesses we target understand that smart decisions are based on ‘results gleaned from algorithmic insight and executed with the confidence that comes from really doing the math’. ‘Analytics’ is now part of the business improvement conversation however you need to target businesses that have complex problems that are solvable and need solving. Additionally, we have always had better success when the problem has a clear owner who will benefit directly from solving the problem.

2. Differentiate your offering. ‘Optimisation’ and now ‘Analytics’ are overused terms. As applied mathematicians we can certainly bring some real science to the table. But this is not enough. What has emerged as very important is our ability to make the mathematics digestible. We have tried hard to deliver ‘Accessible Optimisation’. We believe optimisation is only powerful if it is:

  • Easy to apply to real world operations
  • Easy to understand (intuitive)
  • Easy to access (usable)
  • Affordable with minimum capital spend
  • Fast and reliable

3. Focus on implementation practicalities. You need to keep your eye on the basics of project management. Some of the key issues for us have been:

  • Work hard to keep the scope tight by focusing on the 20% of features that deliver 80% of the value.
  • Use simple frameworks that everyone can understand. All our custom models and tools use a simple linear workflow/logic around a smart engine.
  • Stay close to your customer and practice the art of no surprises.
  • Excel is useful for modelling. It is available on every desk top, flexible, familiar, easy to use and accepted by non-technical managers.
  • Develop and implement prototype models quickly and have a simple way of upgrading them when needed.  For example, we always keep our prototype engines separate to the front-end so we can easily port them to different solution frameworks.

The business of Biarri

/0 Comments/in , /by

At Biarri we build mathematical optimisation products and models and we have also been building up the business over the past two years from very humble beginnings. Below are a few more of the business lessons we have learnt growing a tech start up in Australia.

1. Get some rhythm – we have used the Rockefeller Habits checklist from Verne Harnish – it gives each day, week, month, quarter and year a target and keeps the team accountable for key actions. It also means we are always watching the cash burn. To quote Verne “cash is oxygen”. This is important as we were also told very early that costs have a way of taking care of themselves if not very closely watched – this is true.

2. Meet your competition – how else will you really know how to differentiate and where their weaknesses are?

3. Give people space to deliver – give good people the space to deliver and they almost always will.People don’t need rules or process – they need a challenges and support.We have been amazed at the great work our super smart university students produce on our projects. Our customers also love it.

4. Keep low cost – we have had many big corporate guys come to our offices and comment on the poor paint job, old carpet or our back alley address. They don’t seem to get it. You don’t need to be on level 24 to produce a great product and you can certainly sell it cheaper if you are not.

5. Stay close to customers – make the calls every day to stay close to people and opportunities arise. We find that you need to be out speaking to people, catching up for coffee and on the phone to grow a business like ours.

Tech Start Up Business Lessons

/0 Comments/in , , /by

Biarri commenced as a commercial maths start up almost two years ago. In this time we have learnt a lot.
We focus hard on deploying optimisation and quantitative analytics in accessible ways to deliver the power of mathematics quickly and cheaply. Our just launched workbench (www.biarriworkbench.com) is a great example of this – providing monthly low cost rental of powerful maths engines available over a browser.

While we have been building products and models we have also been building a business and have learnt a few things along the way. Below are a few of the business lessons we have learnt growing a tech start up in Australia.

  1. Be in the cloud – because we were delivering our optimisation workbench using the cloud, we sought out cloud services for our internal business needs. Our accounting software, CRM, email and timesheets are all rented from Software as a Service companies. We learnt a lot about what makes a good web app by using these services and we saved a lot of capital cost upfront. Specifically let me say that SAASU (www.saasu.com.au) is a really good accounting system for a small business – much easier to use than MYOB or quicken in my view.
  2. Always push back against one-sided contract terms from big corporates – we find almost always you will get at least what you ask for. In house lawyers and legal departments will always try it on, especially when they are dealing with a small business – push back hard there is always some flex
  3. Not all phone companies are the same – one large Australian telco sells conference calling enabled handsets while their network does not support conference (e.g. 3 way) calling. This is not disclosed up front- we found out when we tried our first conf call. Ask the question, be wary of penguins and remember Skype is your friend.

Hope these few thoughts help. There is more we are learning each day so will stick up some more thoughts soon.

The Launch of Biarri’s WorkBench

/0 Comments/in , , , /by

With the impending launch of Biarri’s workbench and our ongoing close relationship with Schweppes for the daily routing of soft drink deliveries (an application of perhaps the most well known operations research problem: the vehicle routing problem), I thought that the following excerpt from a journal article submitted to the Asia Pacific Journal of Operations Research would be a very timely blog post.

The journal article is entitled “Real-Life Vehicle Routing with Time Windows for Visual Attractiveness and Operational Robustness” and it describes the vehicle routing algorithm we have implemented for Schweppes.

The excerpt details a specific example encompassing two things we are very passionate about at Biarri. First “Commercial Mathematics” – that is making OR (well not strictly just OR) work in the real world. And second, the revolutionary capabilities that the advent of cloud computing has for the delivery of software.

“Vehicle routing problems manifest in a remarkably wide range of commercial and non-commercial enterprises. From: industrial waste collection to grocery delivery; underground mining crew replenishment to postal and courier collection and delivery; inbound manufacturing component transportation to finished car distribution; in-home primary health care delivery to pathology specimen clearances from surgeries for analysis; and from coal seam gas field equipment maintenance to beverage distribution, to name but a few.

Automated planning systems used by industry at present are predominantly client-server or desktop based applications. Such systems are often: expensive, requiring a large upfront capital investment; accompanied by a large software deployment project requiring initial and ongoing IT department cooperation; customisable to a particular organisations requirements, however commonly retain a large amount of exposed functionality due to the breadth of the existing client base; and require substantial user training as the workflow is usually not restricted in a linear fashion …. Each of these characteristics constitutes a barrier to adoption of automated planning systems, and for most small to medium enterprises these barriers prove insurmountable.

With the advent of cloud computing and software as a service (SaaS) these barriers are being removed. SaaS: embodies a different commercial model; has essentially no IT footprint; mandates (as vendors may never directly interact with potential clients) simple intuitive linear workflows; and involves almost no end user training beyond perhaps an optional demonstration video.

The emergence of this new avenue for the delivery of optimisation based planning systems heralds, a heretofore, unparalleled opportunity for operations research practitioners to engage with a wider potential consumer base than ever before. However, the nature of the delivery mechanism requires the algorithms developed: to be robust and flexible (within their domain of application they must be capable to dealing with a wide range of input data); to have very short run times (the user base is more likely to be under time pressure than ever before); to produce high quality solutions (noting the inherent trade off between run time and solution quality); to be wrapped in a simple linear workflow (meaning it is always obvious what the next step in the planning process is); but above all, be able to produce real-life, practically implementable solutions, without the need for user training and/or experience.

For pure delivery, or pure pick up vehicle routing applications, real-life, practically implementable solutions are often synonymous with geographically compact, non-overlapping routes with little or no intra-route cross over. There are numerous reasons why such solutions are preferred …. If a customer cannot be serviced at the preferred time (e.g. the vehicle cannot get access, the customer is closed, another delivery is taking place, the customer is too busy), because the route stays in the same geographical area, it is easy to return to the customer at a later time. During busy traffic periods drivers are loathe to exit and re-enter a motorway to service individual customers. Even though such customers may be enroute to the
bulk of the customers the route services, thus incurring a minimum of additional kilometres, they may nevertheless be far from the majority of the customers the route services. If there is severe traffic disruption, it is easier to use local alternate routes between customers in a route that is geographically compact to ensure that pick-ups or deliveries can still be made. Third party transport providers, which prefer routes to be as simple as possible, may exert some influence over the planning process. Finally … it is easier to maintain customer relationships by assigning drivers to routes that routinely service a similar geographical area. In summary, solutions which are more visually attractive are more robust, and thus more likely to actually deliver the full extent of the cost savings that should flow from the use of automated planning systems.

This paper describes an algorithm for the vehicle routing problem with time windows, …. The algorithm is: robust and flexible; fast; wrapped in a user interface utilising a simple linear workflow and so requires no user training or experience; and produces high quality, visually attractive and practically implementable solutions.”

Biari Workbench Technology Stack

/0 Comments/in , , /by

Over the course of developing our Workbench solution we’ve adopted a powerful set of interconnecting components. It’s worth mentioning what these are and how they fit together.

Almost all the components of the stack are free and/or open source. We want to be as platform independent as possible and not get too locked in to one technology paradigm. This means that as much as possible, parts should be as “hot swappable” as possible – which also helps encourage strong componentisation. Using components with mature and open/standardised interfaces is very necessary when you’re crossing language boundaries (most notably, Javascript-Python and Python-C++) and client/server boundaries; otherwise you risk re-inventing the wheel. Ideally each component we use should also still be in active development (in the IT world – with the odd highly venerable exception – if software is not growing and evolving, it’s usually either dying, already in it’s death throes, or extinct).

There’s an art to using the right tool for the job, and we’ve made mistakes. We over-used Mako (see Loki’s blog post) and also originally used a slightly inferior lib for the C++ xmlrpc back end; both these mis-steps were fairly easily rectified. Arguably, we probably still use too much C++ and not enough Python – the C++ line count dwarfs the Python line count by a considerable margin. One last interesting point is that, at the moment, we’re still eschewing use of an ORM (Object Relational Mapping layer – such as SQL Alchemy) – time will tell whether that is a good idea or not.

Client:

JavaScript
 – client-side browser language

jQuery
 – JavaScript library for event handling and more

Cloudmade
 – OSM map provider/server

 

Data Interchange:

JSON – JavaScript Object Notation

XML – eXtensible Markup Language

Mathematical Engines:

Mostly in C++ using STL

CppUnit
– C++ library for unit testing

OGR
 – map data library, part of GDAL – used to read map data

Libxmlrpc-c
 – C++ back end for XMLRPC – used by a running process to communicate with the front end via Python

 

Server:

Python
– language

CherryPy
 – Python-based web app framework

PostgreSQL
 – open source RDBMS

PsycoPg2
 – database adaptor for PostgreSQL/Python

XmlRPCLib
 – XML RPC (used to communicate with some of the engines)

Mako
 – Python template library

Repoze
 – Zope/WSGI Python middleware (for authentication)

 

 

Thoughts on Point Solutions

/0 Comments/in , , /by

Lately I have been thinking a bit about the advantages of small, tightly focussed web apps (so-called “point solutions”) that scratch a single little itch, versus larger, more powerful and general web apps that tend to deliver more of a total body rub. This question is of utmost importance to a company like Biarri that needs to place its development time and effort into the best channels.

The question was highlighted by a real-world problem a colleague posed recently: how to assign foursomes in rounds of Golf so that all of the players got to play with each other player at least once. It is not trivial to construct such a solution (if one even exists) by hand, if the constraints are “tight” enough (for example, 20 players and 8 rounds).

Small point solutions that solve a small but non-trivial problem like this might be fairly quick to develop and deploy on the web. But it doesn’t take much feature creep before you get a pile of extra “features” (particular requirements for some players, minimising the number of repeated pairings, right through to printing out score cards etc); before you know it (or more precisely, after months or years of hard coding) you’d have a full-blown Golf Tournament Scheduler. Such a web app might sell for much more, but would probably attract many less customers. And what happened to the poor casual golfer or golf tournament organiser on a shoestring budget who just wanted to solve his or her original golf player assignment problem?

In the spirit of acknowledging that the future is impossible to predict, I think Biarri must address more wide-ranging, lightweight “point solutions”, particularly at our fledgling stage. More mini-apps with a wider potential customer base will allow us to gauge which itches need the most scratching; more complex apps, as every seasoned developer knows, seem to always cause issues and problems – in short, sheer complexity – quite out of scale with the larger code line count; not to mention being harder to use and understand for users (more buttons!)

Those who have test-driven our Workbench solution will also know that, to some extent, we’re trying to have our cake and eat it to, by allowing these smaller “point” solutions to exist as workflows (standalone web apps) in their own right, whilst also being “nestable” – that is, able to be composited in a larger, more powerful workflow. Look out for Geocoding as a sub-workflow inside Travel Time Calculation, coming to the Workbench very soon. And who knows if the Biarri Golf Tournament Organiser will ever eventuate!