I realized the other day that I had not mentioned the Threads:-Add, Threads:-Map, Threads:-Mul and Threads:-Seq functions.  These are parallel implementations of the standard Maple functions, add, map, mul and seq.  They expect the sam

A few months ago, I needed to prepare for a customer on-site training session. As part of the request for topics to be covered during the training, my contact there wanted to talk about contact! Contact models are important for multi-body systems because it is about the interactions between objects.  An important example of a contact model is a tire component that interacts with the road. In this case, the training topic requested was a more generic question: “how to create contact models in MapleSim”.  There are, of course, lots of examples available within MapleSim that contain contact models already. Two particular examples came to mind: 1) the bouncing ball; and 2) the catapult. However, this being a training session, simply presenting the example models would not accomplish the purpose of the session. So I broadened my scope and turned my attention to the question: “how does one model contact in general?”

The MapleSim Tire Component Library has just been released. This product is an add-on to MapleSim. It provides industry standard tire force model components such as Fiala, Calspan, and Pacejka’s magic tire formula. In addition, linear tire models and user-defined tire models are available. Once installed, the tire components work like any other MapleSim components, so you can drag them into your diagram and join them to your existing vehicle model, change parameters, plot and analyze dynamic and kinematic quantities, attach CAD images to be used in the animations, etc.

On and off over the last few months I've been meaning to learn about computing a center manifold approximation and normal form of a dynamic system of three differential equations.

My main reading: Stephen Wiggins, Introduction to Applied Nonlinear Dynamical Systems and Chaos, Second Edition, Springer, 2003.

I want to apply the technique to a system I derived from an optimal control problem. As a first step, I decided to reproduce the steps for the following system, for which the solution has been published.

Below is the latest version of the code to draw iso-chrone lines and a salvo of arrows onto the phase diagram of a two-dimensional system of ordinary differential equations.

I have greatly benefited from inputs by Robert Israel (who wrote the first incarnation of the procedure), Joe Riel, and pagan. A big thankyou!

The procedure is sufficiently developed for my current purpose, so I don't plan to modify it much in the near future.

Tested on Maple 13/ Classic. The last plot combines the isochrones and the salvo.

what I learned today is that you cannot write 1e-i, where i is an unassigned variable (at least not like that):

I've created a Maple help page, saved in a small hdb file, that describes the hierarchy of Maple's numerical types.  Insert it into the path assigned to ?libname.  Access the help page with ?numer-hier. To make it compact, I took some liberties with the notation.  Here is what it looks like

I'm posting it here to keep a record for myself.

my second blog post, aka "the lost blog post", is here.

Still some way to go. The following still needs to be tweaked case by case. And it can be made more compact too. Are the arrows flying so much faster in the top triangular area or are the arrows not printing where I expected them to ...

This post is a quick book review of

The Art of Multiprocessor Programming
by Maurice Herlihy and Nir Shavit

funny that, how do I go from first blog post to third blog post!?!?!

that's because my second blog post appears as a comment to my first blog post.

you've just got to learn...

Since much of what I post couldn't possibly be of interest to anyone else, I thought I'd use the blog. If I remember its existence, I'll try to post here stuff to myself. After all it's less likely to be lost here than in the maze of my harddrive.

Undergraduate engineering and science consists of learning various rules and laws that govern the domains of interest. For me, it was Maxwell’s Equations for electromagnetics, the Navier-Stokes equation for acoustics, the Rayleigh criterion for imaging, the speed of light, et cetera ad nauseam. What is frequently missed or neglected in teaching and in practice is how these rules and limits are simply the boundaries of the game – endpoints on a spectrum of possibilities. That’s why a recent headline caught my attention: “Computers to Get Faster Only for 75 More Years". I find it hard to believe that humans a thousand years from now will be commemorating 2084 as “The Year Computers Stopped Getting Faster”. After reading the research paper from which this headline arose, I was reminded that innovative science doesn’t set limits, it uses them as tools. Since this is precisely what we do in Applications Engineering at Maplesoft, I thought it would be worth looking into a little further.

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.

Every year my extended family does a "secret santa" gift exchange. Each person draws another person at random and then gets a gift for them. At first, none of my siblings were married, and so the draw was completely random. Then, as people got married, we added the restriction that spouses should not draw each others names. This restriction meant that we moved from using slips of paper on a hat to using a simple computer program to choose names. Then people began to complain when they would get the same person two years in a row, so the program was modified to keep some history and avoid giving anyone a name in their recent history. This year, not everyone was participating, and so after removing names, and limiting the number of exclusions to four per person, I had data something like this: