Hi there! We have reached the final lesson of the series *Space and Time â€” Introduction to Finite-difference solutions of PDEs*, the second module of "Practical Numerical Methods with Python".

We have learned about the finite-difference solution for the linear and non-linear convection equations and the diffusion equation. It's time to combine all these into one: *Burgers' equation*. The wonders of *code reuse*!

Before you continue, make sure you have completed the previous lessons of this series, it will make your life easier. You should have written your own versions of the codes in separate, clean IPython Notebooks or Python scripts.

You can read about Burgers' Equation on its wikipedia page. Burgers' equation in one spatial dimension looks like this:

@@0@@

As you can see, it is a combination of non-linear convection and diffusion. It is surprising how much you learn from this neat little equation!

We can discretize it using the methods we've already detailed in the previous notebooks of this module. Using forward difference for time, backward difference for space and our 2nd-order method for the second derivatives yields:

@@1@@

As before, once we have an initial condition, the only unknown is @@2@@. We will step in time as follows:

@@3@@

To examine some interesting properties of Burgers' equation, it is helpful to use different initial and boundary conditions than we've been using for previous steps.

The initial condition for this problem is going to be:

@@0@@

This has an analytical solution, given by:

@@1@@

The boundary condition will be:

@@2@@

This is called a *periodic* boundary condition. Pay attention! This will cause you a bit of headache if you don't tread carefully.

The initial condition we're using for Burgers' Equation can be a bit of a pain to evaluate by hand. The derivative @@0@@ somewhere, so we're going to use SymPy to help us out.

SymPy is the symbolic math library for Python. It has a lot of the same symbolic math functionality as Mathematica with the added benefit that we can easily translate its results back into our Python calculations (it is also free and open source).

Start by loading the SymPy library, together with our favorite library, NumPy.

We're also going to tell SymPy that we want all of its output to be rendered using @@0@@. This will make our Notebook beautiful!

Start by setting up symbolic variables for the three variables in our initial condition. It's important to recognize that once we've defined these symbolic variables, they function differently than "regular" Python variables.

If we type `x`

into a code block, we'll get an error:

`x`

is not defined, so this shouldn't be a surprise. Now, let's set up `x`

as a *symbolic* variable:

Now let's see what happens when we type `x`

into a code cell:

Loading output library...

The value of `x`

is @@0@@. Sympy is also referred to as a computer algebra system -- normally the value of `5*x`

will return the product of `5`

and whatever value `x`

is pointing to. But, if we define `x`

as a symbol, then something else happens:

Loading output library...

This will let us manipulate an equation with unknowns using Python! Let's start by defining symbols for @@0@@, @@1@@ and @@2@@ and then type out the full equation for @@3@@. We should get a nicely rendered version of our @@4@@ equation.

Loading output library...

It's maybe a little small, but that looks right. Now to evaluate our partial derivative @@0@@, we can just use:

Loading output library...

If you want to see the unrendered version, just use the Python print command.

Now that we have the Pythonic version of our derivative, we can finish writing out the full initial condition equation and then translate it into a usable Python expression. For this, we'll use the *lambdify* function, which takes a SymPy symbolic equation and turns it into a callable function.

To lambdify this expression into a usable function, we tell lambdify which variables to request and the function we want to plug them into.

Now that we have the initial conditions set up, we can proceed and finish setting up the problem. We can generate the plot of the initial condition using our lambdify-ed function.

We have a function `u_lamb`

but we need to create an array `u`

with our initial conditions. `u_lamb`

will return the value for any given time @@0@@, position @@1@@ and @@2@@. We can use a `for`

-loop to cycle through values of `x`

to generate the `u`

array. That code would look something like this:

`1 2 3 4`

`u = numpy.empty(nx) for i, x0 in enumerate(x): u[i] = u_lamb(t, x0, nu)`

But there's a cleaner, more beautiful way to do this -- *list comprehension*.

We can create a list of all of the appropriate `u`

values by typing

`1`

`[u_lamb(t, x0, nu) for x0 in x]`

You can see that the syntax is similar to the `for`

-loop, but it only takes one line. Using a list comprehension will create... a list. This is different from an *array*, but converting a list to an array is trivial using `numpy.asarray()`

.

With the list comprehension in place, the three lines of code above become one:

`1`

`u = numpy.asarray([u_lamb(t, x0, nu) for x0 in x])`

Loading output library...

Now that we have the initial conditions set up, we can plot it to see what @@0@@ looks like:

Loading output library...

This is definitely not the hat function we've been dealing with until now. We call it a "saw-tooth function". Let's proceed forward and see what happens.

We will implement Burgers' equation with *periodic* boundary conditions. If you experiment with the linear and non-linear convection notebooks and make the simulation run longer (by increasing `nt`

) you will notice that the wave will keep moving to the right until it no longer even shows up in the plot.

With periodic boundary conditions, when a point gets to the right-hand side of the frame, it *wraps around* back to the front of the frame.

Recall the discretization that we worked out at the beginning of this notebook:

@@0@@

What does @@1@@ is already at the end of the frame?

Think about this for a minute before proceeding.

Loading output library...

Loading output library...

Loading output library...

Coding up discretization schemes using array operations can be a bit of a pain. It requires much more mental effort on the front-end than using two nested `for`

loops. So why do we do it? Because it's fast. Very, very fast.

Here's what the Burgers code looks like using two nested `for`

loops. It's easier to write out, plus we only have to add one "special" condition to implement the periodic boundaries.

At the top of the cell, you'll see the decorator `%%timeit`

.
This is called a "cell magic". It runs the cell several times and returns the average execution time for the contained code.

Let's see how long the nested `for`

loops take to finish.

Less than 50 milliseconds. Not bad, really.

Now let's look at the array operations code cell. Notice that we haven't changed anything, except we've added the `%%timeit`

magic and we're also resetting the array `u`

to its initial conditions.

This takes longer to code and we have to add two special conditions to take care of the periodic boundaries. Was it worth it?

Yes, it is absolutely worth it. That's a nine-fold speed increase. For this exercise, you probably won't miss the extra 40 milliseconds if you use the nested `for`

loops, but what about a simulation that has to run through millions and millions of iterations? Then that little extra effort at the beginning will definitely pay off.

Loading output library...