For organizations
Provide one quantum-simulation environment across research groups while keeping infrastructure, access, project boundaries, and data under organizational control.
QuFabric
In deployment talks
A quantum simulation platform for your research organization.
WECORE Cloud deploys QuFabric on infrastructure your organization controls, giving research teams one governed workspace for notebooks, open-source simulation engines, and research work that stays inside the institution.
Open-source simulation engines
Circuits, chemistry, many-body, open systems
Notebook-first workflow
Data stays in your environment
QuFabric is a module of the WECORE Cloud management panel, running on cloud capacity your organization operates.
QuFabric Workbench preview with sample values; the cluster, blueprint and checks are illustrative, and job submission is not available yet.
Quantum simulation as an organizational research platform
Commission QuFabric for university, laboratory, or enterprise research teams that need reproducible simulation workflows without sending inputs and results to another cloud.
What your users can do
Develop in notebooks, work inside the project that scopes their research, choose from the simulation engines your infrastructure team has made available, and prepare runs against pinned environments that rebuild exactly.
What your infrastructure team gets
Control identity, project access, environments, quotas, approved engines, compute allocation, data location, monitoring, and lifecycle policies.
How WECORE deploys and operates it
We validate the target infrastructure, deploy and integrate QuFabric, configure research environments with your team, and provide the agreed ongoing operations.
7
Open-source engines in scope
3
Research lanes
Self-hosted
Runs on your own cloud
Pinned
Checksummed, reproducible environments
Workflow
The research workflow, step by step
QuFabric brings projects, environments, Jobs, and results into one self-hosted workspace, designed to connect interactive research to scheduled execution on the cluster your organization designates.
1
Work in a project
A project is the durable workspace research belongs to: notebooks, inputs, collaborators, and every run that follows from them.
2
Choose an environment
The environment catalog is built around reproducible scientific stacks (Cirq + qsim, quimb + cotengra, TeNPy, QuTiP, PySCF, OpenFermion + PennyLane, and NetKet) and an engine appears only after your operators activate it against the image and cluster actually in service.
3
Prototype interactively, then prepare a run
Work in Jupyter, then describe the same code as a Job blueprint: engine, source file, resources, and run time. QuFabric estimates the memory the chosen method needs and checks it against the designated research cluster, so a run too large to fit is caught in the form rather than after it has waited in the queue.
4
Track reproducible results
The Job record is built to carry the engine version, the pinned environment, input files, the resource request, and logs, so a run can be traced back to exactly what produced it.
Research lanes
Three research lanes
The environment catalog is organized by research area: each stack is defined with the packages, example notebooks, and resource presets that area needs.
Circuits
Quantum Algorithmist
Gate-based circuit simulation with Cirq and the qsim statevector engine: amplitudes, sampling, and expectation values. This is the runtime baseline QuFabric verifies today.
Cirq
qsim (qsimcirq)
Tensor networks + dynamics
Many-Body Physicist
QuFabric's many-body scope covers DMRG ground states and TEBD/TDVP time evolution with TeNPy, tensor-network contraction with quimb + cotengra, neural-network quantum states with NetKet, and open-system dynamics with QuTiP.
TeNPy
quimb
cotengra
NetKet
QuTiP
Molecules
Quantum Chemist
CPU chemistry environments can be scoped for mean-field, Hartree-Fock, and potential-energy-surface research workflows, with inputs and results kept inside the organization.
PySCF
OpenFermion + PennyLane
Platform
One reproducible workspace for open-source engines.
QuFabric is not another simulator. It adds a managed research workspace to the WECORE panel and brings established open-source engines to cloud capacity you already operate.
QuFabric
Sample record
project: h2-ground-state
engine: Cirq · qsim
source: ground_state.py
resources: 1 node · 8 CPU · 02:00
preflight: passed
state: blueprint (pre-release)
result: none yetSample QuFabric job record; the project, engine and resources shown are illustrative, and job submission is not available yet.
Curated environments
An environment catalog organized by research area, where every entry resolves to an exact, checksummed artifact set with a software bill of materials.
Track complete Jobs, not just run IDs
QuFabric gives each Job a stable, project-scoped identity and a full lifecycle record (status history, cancellation, and retries) so a run is accounted for, not just named.
From notebook to scheduled execution
QuFabric is designed to connect interactive research with scheduled cluster execution and parameter-sweep workflows, keeping related runs grouped under the project that owns them.
Results kept with the run
QuFabric's result layer is defined around versioned result schemas, normalized counts, statevectors, expectation values, and other artifacts, held with the run's logs and metrics.
Notebook-first workflow
Prototype in JupyterLab against the same pinned environment a run is later described against, nothing about the software stack changes between exploration and scale.
Control in your own environment
Run on cloud capacity you already operate and keep sensitive circuits, chemistry inputs, and results inside your environment.
Engines
A pinned simulation runtime, inside a governed workspace.
Cirq and qsim ship in the pinned runtime; the research environment, access, and resources are configured for the organization.
Pinned runtime
Cirq + qsim
Gate-based quantum circuit simulation with statevector amplitudes, via qsimcirq.
Research workspace
JupyterLab
Owner-scoped kernels bound to a named, reproducible environment.
Pinned environments
Exact, checksummed artifact sets with a software bill of materials.
Project controls
Projects and access
Membership, project isolation, approved environments, and compute allocation.
Simulation records
Activity history, engine version, inputs and logs are recorded against the run that produced them.
Measured · 2026-08-18
| Qubits | Amplitudes | Statevector | Run time (s) |
|---|---|---|---|
| 24 | 224 = 16,777,216 | 0.12 GiB | 1.63 |
| 26 | 226 = 67,108,864 | 0.5 GiB | 7.23 |
| 28 | 228 = 268,435,456 | 2.0 GiB | 34.47 |
| 30 | 230 = 1,073,741,824 | 8.0 GiB | 146.69 |
These times are single-threaded: qsimcirq's default cpu_threads=1 was left unchanged, so each figure reflects one core of the 32-vCPU node, not the full machine.
CPU-only here is categorical, not circumstantial. The installed qsimcirq wheel ships only the basic, sse, avx2, avx512 and decide simulators and contains no CUDA module, so there is no GPU code path to select; and the pinned profile admits exactly cirq==1.7.0 with qsimcirq==0.22.0 and no CUDA or NVIDIA artifact. Either reason is sufficient on its own. The host does have a GPU; this run could not reach it.
Computed ceiling — the complex64 statevector model (2ⁿ × 8 bytes) on a 125 GiB node gives about 33 qubits before framework and workspace overhead. This is arithmetic, not a run.
A reproduction baseline, not a performance, scaling, service-level or capacity claim.
Checked against an independent reference
Two teaching examples ship with the module, each checked against a reference written from scratch in Python with only basic numerical libraries and no quantum library at all.
Transverse-field Ising · VQE
4 spins · h = 0.7 · open boundary · 4 RY layers with a CNOT chain · 400 optimisation steps
- Energy from the algorithm
- −3.866416
- Exact energy, by diagonalisation
- −3.872983
- Difference
- 6.57e−03
- Run time (s)
- 8.93
Reference: direct diagonalisation of the 16×16 Hamiltonian.
MaxCut · QAOA
4-node star graph · depth 2 · no sampling noise · random seed 25102
- Objective at the start
- 1.941810
- Objective at the end
- 2.808037
- Selected solution
- 0100
- Run time (s)
- 4.86
Reference: full enumeration of all 16 states. The best cut is 3, at 0100 and 1011.
89.64% of the final probability sits on the two optimal solutions, so the algorithm did not reach them by chance. Both values came out exactly as recorded inside the package.
Why WECORE Cloud
A cloud workflow, with managed research environments.
Dimension
Hosted quantum clouds
QuFabric
Deployment
Vendor SaaS account
The cloud capacity you already operate
Where data is stored
Inputs and results leave your institution
Projects, Jobs, and artifacts stay on your storage
Simulation control
Fixed provider images and credit meters
Tested environments that can be copied and reproduced
Scaling model
Provider-specific queues
One project model, from interactive notebooks to the designated research cluster
Value
Access to vendor capacity
A managed research workspace on infrastructure you own
FAQ
Quantum simulation questions, answered
What QuFabric is, what it is not, and how it fits your research workflow
No. QuFabric is a quantum simulation platform: open-source engines running on the classical capacity of your own cloud. WECORE does not provide quantum hardware, QPUs, or supercomputers, and nothing on this page runs on real qubits.
QuFabric is in its first deployment conversations: each deployment is scoped, validated, and operated with the research organization. If you don't run a cloud foundation yet, the engagement can include deploying the open-source infrastructure layer the platform runs on. Submission to the queue stays closed until a research cluster is designated and validated for the deployment; the blueprint form and its checks are there in the meantime, so a run can be prepared and reviewed. Request a briefing to be part of that stage.
The current verified runtime baseline contains Cirq and the qsim statevector engine. Additional research environments and engine requirements are defined and validated for the deployment.
Researchers prototype in their project's notebook environment, then describe a run against the compute resources allocated to that project (engine, source file, resources, and run time) and QuFabric checks that blueprint against the designated research cluster. Simulations currently run on exactly one node, so memory is what sets the ceiling: a state vector grows as 2ⁿ and a density matrix as 2²ⁿ, and the check compares that estimate with the memory the designated cluster actually offers. Scale depends on the organization’s infrastructure and quota.
Hosted services run your work on their infrastructure, under their account and credit model. With QuFabric, your team manages projects, environments, Jobs, and results on capacity you operate, so circuits, chemistry inputs, and results never leave your environment.
Yes. JupyterLab is the working surface, with owner-scoped kernels bound to a named, reproducible environment; the same environment a run is later described against, so nothing about the stack changes between exploration and scale.
Reproducibility is built into the Job record, which is designed to carry the engine version, the image it resolves to, the source file, the resource request, the random seed, logs, and timing, so a result points back at the exact stack that produced it. Environments are pinned to checksummed artifact sets, so that stack can be rebuilt. Re-executing a Job automatically, with a guaranteed identical result, is not something QuFabric offers yet.
WECORE deploys the platform and operates the agreed platform lifecycle, monitoring platform health, coordinating upgrades, and working incidents within the responsibility split agreed for your deployment. Your team owns identity, projects, quotas, approved engines, and data location; your researchers own their Jobs and results. Panel access is role-based, and administrative actions are recorded in tamper-evident audit records.
QuFabric is delivered as a scoped deployment engagement. Pricing is tailored to each deployment and reflects the infrastructure, research environments, and operational scope agreed with the organization.
QuFabric
Run quantum simulation on your own cloud
QuFabric is for research teams that want a modern simulation workflow without sending sensitive circuits, chemistry inputs, or results to someone else's cloud.