Maplesoft Blogger Profile: Samir Khan

1 Introduction

Three tanks are connected with two pipes. Each tank is initially filled to a different level. A valve in each pipe opens, and the liquid levels gradually reach equilibrium. Here, we model the system in MapleSim (including the influence of flow inertia), and also derive and solve the analytical equations in Maple.

Liquid flowing in a pipeline has inertia.  If a valve at the end of the pipeline suddenly closes, a pressure surge hits the valve, and travels through the pipeline at the speed of sound. The damping effect of fluid friction gradually attenuates the pressure wave.

This phenomenon is called water hammer and can cause damage significant damage, sometimes even rupturing the pipeline.

The pressure wave often produces audible sound. If you’ve ever heard...

I recently stumbled upon a hypnotic video of 15 out-of-phase pendulums from a physics experiment at Harvard University.

The...

A prospective customer recently asked if we had a MapleSim model of a double pipe heat exchanger. Heat exchangers are a critical unit operation in the process industries, and accurate models are needed for process control studies.  I couldn't find an appropriate model so I decided to derive the dynamic equations, and implement them using MapleSim's custom component interface.  I'll outline my modeling strategy in this blog post.

I lived in the UK before making the barely-considered decision to move to Canada.  I still have savings denominated in pounds sterling (all dutifully declared on my Canadian tax return).  Accordingly, I keep a close watch on the GBP-CAD exchange rate so I have some sense of my net worth.

When I arrived in Canada in July 2008, one pound sterling bought $2, down from $2.30 two years before that.  Today, the pound has devalued further and is worth around...

I spend much of my time traveling for business. These trips often last a week, and we try to visit as many potential customers as possible, and in the most efficient order. This involves matching our hosts' calendars with our own, booking the most cost effective travel options, and coping with last-minute cancellations and changes. It isn’t easy!

This has become so much easier with the advent of shareable calendars and mapping services, like Google Maps. ...

Sometimes the obvious escapes me, and it’s only due to some chance observation that I realize the same fundamental principles are everywhere.

A short time ago, I created a simple hydraulic network in MapleSim, and after experimenting with some of the parameters, found it gave the same behaviour as an electric circuit I’d modeled earlier.

Around the time that Windows 98 was at its most popular, I used to dabble in programming Windows user interfaces with Visual C++ and the help of several thick MFC (Microsoft Foundation Class) manuals.  I wanted to create packaged (and admittedly simple) engineering applications. But for a chemical engineer with little background in Windows programming, combining math functionality with a user interface was time-consuming and cumbersome. (MFC can be arcane unless you’ve invested considerable time in learning the API.)

Later, I migrated to VB6.  Designing an interface was an order of magnitude easier, but I still had to roll many of my own math routines, or link to external libraries. While I may be interested in the mathematical mechanics of adaptive step sizing in Runge-Kutta algorithms at the intellectual level, it was secondary to my then goal.

If you were to stroll into the Application Engineering office at Maplesoft, you might be led to believe that we subsist on nothing but donuts, pizza, chocolate and coffee.  It’s even worse at this time of year when we have many more opportunities to over-consume. I try to have a balanced diet, but there are too many temptations scattered around the office (including candy at the office entrance – our receptionist, Walli, expects me at 3pm each day without fail). It doesn’t help that a virtually limitless supply of donuts are only a three minute drive away.

Resellers buy products from a manufacturer, and sell to consumers.  They are an important factor in many industries, including the one in which I work.  Maplesoft operates through a network of resellers throughout the world (apart from North America and a few other territories).  Some may suspect I’m somewhat biased in promoting the importance of resellers; I spent seven years working for Adept Scientific, Maplesoft’s partner in the UK.

The largest resellers are based in larger, better developed markets with a strong manufacturing and research base (like Cybernet and Scientific Computers in Japan and Germany).  Conversely, many smaller resellers, like Multi-On and Czech Software First in Mexico and the Czech Republic, operate in markets with significant growth potential.

Dual- and quad-core PCs are now ubiquitous.  While making your operating system a better multi-tasking environment, they’ve had a limited effect on the code that most technical professionals write.  This is largely because of the perceived difficulty of parallel programming.   The evolution , however, of high-level languages that support multi-threading throughout the 90s and beyond, removed the need to manage threads at the low level, allowing engineers to concentrate on what part of the algorithm could be run in parallel.  Given the ever-increasing complexity of systems that have to be simulated, multi-threaded programming can offer significant time savings for many the problems that can be easily parallelized (and for which time-savings of parallelization outweigh the overhead).

The first professional training course I gave involved a 275 mile late evening drive in a 1 litre European econobox from Letchworth in the UK to a dingy hotel in Alnwick.  I was pretty nervous –some of my delegates were engineers who had been using Mathcad for over ten years, and I was being paid to tell them what they didn’t know.  The following day, after drinking several litres of coffee, I drove another five miles to the training location, only to find that just one delegate had turned up.  Luckily he was just an intern who’d never used Mathcad before – and to him I was an expert.

The evolution of written language started in earnest in 3500 BC with Cuneiform, spurring a step-change in the volume of information that could be recorded and transmitted over large distances.

This evolved into wide spectrum of other methods of information transmission. The first transatlantic telegraph cables, for example, were laid in the mid-to-late nineteenth century by information pioneers – industrialists who saw the vast benefit in increasing the rate of information exchange by many orders of magnitude. This led to a Cambrian explosion in the sheer volume of information transmitted internationally, increasing trade and commerce to hitherto unseen levels.

A few mornings ago, I drove to the office, bleary-eyed and still waiting for my first liter of coffee to kick in.  I parked, exited my car, and started walking to the entrance.  Someone a few meters ahead of me held the door open, but let go while I was still about a meter away.  Judging the closing speed of the door, I thought I had enough time to sneak in.  However, during the latter stages of its closing sweep, it suddenly sped up, and slammed shut. Not yet being suitably caffeinated, I uttered a small curse, damning the door and all its close mechanical relatives, and reached for my key fob.

When I was a toddler and learning about the concept of numbers, I used to play a simple game with my parents.  They’d think of a number, and I’d try to guess it.  They would shout “hotter!” if I were getting closer to the number and “colder!” if I was getting further away.  I’m still fascinated by number games, but now it’s Sudoku, the Countdown numbers game… or balancing my bank account at the end of the month.

While visiting a cathedral in Germany, Bob Schipke, a retired Harvard mathematician was astounded to find a glyph in a 13^th century manuscript that looked remarkably like the Mandelbrot set.  This led to a remarkable voyage of discovery that was publicised in a

Great playwrights and poets are drummers – they craft the written word so that the rhythm and the cadence of their dialogue when spoken are a drumbeat, and combine with the meaning of the language to create emotion.  Shakespeare, for example, used syllables as his drumbeats (as did many other playwrights and poets).  Analyzing linguistic structure isn’t a common application for a math tool (and for a very good reason), but can Maple tell us more about Shakespeare’s favourite drumbeat?

I'm one of several technical writers at Maplesoft.  It's our job to craft the text in our brochures and user stories, and on our web site.  We all have differing styles, but we share a common goal; we want to write in a manner that’s technically compelling but simple to understand.

After recently exploring Maple’s string manipulation tools, I was surprised to find a command that measures the readability of a sample of English text.  It seems that as well as making you a better mathematician, Maple will poke and prod you into being a better writer.

I was recently forwarded a link to this Snopes article.

According to the urban legend described therein, text is still readable if all the letters in a word apart from the first and last are randomized. I quickly threw together a Maple worksheet, primarily using its flexible string manipulation tools.

We’re now at an inflection point in which symbolic technology will automate physical modeling and equation generation through tools like MapleSim. As a recent webinar hosted by Maplesoft and the Society of Automotive Engineers proved, engineers are fascinated by the application of the technology, and the technology itself.

• Voting patterns in Mexico and Florida.
• The size of files in your Maple 12 installation
• Stock trading volumes on the NYSE

What do all of these have in common? They, and other data sets drawn from the real world, often follow a non-intuitive pattern called Benford’s Law.

Over the last few years, I’ve been lucky enough to spend time in Taiwan.  In my first visit to Taipei, I was astounded by the sheer scale of the Taipei 101 skyscraper.  At over 500m tall it dwarfed everything else in the skyline.

Given the proximity of many active fault lines, tall buildings in Taipei have a degree of earthquake protection engineered into them with a tuned mass damper .

I was in Boston last week attending the ASME International Mechanical Engineering conference demonstrating MapleSim, our new tool for physical modeling.  I had the opportunity to speak to a large number of delegates, but I remember one conversation in particular; a professor who taught freshman students was bemoaning the fact that he found it harder and harder to impress students with his relatively simple animations of physics phenomena.  A simple animated pendulum no longer captivated students who were already immersed in the interactive physics-enabled environments of video games.  He had to escalate the intricacy of his demonstrations, but generating them was starting to consume too much of his time.

Twenty years after I first plotted the Mandelbrot set on a ZX Spectrum with 48K of RAM and a 3.5MHz processor, I’m still amazed by the sheer complexity and beauty contained therein.  I now have access to far more computing horsepower and can create ever more vivid visualizations.  It’s surprising what you can do with some creativity and a modicum of patience.

Like most students studying engineering in the 90s, spreadsheets were the de facto calculation tool.  I used them for everything from food budgeting to pump and piping sizing calculations. 

Computing power has since exploded, and engineers have far better choices.  But engineers still continue using spreadsheets. 

Why?

There’s really only one reason – ubiquity and familiarity.  A spreadsheet is installed on nearly all desktop computers, but even though most engineers are aware of at least some of their design deficiencies they keep on using them.

That’s a mantra I need to have drummed into me, and perhaps tattooed on the inside of my car so I’m reminded every morning.  But I keep on making the same mistakes. 

 I seem to think that if I’ve “optimized” my portfolio with a few flashy calculations that I’ve done my due diligence, and the next stop is financial independence.  It’s the black box syndrome – trusting the output of a computer program without truly understanding the real issues.  Most portfolio analyses, for example, hinge on historical data, which of course doesn’t predict the sub-prime blow-up in the US or whether Brazilian coffee growers are on strike.  They’re all backward looking.