PDEs: theses (time) bounds are made for solvin'


Table of Contents

This is the third post of the series about partial differential equations (PDEs). In the first and second posts, we explored two issues inherent to PDEs (domain of definition and boundary conditions) that might be an issue for quantum algorithms due to the need to input classical data into a quantum computer.

In this post, I want to show you that boundaries are not limited to the spatial domain of definition: the time dimension is important too! And that comes with its limitations too.

Time is a strange dimension

In my previous post, I explained why it is impossible for us to consider the whole universe when solving PDEs. Instead, we only consider our physical domain of definition and set some values at the boundaries of this domain.

Visual example of what is a boundary condition. The values set at each boundary points do not have to be constant. Image from [Wikipedia](https://commons.wikimedia.org/wiki/File:Boundary_value_problem-en.svg) licensed under [CC BY-SA 3.0](http://creativecommons.org/licenses/by-sa/3.0/).
Visual example of what is a boundary condition. The values set at each boundary points do not have to be constant. Image from Wikipedia licensed under CC BY-SA 3.0.

But there is one thing that we forgot: time is also part of our domain of definition.

Just like we cannot solve a given PDE on the whole universe, it is impossible to solve a time-dependent PDE (i.e., a PDE that also depends on time, like the heat equation or the wave equation) for every time $t$ that ever happened.

So instead of computing for any time $t$, we limit our numerical resolution to a domain of definition, i.e., a specific range of time $\left[ t_0, t_\text{final}\right]$ in which we will solve the equation.

Arrow of time, $t_0$ is the first time that is part of the domain of definition, $t_\text{final}$ is the last time we are interested in, i.e., the time for which we want to get the PDE solution.
Arrow of time, $t_0$ is the first time that is part of the domain of definition, $t_\text{final}$ is the last time we are interested in, i.e., the time for which we want to get the PDE solution.

But time is a strange dimension: it only goes forward!

Let’s use again the bedroom example to illustrate this.

It is 6PM, you just came back from work, enter your bedroom, and feel a chill running down your spine: the bedroom is too cold. You look at the thermometer: 12°C (~54°F). You want to know its temperature at 11PM, when you usually go to bed, if you switch on the heater now.

This is the kind of problems that can be solved thanks to the heat equation! The time $t_0$ is 6PM, $t_\text{final}$ is 11PM, you know the state (i.e., the temperature) of your domain of definition (i.e., your bedroom) at the time $t_0$ and want to devise its state at the time $t_\text{final}$.

Time, space, you are different, but I love both of you equally

But as noted at the beginning of this post, time only goes forward. This makes the time dimension different from any space dimension.

For any spatial dimension, all the boundaries have to be defined with boundary conditions.

But for time, only one of the two boundaries ($t_0$) can be defined, because knowing the values of the other boundary ($t_\text{final}$) is the end-goal of our problem!

This means that, just like the spatial domain of definition, the temporal domain of definition needs some boundary conditions. But the temporal domain of definition only needs one boundary to be clearly defined: $t_0$.

In order to acknowledge the difference between spatial and temporal boundary conditions, the temporal boundary conditions are denoted as initial conditions.

Here are my initial conditions, take it or leave it!

Up until now I spoke about initial conditions without giving you any graphical example to illustrate! Coming back to the bedroom example from before, a possible initial condition is depicted in the image below.

Temperature of your bedroom at the time $t_0$. In this example, the temperature is not constant accross the room.
Temperature of your bedroom at the time $t_0$. In this example, the temperature is not constant accross the room.
Temperature of your bedroom at the time $t_0$. In this example, the temperature is not constant accross the room.
Temperature of your bedroom at the time $t_0$. In this example, the temperature is not constant accross the room.

An initial condition consists in a representation of the temperature within our domain of definition at the initial time $t_0$.

If you followed attentively and understood the first and second posts, you probably see it coming…

Encoding the initial condition requires to encode classical data into a quantum computation!

"Here we go again", data input is again the root of another issue practical quantum PDE solvers will face in the future. Image from the meme culture, originating from the initial scene in the game *GTA: San Andreas*. [Explanation and history](https://knowyourmeme.com/memes/ah-shit-here-we-go-again).
“Here we go again”, data input is again the root of another issue practical quantum PDE solvers will face in the future. Image from the meme culture, originating from the initial scene in the game GTA: San Andreas. Explanation and history.

The root cause is, again, the inefficiency of inputing data into a quantum computation.

Other data input problems

You might think that the three different data input problems we have seen until now cover all the possible data input issues. And you would be wrong!

There are other situations in which solving a PDE will require to input classical data into a quantum computation.

This is for example the case when one of the PDE parameter is not constant accross the domain of definition. This situation can be encountered when trying to solve the heat equation on a domain with a non-constant thermal diffusivity for example.

Another issue arise if only a part of the PDE solving algorithm is performed on the quantum computer. In this case, you will have to communicate the results obtained by the classical computation to the quantum computation, which is again trying to input classical data into the quantum computer.

Conclusion

The inability to encode classical data into a quantum computation impacts deeply the potential of quantum computer to solve PDEs. It is not impossible, but

  • the domain of definition,
  • the boundary conditions,
  • the initial condition and
  • every other classical data that needs to be communicated to the quantum computation

have to be efficiently encodable, which might severely limit the number and types of PDEs that will be efficiently solvable on a quantum computer.

Want to get details about the efficiently encodable types of data?

It turns out that I just created my company and that I am offering counselling as part of my work 😉.

Feel free to contact me if you want to know more on this subject.

Also note that I did not write a single word about the quantum computer architecture or the software library used to implement the hypothetical PDE solver. All the potential issues listed here are theoretical, and apply to any hardware that is unable to efficiently encode classical data into a quantum computation.

And as far as I am aware, none of the current architectures is able to perform this encoding efficiently.

I am not a hardware expert, so take my last sentence with appropriate care (i.e., double check it, do not take it for granted, ask around if you know hardware-people).

What’s next?

In these first three posts, I (very briefly) covered the problem of inputing classical data.

Next week, I want to speak about outputing, i.e., how can we recover the results of our computation in order to use them.

If you want to be notified when each post is out, you can add me on LinkedIn, I will do a LinkedIn post for each new blog post.

Also, if this post picked your interest or raised some questions in your mind, please feel free to send me a message 😉

Adrien Suau
Adrien Suau
Entrepreneur in Quantum Computing

I am an entrepreneur in quantum computing. I also do business consulting, so feel free to reach out!

Next
Previous