# Hamiltonian Dynamics in Haskell

by Justin Le ♦

As promised in my *hamilton* introduction post (published almost exactly one year ago!), I’m going to go over implementing of the *hamilton* library using

*DataKinds*(with*TypeLits*) to enforce sizes of vectors and matrices and help guide us write our code- Statically-sized linear algebra with
*hmatrix* - Automatic differentiation with
*ad* - Statically-sized vectors with
*vector-sized*

This post will be a bit heavy in some mathematics and Haskell concepts. The expected audience is intermediate Haskell programmers. Note that this is *not* a post on dependent types, because dependent types (types that depend on runtime values) are not explicitly used.

The mathematics and physics are “extra” flavor text and could potentially be skipped, but you’ll get the most out of this article if you have basic familiarity with:

- Basic concepts of multivariable calculus (like partial and total derivatives).
- Concepts of linear algebra (like dot products, matrix multiplication, and matrix inverses)

No physics knowledge is assumed, but knowing a little bit of first semester physics would help you gain a bit more of an appreciation for the end result!

The hamilton library introduction should be considered a “soft prerequisite” for this post, as it presents motivations, visual demonstrations, and general overviews of the methods presented here!

## The Goal

At the end of this, we should be able to have Haskell *automatically generate* **equations of motions** for any arbitrary system described in arbitrary coordinate systems, and simulate that system.

Normally, we’d describe a system using particles’ x and y coordinates, but our goal is to be able to describe our particles’ positions using any coordinate system we want (polar, distance-along-a-curved-rail, pendulum-angles, etc.) and have Haskell automatically generate equations of motions and time progressions of those coordinates.

Read my hamilton library introduction for more information and examples!

## Hamiltonian Mechanics

As mentioned in the previous post, Hamiltonian mechanics is a re-imagining of dynamics and mechanics (think “the world post-”) that not only opened up new doors to solving problems in classical, but also ended up being the right angle of viewing the world to unlock statistical mechanics and thermodynamics, and later even quantum mechanics.

Hamiltonian mechanics lets you parameterize your system’s “position” in arbitrary ways (like the angle of rotation, for pendulum problems) and then posits that the full state of the system exists in something called *phase space*, and that the system’s dynamics is its motion through phase space that is dictated by the geometry of the *Hamiltonian* of that phase space.

The system’s *Hamiltonian* is a function from a point in phase space (where is the number of coordinates parameterizing your system) to a scalar in . For a time-independent system, the picture of the dynamics is pretty simple: the system moves along the *contour lines* of the *Hamiltonian* – the lines of equal “height”.

In the example above, if we imagine that phase space is the 2D location, then the *Hamiltonian* is the mountain. And for a system dropped anywhere on the mountain, its motion would be along the contour lines. For example, if a system started somewhere along the 10 contour line, it would begin to oscillate the entire phase space along the 10 contour line.^{1}

*Every* smooth function on phase space can be used as a Hamiltonian to describe the physics of some system. So, given any “mountain range” on phase space, any “elevation map” or real-valued function on phase space, you can treat it as a description of the dynamics of some physical system.

The *trick*, then, to using Hamiltonian dynamics to model your system, is:

Finding the phase space to describe your system. This can be done based on any continuous parameterization of your system (“generalized coordinates”), like angles of pendulums and so on.

Finding the Hamiltonian on that phase space to describe your system.

And then Hamilton’s dynamics will give you the rest! All you do is “follow the contour lines” on that Hamiltonian!

### Phase Space

Hamiltonian dynamics are about systems moving around in phase space. It seems that phase space is the “room where it happens”, so to speak, so let’s dig deeper into what it is. *Phase space* is a -dimensional space parameterized by:

- All of the current values of the parameters (“generalized coordinates”)
- All of the current “generalized momenta” of those parameters

So if you were parameterizing your pendulum system by, say, the angle of the pendulum, then a point in phase space would be the current angle of the pendulum along with the current “generalized momentum” associated with the angle of the pendulum. What exactly *is* generalized momentum? We’ll go over calculating it eventually, but what does it represent…*physically*?

The deeper answer involves the underlying Lie algebra of the Lie group associated with the generalized coordinates, but going into that would make this a completely different post. What I *can* say is that the generalized momenta associated with (“conjugate to”) certain sets of familiar coordinates yield things that we typically call “momenta”:

The momentum conjugate to normal Cartesian coordinates is just our normal run-of-the-mill

*linear momentum*(in the ) from first semester physics.The momentum conjugate to the angle in polar coordinates is

*angular momentum*() from first semester physics.The momentum conjugate to the radial coordinate in polar coordinates is also just boring old linear momentum , which makes sense because purely radial motion is just linear motion.

So, it’s our normal momentum (for linear and polar coordinates) *generalized* to arbitrary coordinates.

### Hamiltonian Dynamics

I’ve explained Hamiltonian dynamics for time-independent Hamiltonians as “follow the contour lines”. If you remember your basic multi-variable calculus course, you’ll know that the line of “steepest ascent” is the gradient. If we call the Hamiltonian (where is the vector of positions and is the vector of momenta), then the direction of steepest ascent is

But we want to move along the *contour lines*…and these are the lines *perpendicular* to the direction of steepest descent. The vector perpendicular to is ,^{2} so we just derived the actual Hamiltonian equations of motion: just move in the direction perpendicular to the steepest ascent! That is, to have things move on contour lines, and *should* be:

This is a conclusion with one generalized coordinate , but we can generalize this to systems with multiple coordinates as well, as long as this holds for *every* and the momentum conjugate to it (). (For the rest of this post, refers to the vector of coordinates, refers to a single specific coordinate, and refers to the momentum conjugate to that coordinate).

Essentially, these give you “updating functions” for and – given , you have a way to “update” the particle’s position in phase space. Just take the partial derivatives of at every step in time! To update , nudge it by . To update , nudge it by !

This picture is appealing to me in a visceral way because it sort of seems like the system is “surfing” along the Hamiltonian’s contour lines. It’s being “pushed” *faster* when the Hamiltonian is steeper, and slower when it’s more shallow. I can apply all my intuition as a surfer^{3} to Hamiltonian mechanics!

## Hamiltonian Dynamics and Physical Systems

Earlier I mentioned that the two steps for applying Hamiltonian mechanics to your system was figuring out your system’s conjugate momenta and the appropriate Hamiltonian. To explain this, I’m going to make a couple of simplifying assumptions that make the job easier for the purposes of this article:

- Your coordinates and potential energy are time-independent.
- Your potential energy function only depends on
*positions*, and not*velocities*. (So nothing like friction or wind resistance or magnetic field vector potentials)

With these assumptions, I’m going to skip over discussing the Lagrangian of the system, which is the traditional way to do this. You can think of this section as me presenting derived conclusions and skipping the derivations.

### Conjugate Momenta

For systems with velocity-independent potential energies, it can be shown that the momentum conjugate to coordinate is

Where is the kinetic energy of the system, which is a function on the coordinates and their rates of change, . For example, for normal Cartesian coordinates in one dimension, . So the momentum conjugate to is:

Just linear momentum, like I claimed before.

Let’s generalize this to arbitrary coordinates. In general, for *Cartesian* coordinates, the kinetic energy will always be

Where is the inertia associated with each coordinate…for example, if describes the location of an object of mass , then .

To give us nice notation and make things more convenient, we’ll write this as a quadratic form over an inertia matrix:

Where is the diagonal matrix whose entries are the masses of each coordinate, and is the column vector of all of the (Cartesian) coordinates, .

Now! How to generalize this to arbitrary coordinates? Well, if we have generalized coordinates mapping to -dimensional Cartesian coordinates, we can specify them as , where , taking the vector of generalized coordinates and returning a vector for the position in Cartesian space. For example, for polar coordinates, , because, for polar coordinates, and .

So we can get from with , but how can we get , the vector of rate of changes? Well, if , then the is the total derivative of with respect to time:

Or, in short:

But, hey, this looks a lot like a matrix-vector multiplication! If we make , an matrix of partial derivatives of () at a given point (typically called the Jacobian matrix of f, then we have a nice expression for :

And we can plug it in (remembering that ) to our kinetic energy equation to get:

And for the final step, we differentiate with respect to the s (which is just the gradient ) to get , the vector of conjugate momenta:

Now, we’re going to be using a lot, so let’s give it a name, . represents some sort of coordinate-aware inertia term for our system. If the masses are all positive and is full-rank^{4}, then is a symmetric, positive-definite, invertible matrix (by construction). It’s important to also remember that it’s an explicit function of , because is a matrix of partial derivatives at a given . We now have a simple expression for the vector of conjugate momenta (), and also for kinetic energy ().

It’s going to be important for us to also be able to go backwards (to get from ). Luckily, because we wrote the whole thing as a matrix operation, going backwards is easy – just take the matrix inverse, which we know exists!

The power of linear algebra!

### Hamiltonians of Physical Systems

Ok, that’s step one. How about step two – finding the Hamiltonian for your system?

The *real* Hamiltonian is actually the Poisson bracket of the system’s Lagrangian, but I did some of the work for you for the case of time-independent coordinates where the potential energy depends *only* on positions (so, no friction, wind resistance, time, etc.). In such a case, the Hamiltonian of a system is precisely the system’s total mechanical energy, or its kinetic energy plus the potential energy:

Which makes a lot of intuitive sense, because you might recall that total mechanical energy is always conserved for certain types of systems. Incidentally, Hamiltonian dynamics makes sure that the value of the system’s Hamiltonian stays the same (because it moves along contour lines). So, the system’s Hamiltonian always stays the same, and so its total mechanical energy stays the same, as well! Energy is conserved because the Hamiltonian stays the same!

Anyway, we want to build our system’s Hamiltonian from properties of the coordinate system, so plugging in our expression for , we get .

Oh, but oops, the Hamiltonian has to be a function of , not of . Let’s remember that and find the final form of our Hamiltonian (after a bit of simplification, remembering that the inverse of a symmetric matrix is also symmetric):

### Hamiltonian Equations

We got our Hamiltonian! Now just to find our updating functions (the partial derivatives of the Hamiltonian), and we’re done with the math.

Because we are assuming the case (with loss of generality) doesn’t depend on , the partial derivatives of with respect to is:

We already can calculate , so this wound up being easy peasy. But finding the partial derivatives with respect to is a little trickier. The gradient is a linear operator, so we can break that down to just finding the gradient of the term . Because is an independent input to , we can just look at the gradient of . We can simplify that even more by realizing that for any invertible matrix , , so now we just need to find the partial derivatives of , or . is a constant term, so, using the good ol’ product rule over and , we see that, after some simplification:

(an matrix, like ) represents the *second derivatives* of – the derivative (with respect to ) of the derivatives.

The collection of “second-order derivatives of ” is known as the Hessian Tensor (a vector-valued generalization of the Hessian matrix), which we will denote as .^{5} We can write this in a nicer way by abusing matrix multiplication notation to get

if we use as an tensor, whose components are the each the matrices corresponding to

And with that, we have our final expression for :

Or, to use our abuse of notation:

And, finally, we have everything we need – we can now construct our equations of motion! To progress through phase space ():

That’s it. We’re done. Have a nice day, thanks for reading!

## The Haskell

Just kidding, now it’s time for the fun stuff :)

Our final goal is to be able to simulate a *system of discrete particles* through *arbitrary generalized coordinates*.

To simplify the math, we always assume that, whatever generalized coordinates you are using (), your system “actually” exists in some real flat Cartesian coordinate system (). This allows us to take advantage of all of that math we derived in the previous section.

So, in order to fully describe the system, we need:

- Each of their masses (or inertias) in their underlying Cartesian coordinates, which we’ll call .
- A function to convert the generalized coordinates () to Cartesian coordinates ()
- The potential energy function in the generalized coordinates ()

From these alone, we can derive the equations of motion for the particles in phase space as a system of first-order ODEs using the process described above. Then, given an initial phase space position, we can do numeric integration to simulate our system’s motion through phase space. To “surf the Hamiltonian waves in phase space”, so to speak.

But, to be explicit, we also are going to need some derivatives for these functions/vectors, too. If you’ve been following along, the full enumeration of functions and vectors we need is:

But, as we’ll see, with libraries like *ad* in Haskell, we can really just ask the user for , , and – all of the derivatives can be computed automatically.

### Our Data Structures

We can couple together all of these functions in a data type that fully describes the physics of our systems (the “shape” of the Hamiltonian):

```
-- source: https://github.com/mstksg/inCode/tree/master/code-samples/hamilton1/Hamilton.hs#L25-L32
data System m n = System
{ sysInertia :: R m -- ^ 'm' vector
, sysCoords :: R n -> R m -- ^ f
, sysJacobian :: R n -> L m n -- ^ J_f
, sysHessian :: R n -> V.Vector n (L m n) -- ^ H_f
, sysPotential :: R n -> Double -- ^ U
, sysPotentialGrad :: R n -> R n -- ^ grad U
}
```

`R n`

and `L m n`

are from the *hmatrix* library; an `R n`

represents an n-vector (For example, an `R 4`

is a 4-vector), and an `L m n`

represents an `m x n`

matrix (For example, an `L 5 3`

is a 5x3 matrix).

A `System m n`

will describe a system parameterized by `n`

generalized coordinates, taking place in an underlying `m`

-dimensional Cartesian space.

It’ll also be convenient to have a data type to describe the state of our system in terms of its generalized positions () and generalized velocities (the rates of changes of these positions, ), which is sometimes called “configuration space”:

```
-- source: https://github.com/mstksg/inCode/tree/master/code-samples/hamilton1/Hamilton.hs#L35-L39
data Config n = Config
{ confPositions :: R n
, confVelocities :: R n
}
deriving Show
```

And, more importantly, remember that Hamiltonian dynamics is all about surfing around on that phase space (generalized positions and their conjugate momenta, ). So let’s make a type to describe the state of our system in phase space:

```
-- source: https://github.com/mstksg/inCode/tree/master/code-samples/hamilton1/Hamilton.hs#L42-L46
data Phase n = Phase
{ phasePositions :: R n
, phaseMomenta :: R n
}
deriving Show
```

### Getting comfortable with our data types

First of all, assuming we can construct a `System`

in a sound way, let’s imagine some useful functions.

We can write a function `underlyingPosition`

, which allows you to give a position in generalized coordinates, and returns the position in the “underlying coordinate system”:

```
-- source: https://github.com/mstksg/inCode/tree/master/code-samples/hamilton1/Hamilton.hs#L51-L55
underlyingPosition
:: System m n
-> R n
-> R m
underlyingPosition = sysCoords
```

Note that the types in our function helps us know exactly what the function is doing — and also helps us implement it correctly. If we have a `System`

in `n`

dimensions, over an underlying `m`

-dimensional Cartesian space, then we would need to convert an `R n`

(an n-dimensional vector of all of the positions) into an `R m`

(a vector in the underlying Cartesian space).

Simple enough, but let’s maybe try to calculate something more complicated: the *momenta* of a system, given its positions and velocities (configuration).

We remember that we have a nice formula for that, up above:

We can translate that directly into Haskell code:

```
-- source: https://github.com/mstksg/inCode/tree/master/code-samples/hamilton1/Hamilton.hs#L59-L67
momenta
:: (KnownNat n, KnownNat m)
=> System m n
-> Config n
-> R n
momenta s (Config q v) = tr j #> mHat #> j #> v
where
j = sysJacobian s q
mHat = diag (sysInertia s)
```

Note that, because our vectors have their size indexed in their type, this is pretty simple to write and ensure that the shapes “line up”. In fact, GHC can even help you write this function by telling you what values can go in what locations. Being able to get rid of a large class of bugs and clean up your implementation space is nice, too!

(Note that *hmatrix* requires a `KnownNat`

constraint on the size parameters of our vectors for some functions, so we add this as a constraint on our end.)

With this, we can write a function to convert any state in configuration space to its coordinates in phase space:

```
-- source: https://github.com/mstksg/inCode/tree/master/code-samples/hamilton1/Hamilton.hs#L70-L75
toPhase
:: (KnownNat n, KnownNat m)
=> System m n
-> Config n
-> Phase n
toPhase s c = Phase (confPositions c) (momenta s c)
```

This function is important, because “configuration space” is how we actually directly observe our system – in terms of positions and velocities, and not in terms of positions and momenta (and sometimes conjugate momenta might not even have meaningful physical interpretations). So, having `toPhase`

lets us “initialize” our system in terms of direct observables, and then convert it to its phase space representation, which is something that Hamiltonian mechanics can work with.

### Automatic Differentiation

Now, creating a `System`

“from scratch” is not much fun, because you would have to manually differentiate your coordinate systems and potentials to generate your Jacobians and gradients.

Here’s where the magic comes in – we can have Haskell generate our Jacobians and gradients *automatically*, using the amazing ad library! We can just use the appropriately named `grad`

, `jacobian`

, and `hessianF`

functions.

#### Quick Intro to AD

At the simplest level, if we have a function from some number to some other number, we can use `diff`

to get its derivative:

If we have a function a function from a sized vector to a scalar, we can use `grad`

to get its gradient:

```
-- import qualified Data.Vector.Sized as V
myFunc :: RealFloat a => V.Vector n a -> a
grad myFunc :: RealFloat a => V.Vector n a -> V.Vector n a
```

Where each of the components in the resulting vector corresponds to the rate of change of the output according to variations in that component.

We’re using **statically sized vector** type from the vector-sized package (in the Data.Vector.Sized module), where `V.Vector n a`

is a `n`

-vector of `a`

s – for example, a `V.Vector 3 Double`

is a vector of 3 `Double`

s.

We have to use `Vector`

(instead of `R`

, from *hmatrix*) because automatic differentiation for gradients requires *some Functor* to work. An `R 5`

is essentially a `V.Vector 5 Double`

, except the latter can contain other, non-Double things – and therefore can be used by *ad* to do its magic.

If we have a function from a sized vector to a (differently) sized vector, we can use the `jacobian`

function to get its jacobian!

```
myFunc :: RealFloat a => V.Vector n a -> V.Vector m a
jacobian myFunc :: RealFloat a => V.Vector n a -> V.Vector m (V.Vector n a)
```

Again note the usage of sized vector types, and the fact that our matrix is represented by a `m`

-vector of `n`

-vectors.

Finally, we can get our Hessian Tensor by using `hessianF`

:^{6}

```
myFunc
:: RealFloat a => V.Vector n a -> V.Vector m a
hessianF myFunc
:: RealFloat a => V.Vector n a -> V.Vector m (V.Vector n (V.Vector n a))
```

#### Conversion between vector-sized and hmatrix

So some ugly things – we need to write some functions to convert between *vector-sized* sized vectors and *hmatrix* vectors and matrices. These are fundamentally unsafe to write (but safe to use, after written properly):

```
-- import qualified Data.Vector.Generic.Sized as VG
-- source: https://github.com/mstksg/inCode/tree/master/code-samples/hamilton1/Hamilton.hs#L78-L87
vec2r :: KnownNat n => V.Vector n Double -> R n
vec2r = fromJust . create . VG.fromSized . VG.convert
r2vec :: KnownNat n => R n -> V.Vector n Double
r2vec = VG.convert . fromJust . VG.toSized . extract
vec2l :: (KnownNat m, KnownNat n) => V.Vector m (V.Vector n Double) -> L m n
vec2l = fromJust . (\rs -> withRows rs exactDims) . toList . fmap vec2r
```

These are necessary because *ad* requires our vectors to be *Functors*, but `R`

and `L`

from *hmatrix* are not your typical Hask Functors. One nice thing is that because they both use *TypeLits* to get their sized parameters, we can get type-safe conversions that preserve their size information!

Also, even though *ad* gives our Hessian as an tensor, we really want it as a n-vector of matrices – that’s how we interpreted it in our original math. So we just need to write an function to convert what *ad* gives us to the form we expect. It’s mostly just fiddling around with the internals of *hmatrix* in a rather inelegant way. (Again, unsafe to write, but safe to use once you do)

```
-- source: https://github.com/mstksg/inCode/tree/master/code-samples/hamilton1/Hamilton.hs#L90-L93
rehessian :: (KnownNat m, KnownNat n) => V.Vector m (L n n) -> V.Vector n (L m n)
rehessian = fmap (fromJust . (\rs -> withRows rs exactDims) . toList)
. sequenceA
. fmap (fromJust . V.fromList . toRows)
```

#### Using AD to Auto-Derive Systems

Now to make a `System`

using just the mass vector, the coordinate conversion function, and the potential energy function:

```
-- source: https://github.com/mstksg/inCode/tree/master/code-samples/hamilton1/Hamilton.hs#L97-L113
mkSystem
:: (KnownNat m, KnownNat n)
=> R m
-> (forall a. RealFloat a => V.Vector n a -> V.Vector m a)
-> (forall a. RealFloat a => V.Vector n a -> a)
-> System m n
mkSystem m f u = System
-- < convert from | actual thing | convert to >
{ sysInertia = m
, sysCoords = vec2r . f . r2vec
, sysJacobian = vec2l . jacobian f . r2vec
, sysHessian = rehessian
. fmap vec2l . hessianF f . r2vec
, sysPotential = u . r2vec
, sysPotentialGrad = vec2r . grad u . r2vec
-- < convert from | actual thing | convert to >
}
```

Now, I hesitate to call this “trivial”…but, I think it really is a straightforward direct translation of the definitions, minus some boilerplate conversions back and forth using `r2vec`

, `vec2r`

, and `vec2l`

!

- The vector of masses is just
`m`

- The coordinate function is just
`f`

- The Jacobian of the coordinate function is just
`jacobian f`

- The Hessian Tensor of the coordinate function is just
`hessianF f`

- The potential energy function is just
`u`

- The gradient of the potential energy function is just
`grad u`

The *ad* library automatically generated all of these for us and created a perfectly well-formed `System`

with all of its gradients and Jacobians and Hessians by giving only the coordinate function and the potential energy function, and in such a clean and concise way!

### Equations of Motion

At this point, we’re ready to write our final equations of motion, which we found to be given by:

These equations aren’t particularly beautiful, but it’s straightforward to translate them into Haskell (using ):

```
-- source: https://github.com/mstksg/inCode/tree/master/code-samples/hamilton1/Hamilton.hs#L116-L133
hamilEqns
:: (KnownNat n, KnownNat m)
=> System m n
-> Phase n
-> (R n, R n) -- dq/dt and dp/dt
hamilEqns s (Phase q p) = (dqdt, dpdt)
where
j = sysJacobian s q
trj = tr j
mHat = diag (sysInertia s)
kHat = trj <> mHat <> j
kHatInv = inv kHat
dqdt = kHatInv #> p
dpdt = vec2r bigUglyThing - sysPotentialGrad s q
where
bigUglyThing =
fmap (\j2 -> -p <.> kHatInv #> trj #> mHat #> j2 #> kHatInv #> p)
(sysHessian s q)
```

Of course, there is no way to get around the big ugly math term in , but at least it is a direct reading of the math!

*But!!* I’d much rather write this scary Haskell than that scary math, because *ghc typechecks our math*! When writing out those equations, we really had no idea if we were writing it correctly, and if the matrix and vector and tensor dimensions line up. If it even *made sense* to multiply and transpose the quantities we had.

However, when writing `hamilEqns`

, we let GHC *hold our hand for us*. If any of our math is wrong, GHC will verify it for us! If any dimensions don’t match up, or any transpositions don’t make sense, we’ll know immediately. And if we’re ever lost, we can leave a *typed hole* – then GHC will tell you all of the values in scope that can *fit* in that hole! Even if you don’t completely understand the math, this helps you implement it in a somewhat confident way.

It’s admittedly difficult to convey how helpful these sized vector types are without working through trying to implement them yourself, so feel free to give it a try when you get the chance! :D

### Numerical Integration

The result of `hamilEqns`

gives the rate of change of the components of our `Phase n`

. The rest of the processes then is just to “step” `Phase n`

. Gradually update it, following these rate of changes!

This process is known as numerical integration. The “best” way to do it is quite a big field, so for this article we’re going to be using the extremely extremely simple Euler method to progress our system through time.

Disclaimer – The Euler method is typically a **very very bad** choice for numerical integration (even though, as popularized in the movie *Hidden Figures*, it was good enough to send humans to space?). We are just choosing it for this article because it’s very simple, conceptually!

The basic idea is that you pick a time-step, , and update each coordinate as:

Which makes sense visually if we imagine as the “slope” of – it just means to follow the slope another steps. If the slope stays constant, this method is perfectly accurate. The inaccuracy, of course, happens when the slope changes drastically within that (and also from the fact that small errors cause errors in the new calculations of , and so compound over time)

You can understand this symbolically, as well, by remembering that the derivative can be approximated by for small , and so we can do a little bit of symbolic manipulation to get .

We can directly translate this into Haskell: (using `konst :: KnownNat n => Double -> R n`

, making a constant vector, and `*`

, the component-wise product of two vectors)

```
-- source: https://github.com/mstksg/inCode/tree/master/code-samples/hamilton1/Hamilton.hs#L136-L144
stepEuler
:: (KnownNat n, KnownNat m)
=> System m n -- ^ the system
-> Double -- ^ dt
-> Phase n -- ^ q(t) and p(t)
-> Phase n -- ^ q(t + dt) and p(t + dt)
stepEuler s dt ph@(Phase q p) = Phase (q + konst dt * dq) (p + konst dt * dp)
where
(dq, dp) = hamilEqns s ph
```

And repeatedly evolve this system as a lazy list:

```
-- source: https://github.com/mstksg/inCode/tree/master/code-samples/hamilton1/Hamilton.hs#L147-L155
runSystem
:: (KnownNat n, KnownNat m)
=> System m n -- ^ the system
-> Double -- ^ dt
-> Phase n -- ^ initial phase
-> [Phase n] -- ^ progression of the system using Euler integration
runSystem s dt = go
where
go p0 = p0 : go (stepEuler s dt p0)
```

## Running with it

And…that’s it! Granted, in real life, we would be using a less naive integration method, but this is essentially the entire process!

Let’s generate the boring system, a 5kg particle in 2D Cartesian Coordinates under gravity –

```
-- source: https://github.com/mstksg/inCode/tree/master/code-samples/hamilton1/Hamilton.hs#L158-L164
simpleSystem :: System 2 2
simpleSystem = mkSystem (vec2 5 5) id pot
where
-- potential energy of a gravity field
-- U(x,y) = 9.8 * y
pot :: RealFloat a => V.Vector 2 a -> a
pot xy = 9.8 * (xy `V.index` 1)
```

If we initialize the particle at position and velocity (that is, and ), we should see something that travels at a constant velocity in x and something that starts moving “upwards” (in positive y) and eventually reaches a peak and moves downwards.

We can make our initial configuration:

```
-- source: https://github.com/mstksg/inCode/tree/master/code-samples/hamilton1/Hamilton.hs#L168-L172
simpleConfig0 :: Config 2
simpleConfig0 = Config
{ confPositions = vec2 0 0
, confVelocities = vec2 1 3
}
```

And then…let it run!

```
-- source: https://github.com/mstksg/inCode/tree/master/code-samples/hamilton1/Hamilton.hs#L174-L178
simpleMain :: IO ()
simpleMain =
mapM_ (disp 2 . phasePositions) -- position with 2 digits of precision
. take 25 -- 25 steps
$ runSystem simpleSystem 0.1 (toPhase simpleSystem simpleConfig0)
```

We get:

```
ghci> :l Hamilton.hs
ghci> simpleMain
0 0
0.10 0.30
0.20 0.58
0.30 0.84
0.40 1.08
0.50 1.30
0.60 1.51
0.70 1.69
0.80 1.85
0.90 1.99
1.00 2.12
1.10 2.22
1.20 2.31
1.30 2.37
1.40 2.42
1.50 2.44
1.60 2.45
1.70 2.43
1.80 2.40
1.90 2.35
2.00 2.28
2.10 2.18
2.20 2.07
2.30 1.94
2.40 1.79
```

Exactly what we’d expect! The `x`

positions increase steadily, and the `y`

positions increase, slow down, and start decreasing.

We can try a slightly more complicated example that validates (and justifies) all of the work we’ve done – let’s simulate a simple pendulum. The state of a pendulum is characterized by one coordinate , which refers to the angular (clockwise) from the equilibrium “hanging straight down” position. corresponds to 6 o’ clock, corresponds to 9 o’ clock, corresponds to 3 o’ clock, etc. For a pendulum of length , we can translate that as .

Let’s set up that system! We’ll put it under normal gravity potential, again (). Our initial position will be at equilibrium, and our initial angular velocity will be 0.1 radians/sec (clockwise), as we try to induce harmonic motion:

```
-- source: https://github.com/mstksg/inCode/tree/master/code-samples/hamilton1/Hamilton.hs#L181-L210
-- | A pendulum system, parameterized by its angle clockwise from
-- equilibrium
pendulum :: System 2 1
pendulum = mkSystem (vec2 5 5) coords pot -- 5kg particle
where
-- <x,y> = <-0.5 sin(theta), -0.5 cos(theta)>
-- pendulum of length 0.25
coords :: RealFloat a => V.Vector 1 a -> V.Vector 2 a
coords (V.head->theta) = fromJust
. V.fromList
$ [- 0.25 * sin theta, - 0.25 * cos theta]
-- potential energy of gravity field
-- U(x,y) = 9.8 * y
pot :: RealFloat a => V.Vector 1 a -> a
pot q = 9.8 * (coords q `V.index` 1)
pendulumConfig0 :: Config 1
pendulumConfig0 = Config
{ confPositions = 0
, confVelocities = 0.1
}
pendulumMain :: IO ()
pendulumMain =
mapM_ (disp 3 . phasePositions) -- position with 2 digits of precision
. take 25 -- 25 steps
$ runSystem pendulum 0.1 (toPhase pendulum pendulumConfig0)
```

This pendulum should wobble back and forth, ever so slightly, around equilibrium.

```
ghci> :l Hamilton.hs
ghci> pendulumMain
0
0.010
0.020
0.029
0.037
0.042
0.045
0.044
0.040
0.032
0.021
0.007
-0.008
-0.023
-0.038
-0.051
-0.061
-0.068
-0.069
-0.065
-0.056
-0.041
-0.022
-0.000
0.023
```

We see our coordinate increasing, then turning around and decreasing, swinging the other way past equilibrium, and then turning around and heading back!^{7}

We *automatically generated equations of motion for a pendulum*. Sweet!

## Wrap-Up

We traveled through the world of physics, math, Haskell, and back again to achieve something that would have initially seemed like a crazy thought experiment. But, utilizing Hamiltonian mechanics, we have a system that can automatically generate equations of motion given your coordinate system and a potential energy function. We also learned how to leverage typed vectors for more correct code and a smoother development process.

See my previous post for even crazier examples – involving multiple objects, double pendulums, and more. And check out my hamilton library on hackage, which includes demos for exotic interesting systems, rendered graphically on your terminal.

I realize that this was a lot, so if you have any questions or suggestions for clarifications, feel free to leave a comment, drop me a tweet, or find me on the freenode *#haskell* channel (where I usually idle as *jle`*!)

The picture with a time-dependent Hamiltonian is different, but only slightly. In the time-dependent case, the system still

*tries*to move along contour lines at every point in time, but the mountain is constantly changing underneath it and the contour lines keep on shifting underneath it. Sounds like life!↩There’s also another perpendicular vector, , which actually gives motion

*backwards*in time.↩Disclaimer: I am not a surfer.↩

is full-rank (meaning is invertible) if its rows are linearly independent. This should be the case as you don’t have any redundant or duplicate coordinates in your general coordinate system.↩

Thanks to Edward Kmett for pointing this out!↩

`hessian`

computes the Hessian Matrix for scalar-valued function, but here, we have a vector-valued function, so we need`hessianF`

, the Hessian*Tensor*.↩Clearly our system is gaining some sort of phantom energy, since it rises up to 0.045 on the left, and then all the way up to -0.69 on the right. Rest assured that this is simply from the inaccuracies in Euler’s Method.↩