We can start with the next call.
So actually it's going to talk about some of the open search tools that the end is
in my writing for Magnostic.
Thank you, Rosanto.
Hi everyone.
So my name is Arshit.
I'm from India and I work with Kubrick as a quantum software engineer.
And today I'm going to be talking about open source tools for platform,
agnostic, quantum computing.
That's a lot to take in.
So we're with me.
And it's going to be a little bit similar in the talk that we had just now,
with QMAT, but a lot more than that.
So let's get started.
So the agenda is threefold.
First, we're going to be talking what exactly is Kubrick.
What are the motivations in why we exist?
Then we're going to be diving into the open source tools,
which we have read.
The first and the foremost is the Kubrick SDK.
In this, we have two components.
The Kubrick runtime and the Kubrick transpiler,
which enables users to develop platform agnostic algorithms.
And then finally, I'm going to be talking about a relatively new tool.
That's called piecasm, which is, you know,
transformation analysis of quantum assembly language with Python.
So let's get started.
So first of all, let's understand why Kubrick.
And imagine your user, and you're trying to get into quantum,
or you're already in quantum, right?
And think of your initial days.
So what do you do?
You learn a bunch of theory.
You learn a bit of linear algebra or some quantum information signs.
And then you want to actually run your quantum circuits,
first on the simulator, and then on the hardware, right?
How do you get access to that hardware?
And let's say once you've learned a particular package,
how do you, you know, run your circuits to different hardware, right?
You know, the problem that are found are also face like,
I would say, four years ago.
And that is how Kubrick was born.
To be a one-stop platform, enabling quantum computing,
and not having as, you know, the last speaker said,
vendor lock-in, right?
So this is one feature that we have.
That's called the Kubrick lab.
What Kubrick lab provides is quantum software development
in the cloud itself.
And I'm going to be showing a quick demo after this slide.
And you can, you know, pretty easily start working
with any particular quantum computing package,
like Kiskit or Amazon's bracket or Serk or Google Serk.
And also use Kubrick SVK, which is our open source tool,
to, you know, integrate your quantum jobs on different hardware.
Okay?
And let's have some moving pieces now.
So this is a demo.
This is, this is what you, you know,
live at when you land at Kubrick.com.
And whenever you click start now, this is our account page.
This represents what kind of plan you have,
how many credits you have.
And for the purposes of this demo,
I'm going to be talking about three services,
quantum jobs, devices, and lab environment manager.
Why?
Because they use the open source tools,
which I'm going to be talking about, post this demo.
Okay?
So first, let's, you know, talk about quantum jobs, right?
So let's say you have any particular vendor,
you want to execute your quantum circuit on.
You can see that through this interface.
This is called the quantum jobs interface.
And you can click on any particular job,
and see the details regarding how many Kubricks
were present in that job, or, you know,
what was the circuit depths,
whether they were any measurements or not in that particular job.
And the details about the provider on which this job was run.
Okay?
This is regarding quantum jobs.
Then comes the devices.
So we have a lot of integrations with different vendors,
which provide their simulators and hardware through our platform.
So for the sake of this example,
I will, for the sake of this presentation,
I'll take the example of AWS's state vector simulator.
Here what you can do is that you can just,
get some details about the device,
and the computing, the cubits, and the availability of the device.
And what is the form of access?
So here it's bracket, that's the package, which AWS has developed.
And next, we're going to be talking about the lab environment manager.
That is present in the cubrid lab environment,
which is launched right now.
That is a feature which allows you to, you know,
develop Python virtual environments directly in the cloud
and persists them across your sessions.
So this is the lab interface, and this is very much like Colab,
but a lot more tuned towards quantum computing.
Okay?
This is the lab environment manager.
You have a lot of environments pertaining to a user.
And you have a lot of environments,
which are publicly available for any user to install and work with.
This is what I'm scrolling right now.
Let's take an example of, let's say, Penny Lane.
This is Zanadoos environment and we click Install.
That will be available for any user in their personal environment,
which you can see here.
And you can just click on it, activate it, and there you go.
You can start using your Jupiter notebooks right with this environment's kernel.
Okay?
I already have Cubid SDK installed, and we can just add the kernel for that particular environment.
We can click on that notebook and run with all the good stuff present in that kernel for that notebook.
So this was kind of setting the background for the tools.
And the most important ones are Cubid SDK and Pycasm.
And let's talk about Cubid SDK now.
So as you saw that Cubid SDK is a tool, which allows users to not think about how they're going to do something.
But mostly about what they want to do.
Let's say a user wants to write a quantum program.
They only think about what's going to be the algorithmic details,
but not the implementation details.
So that is like the core motivation of Cubid SDK.
And yeah, it's available on Pyp.
You can install it, you can want to be turned.
So yeah.
And the feature right now I'm going to be talking about is Cubid runtime.
What this does is, you know, material for after we talk about what the problem it's solving.
Right?
Let's first imagine that you are a user and you have a high level programming language.
And you want to execute your program on a quantum computer.
How do you do that?
Well, it's not very trivial.
You need to, you know, go through converting a program into an IR or an intermediate representation.
Go through the, you know, stuff of client side management authentication.
So on and so forth.
Then billing and then finally executing on the hardware and then getting back the results and transforming them.
Right?
This is not very easy.
And this is why we have built Cubid runtime.
What it does is that it will take your program.
It will convert that to device specific constraints,
such as the gate set of a device or what kind of topology you have.
Then finally it will convert that to a quantum program IR,
which can be opened for under assembly language or it can be,
the LLVM IR that is the QIR representation.
And then finally you have the client side authentication,
which is built into Cubid, which interacts with the Cubid API on the backend.
So this is, you know, about Cubid runtime.
And now we will see another demo of Cubid runtime.
This is just another condensed information.
So, okay.
All right.
So I have a Jupyter notebook running locally.
And just to highlight that this is all local.
You can also prep install Cubid and start working on this notebook.
Right?
Given you have set it up correctly.
So yeah, you can prep install Cubid.
I'm not going to be doing that here.
You can print the version.
There are some extractions present here such as the provider or the device.
You're trying to run your program on.
Provider here is Cubid because we are hosting all of these simulators,
which you are, you know, seeing here.
Okay.
And then we can choose for the sake of this demo,
the AWS is straight vector simulator.
And you can clearly see that the target specification,
or the program type it expects is bracket,
which has been developed by AWS.
And for here, we're just going to be preparing a GFZ state.
This is a very simple max million times in the state.
And you will set a short.
I mean, a key point to note here,
we're going to be building in packages,
which are not directly supported on AWS.
Here we're building in search, which is a Google package.
Post that will build and kiss it.
And then send directly to the AWS simulator,
so that we can, you know, see how good Cubid SDK is.
This will take some time because obviously this is interacting
with the actual AWS packet, but I will end here on the jobs.
And just to explain a little bit,
this is the simulator object.
We run the circuit, and hey, we got results.
Okay.
And these are the probability of our results.
Similar case is with the kiss kit,
circuit, we again take the AWS simulator,
run the kiss kit, circuit, get the results back, and display them.
Okay, so this is just, you know, promoting the efficacy of Cubid,
that we are actually using different packages to run
circuits on different devices.
Okay, getting back to the presentation.
All right.
So yeah, as you saw that this enables agnostic quantum development.
You can code in any package and execute on any backend with Cubid.
And you can also see our runtime user guide, which we have on docs.
We currently integrate with kiss kit,
a Microsoft Azure, then AWS, OQC,
IonQ, they're also other providers as Cubera,
and any C, which are integrated,
but these are one of the foremost.
And yeah, this was the demo for runtime.
Now let's go behind the scenes.
How do we do that?
So we have something called a Cubid Transpiler,
which detects and makes your circuits
run-able on a quantum device, right?
Let's dive into the details of that.
It allows you to convert one package to another,
transform your, you know, program to device specific requirements,
and then finally also enables access to any optimizations that you have
in a particular package, right?
Because that's integrated with our SDK.
The model is similar to a graph.
I think most of you are familiar with the graphs in the redesigns.
Every single node we have is a quantum computing package,
and an edge to another package is a conversion path.
So let's say we choose search,
and you want to convert to, let's say, kiss kit.
We can go through search, bracket, kiss kit,
or we can choose to cancel and do to kiss kit.
So this is our Transpiler model.
This is our works behind the scenes.
And a test, do ensure that there is unitary equivalence,
or basically there's no loss between converting one particular circuit
from one package into another,
and we have a very robust unit test for that.
And you can easily execute as we saw a kiss kit
so we can get on an Amazon back.
So you can also see code here, which is present in our bit of repo.
And this is like the example for the conversions.
Let's say you take kiss kit, which is IBM's quantum computing package.
You call Cubrid or Transpile on it.
You take the circuit, you take the target,
and then you can, you know, Transpiler,
circuit to let's say AWS,
search, open gasm, penny lane, or anything else.
Again, this is our demo node book,
which you can, you know, see to just see this in action.
So flag that.
Now, finally, we also have a pretty vibrant community,
and we have a lot of issues and help required in Cubrid SDK,
and other open source tools.
And we also participate in Unitary Hack,
in which contributors can actually, you know,
submit PRs to different issues that we've registered for the Unitary Hack.
And currently, we also have part of the QOSF mentorship program,
which is a quantum open source foundation,
where there are different cohorts for different mentees
to participate in and develop cool projects.
So, yeah.
And now, let's talk about PyCasm.
So, PyCasm is a tool, which we have recently developed
for, you know, open gasm program transformation and analysis.
And this is also a PayPal installable.
You can, you know, play around with it.
You don't even require any kind of, you know, access from Cubrid
to interface with it.
So, let's think about motivations first.
And for those of you who don't know, open gasm
or open quantum assembly language,
is one of the most popular IRs in quantum.
And that the effort has been, you know,
undergoing with IBM lot.
And gasm version 3.x, which was released, you know,
in recent years, has a very extensive grammar.
So, it is almost like Python, if you see it.
And there are tools with support,
type check-in, and semantic analysis.
But there is not a tool with support,
comprehensive semantic analysis.
So, for example, if you see here,
this is an open gasm code segment.
You can see there are functions involved.
There are Cubrid declarations involved.
There are loops involved.
Then there are, you know, types involved.
How do we actually make this open gasm program,
runnable on a quantum device?
Because those devices just support, you know,
let's say the Clifford set.
Or let's say the RZ plus Cx set.
So, something like that.
Sorry, RZ plus Cx.
So, this is the main motivation.
And currently, we have extensive support for each of these features,
which are, you know, present on this, and more.
And a feature which I'd like to highlight is program
unrolling and validation.
So, by unrolling here, I mean, let's say,
we have a very large program,
and we want to decompose it down into sequential instructions,
which a quantum computer can execute.
That is what unrolling is.
And we also have some support for transformation analysis,
wherein you can, you know, plug in your quantum program,
the open gasm program.
Then, you know, start analyzing, like,
how many number of Cubrids should we have,
what's the depths of the program?
Do we have barriers or measurements or so on and so forth?
This is the complete directory,
and just spit out errors if there are n.
So, that was about pikasm.
And these are the references.
These are, you will have to access the slide
because these are links.
It didn't add the full URL fair.
And these are the contact information.
Thank you.
Any questions?
Actually, actually, I have a Q and I'll see you next week.
Yeah.
So, initially, what we came from was a hub and spokes model.
Oh, yeah, sorry.
So, he's asked that the transpiler,
why is the transpiler model going on?
Yes.
So, initially, what we came from was a hub and spokes model.
Oh, yeah, sorry.
So, he's asked that the transpiler,
why is the transpiler model the way it is?
And like, it might be that there's a lot of work
which has been put into it and it can be
probably simplified, right?
From not wrong.
So, initially, what we had was a hub and spokes model.
Where the center there was chasm and every, you know,
every provider went through chasm and then
through the other package.
Something like a bicycle wheel, right?
Yes, folks.
But what we found that our native converters
couldn't actually match those speed of conversions,
which was present in direct converter.
So, for example, let's take the example of, let's say
bracket to cascade, right?
So, if there is a package which directly converts
bracket to cascade and back and back,
then we couldn't actually use that speed or, you know,
their functionality.
So, what we tried to do is that combine, you know,
the best of both worlds and develop a graph-based model.
And this is not complete because the edges also have weights.
So, if the, you know, if the, if we can really not exactly
what we do, is that we try to find out decomposers
in the current package, decompose the program,
and then try to convert, you know,
one-to-one map from the source to target.
And that occurs loss.
So, that means the edges are actually more weighted
if we do not have direct converter.
So, something like that.
Thank you.
Any other questions?
Any one more.
Any one more question?
Any one more thing?
Any other questions?
.
Yeah, you can use that because.
.
Yeah.
.
So as Andrew has said, can we directly use the
.
..
.
Yeah.
.