“The Superposition Guy’s Podcast”, hosted by Yuval Boger, CCO at QuEra Computing
Dominik Ulmer, Chief Quantum Solutions officer at ParTec, is interviewed by Yuval Boger. Dominik discusses ParTec’s transition from a traditional HPC software company to integrating quantum computing into their offerings. He explains their approach to hybrid classical-quantum systems, including virtualizing quantum computers as special nodes within HPC clusters and supporting various quantum modalities. Dominik highlights the importance of minimizing new infrastructure requirements for quantum systems, the use of emulators, and their support for hybrid on-premises and cloud integration. He also outlines ParTec’s physical integration lab. future plans for a Quantum Workbench, and much more.
Listen on Spotify — here
Full Transcript
Yuval Boger: Hello, Dominik. Thank you for joining me today.
Dominik Ulmer: Hi, Yuval. Great to be here.
Yuval: So who are you, and what do you do?
Dominik: Well, I work for ParTec, responsible there for their quantum and AI products. My background is in HPC. Actually, originally I’m a geologist, but that’s former life almost, I would say.
And I joined ParTec about three years ago to build up a new direction of the company because as an HPC company, we’re always interested in anything that pushes out the boundaries of what’s computationally possible. And quantum obviously has a lot of potential for us.
Yuval: And what does ParTec do?
Dominik: We have been mainly a software company until three years ago. We developed software that enables us to do what we call modular computing on heterogeneous HPC systems, managing such systems, optimizing performance on those systems, and enabling communication between the modules of those systems.
About three years ago, we decided to look also at other technologies than classical computing. Obviously quantum computers embedded in HPC systems match our strategy of building heterogeneous parallel computers.
Yuval: If you think about hybrid classical quantum applications, it sounds like your software can connect the classical side to the quantum side. What is common between classical and quantum computers as far as you are concerned? And what is different between classical and quantum processors?
Dominik: A lot of differences. I think that’s what you notice first about it. Let me explain our approach, how we do the integration which we do coming from a customer perspective.
We think that quantum computers will be an important building block in academic or research oriented HPC centers. They have of course established a way how to operate those systems and how to use the systems of the last decades, and they don’t want to change these practices.
Our approach is to virtualize the quantum computer as a special node in the HPC cluster. Thus it can be managed by the sysadmin in a way that they are used to, as much as that is possible from a physical point of view.
This approach also allows to keep the way user access is managed and system usage is managed to be the same. We can project priorities, compute time allocations, or even security policies from the HPC environment on the quantum system.
For the end-user, using such a hybrid system will be a little bit like programming a CPU-GPU system if you want. They will off-load certain tasks in the application from the classical system to the quantum computer. You have to identify those elements in the code that you can and want to run on the quantum computer, but you will have to use a completely different programming style and language for these elements.
Research over the next few years will be about aspects such as how such offloading works, how close these loops between the classical and quantum have to be, what type of algorithms gives you the initial advantage, and so on.
ParTec wants to build not only the software for the HPC-QC integration, but we also want to establish ourselves as an hardware integrator, anticipating a development that happened in the HPC market in the past. Initially, you could buy monolithic systems where everything came from the same company – CPU, interconnect, software stack etc -, but today, HPC systems are integrations of technologies from different suppliers.
In quantum computing we see the beginning of the formation of such a supply chain of technology providers which will allow you to integrate quantum computers from components. Compared to classical computers, however, the heterogeneity on the quantum compute side – the technologies and how these systems behave – is of course much, much broader. Yes, there are differences between an ARM or an AMD or an Intel processor, but the way they basically behave and how you use them is very similar. That’s not the case between QPUs of different modalities of quantum computing.
Yuval: Let me dive deeper into that. I understand that the programming model is different. I understand that it’s different. CPU and GPU and QPU code are different. I understand, or I think I understand, that some things like security and reserving the resources or maybe billing and priorities are probably common across all types of computers. But other than the code itself, what is different from your viewpoint between classical and quantum?
Dominik: As someone who ran a computer center myself for nine years, I can tell you it starts already at the infrastructure side. You have completely new requirements for the data center infrastructure, and what we try to do is to identify those technologies for our solutions that minimize the new requirements as much as possible. For a cryogenic system for example, we want solutions for which you don’t need special certifications for liquid nitrogen handling. That’s where it starts.
On a classical computer, a customer can nowadays manipulate a large part of the hardware components themselves, where in quantum they wouldn’t or shouldn’t. That’s comparable to the early HPC times. Classical systems today don’t need hardware support engineers permanently onsite. But when you bought a supercomputer 30 years ago, you bought two onsite engineers with your machine because the system needed a similar level of handholding like a quantum computer today.
Yuval: I understand the differences on the hardware side, but I’m wondering if on the system management side. So for submitting a job, is it any different? Resource allocation, is it any different between classical and quantum? Obviously the cryogenics and the coding language and the tool chain are completely different.
Dominik: If you virtualize your quantum computer as a node in your HPC cluster, it’s a very expensive node compared to the others. Typically in an HPC cluster, the user books a node completely for their current job.
Probably would like to avoid this exclusive approach for this very expensive node. It rather should be a shared resource for which you allow simultaneous access by various jobs in order to maximize utilization and reduce long wait times.
An emulator with the real noise model of the actual physical system is a very useful extension basically that you may want to add for two reasons:
First, you also may not want every user to go immediately on the real hardware because when they are in an early stage, that’s too expensive again to let them on. They can work initially on the emulator.
Second, you may have a cryogenic system with extended downtimes that you don’t experience on a classical computer. A node on a classical computer may fail, you replace a part, you boot it again and then you’re done.On a cryogenic system, you have to warm up, change parts, and cool down. The system may be gone for several days and the emulator can step in during that period.
Yuval: We spoke a lot about cryogenics, which of course is a concern when doing superconducting computers, but there are other technologies like neutral atoms that do not require cryogenics and operate at room temperature. Does your software platform support all types of quantum computers or just specific modalities?
Dominik: We started developing the integration software QBridge together with Quantum Machines as our partner. They basically can drive all types of modalities. However, we started in the design assuming characteristics of a typical superconducting or a silicon spin qubit solution.
But fundamentally, we can drive any modality with the approach to how the software was developed. The soon to be inaugurated Israeli Quantum Compute Center where we work together with Quantum Machines and many other partners will offer access to several different modalities.
Initially, there will be a superconducting system and a photonics annealer. They will be integrated with classical resources that are partially on premise, but mostly in the cloud. ParTec has developed a platform as a service solution which allows you to access those different modalities to which we will add additional ones over time.
Yuval: You brought up an interesting point that I wanted to ask about. Certain users are buying quantum computers on premises. Some have a classical supercomputer on premises, but they still want to access sometimes cloud resources either for the quantum or classical side. Does your software platform support this hybrid situation where some jobs could be executed locally and some jobs could be executed on the cloud?
Dominik: Yes, absolutely. The integration software currently integrates into what we call a SLURM cluster for managing the workload on a parallel HPC system. But the way the software was designed, we can add other workload management types to this.
Not only other HPC workload managers, but also Kubernetes clusters or some other way of running a multi-resource environment.
Yuval: Does ParTec also do the physical integration? So if I wanted to set up a new quantum center, would you help me both with the physical installation, cabling, preparing the nitrogen if I need, as well as the software one?
Dominik: Actually, we started exactly this. As I described, we started with the software side for the integration of quantum and HPC, and now are in the process of setting up a lab for the physical integration. In Munich where ParTec is located, we are building an assembly site at which we will use this component-based approach for building systems, using technologies that we get from suppliers and integrating then the physical system itself. We hope to have the site ready by the end of this year or by early next year.
What we see in the market is, that on the one hand, there are a lot of procurements which basically prescribe exactly what you have to build. Then it’s basically a custom engineering project that you do for that customer.
But what we want to do as the next step in our, what we call ParTec Quantum Factory, is to derive from that a set of standardized components that you put together and that we can vary in a kind of LEGO style, which makes it then a real product.
That product is going to be available as a superconducting solution initially. We’re focused on superconducting for the first product line because of the maturity of the technology at this point and also availability of the aforementioned supply chain.
We think we will have that product available next year as well, together with the factory.
Yuval: In your experience and estimate, how long does it take? So let’s assume I decided on what computers I want to buy. I have space. The computers were delivered. They’re waiting in boxes. How long before my HPC center could be up and running in some fashion?
Dominik: Which means that everything has been delivered to site.
Well, we did two of such integration projects already and let’s use the example of what we did at the Julich research center in Germany. There, we had an existing cryostat that was kind of already operational and we could use, or we have to take this into account.
Integrating not only the hardware, but also integrating in the local supercomputers, took us about three months. That was our very first system.
There was of course still a lot of work to do to make it even more useful, but that’s when first users could get on the system.
Yuval: You mentioned SLURM. Is that, in your opinion, the dominant standard for resource allocation and so on, or do you support other type of frameworks?
Dominik: In academic HPC, I would say SLURM is the most widespread solution. The way, as I described it before, our integration software called QBridge works, we can easily extend this to other workload managers or also even to cloud-style workload orchestration platforms.
Yuval: If you think about your product line, say, two years into the future, what’s the biggest thing that you think people might want in two years that they don’t have today?
Dominik: What we’ve seen in AI in classical computing is that people are very eager to store their experiments, not only the results, but also the way they run the experiments so that they can reproduce those things later. We want to build something similar for quantum, what we call the Quantum Workbench.
For the HPC-quantum integration, we will allow very short and frequent exchanges between the quantum computer and the classic computer with less latency than we have in our current solution. My team has seen that for real experiments and quantum advantage, applications need this very frequent low latency exchange between the two systems.
And on the emulator side, I think we want to give users the choice of different types of simulation codes.
We hopefully will see that people will, exactly what you described before, want to try to run different modalities side-by-side, characterize them and compare them. That could be the direction that people will try to take and we want to support this type of work. Our general approach is to have a very close collaboration with the customer, work with them together on improving the usefulness of the system over the years.
Yuval: Very good. Dominik, thank you so much for joining me today.
Dominik: Likewise, it was a pleasure talking with you.
To subscribe to the audio podcast, please Spotify here
