MAXFlops
A large-scale compute environment for materials research, without procurement or operations overhead. We design and stand up a dedicated HPC cluster you can use the day it goes live.
- Designed and built in the cloud — usable as soon as it stands up
- On-demand capacity when your in-house HPC is full or backlogged
- Tuned per solver — researchers do not have to tinker
- Operations and monitoring included as a managed service
Compute that keeps research moving
- Cloud
- Stood up in the cloud
- On-demand
- Scale up as needed
- Managed
- Operations included
- Tuned
- Solver-specific setup
Core capabilities
From design to operation in one package — so researchers stay focused on the work, not the infrastructure.
Managed cloud HPC
A dedicated cluster designed and built in the cloud. No data center, no in-house admin team needed.
Per-solver tuning
Compiler, library, and MPI settings tuned for DFT, MD, and other workloads — faster results on the same hardware.
Burst capacity
When in-house HPC is full or queues are long, bring up extra nodes immediately so a campaign does not stall.
Job scheduler
Standard Slurm-based scheduling with priorities, quotas, and fair-share policy for team-level resource sharing.
Monitoring & operations
Live view of utilization, queue state, and job history — with incident response handled by the VirtualLab ops team.
Pay for what you run
Cloud billing means you pay for the hours you actually use, with no idle hardware on the books.
Getting results sooner from the same hardware
Cloud HPC performance depends far more on how the solver is built and how it communicates on those nodes than on how many nodes you switch on.
What tuning per solver actually means
The same source, built with a different compiler, linked against a different numerical library, running on a different MPI implementation, produces visibly different wall-clock times for an identical calculation. DFT codes are sensitive to FFT and linear algebra performance; MD codes to neighbour-list construction and inter-node latency. MAXFlops ships images with that combination already matched to the solvers your team actually runs, so nobody has to experiment with build flags.
How many nodes to attach
Parallel calculations do not run twice as fast on twice the nodes. Past some point communication cost overtakes the compute gain, and where that point sits depends on system size and solver. During onboarding we measure scaling on a representative calculation and set a sensible node count per job from it — over-parallelising costs more and returns results later.
Scheduling and sharing
A standard Slurm scheduler means existing HPC experience transfers unchanged. Priorities and quotas per team or project, plus a fair-share policy, stop one person's large campaign from blocking everyone else's queue. Utilisation, queue state and job history are visible in real time.
Data and cost
Results outlive the nodes that produced them, so storage and compute are designed with separate lifetimes. Resources stay up only for the hours they are needed, following cloud billing rather than leaving you holding idle hardware. Sizing starts from the solvers you run, concurrent users, data volume and budget, worked through together.
Why your existing workflow survives
Because the scheduler is standard Slurm, the submission scripts and habits from an in-house cluster mostly carry over unchanged. That was the point: learning a new command set or rewriting a pipeline should not be what stops a team from adding capacity. Where finished results are retrieved to, and how, is settled during onboarding — after which the aim is that a researcher cannot tell whether a job ran locally or in the cloud.
How it is delivered
We listen to your workload, design a cluster for it, and stand it up. From there, you use it — that is the whole flow.
-
01
Define the workload
Solvers you mostly run, concurrent users, data sizes, and budget — we work through these together.
-
02
Design & stand up
Instances, network, storage, and software stack are designed in the cloud, tuned for your solvers, and brought online.
-
03
Run & operate
Researchers just submit jobs. Monitoring, incident response, and scale-outs are handled by VirtualLab.
Where teams use it
Large-scale materials campaigns
DFT/MD screening across many candidate structures and thousand-job data-generation pipelines.
AI training data generation
Computational datasets for materials ML — workloads that have to finish within a deadline.
Everyday DFT and MD
Routine calculations stuck waiting on in-house HPC, offloaded to the cloud as needed.
Short-term collaborations and projects
Spin up dedicated resources for the duration of a project, then tear down — no procurement cycle.
MAXFlops — frequently asked questions
What is MAXFlops?
A managed service that designs, builds and operates a dedicated HPC cluster for your team on the cloud. You get a large-scale compute environment without procurement, a data centre, or a dedicated administrator.
We already have in-house HPC. Why would we need this?
As headroom. When in-house resources run short or queues grow long, extra nodes come online immediately so a calculation campaign does not stall — expanding for the period you need instead of permanently.
How are jobs submitted and resources shared?
Through a standard Slurm scheduler, with per-team priority, quota and fair-share policies. Utilisation, queue state and job history are visible in real time.
What does "tuned per solver" mean?
Compiler options, numerical libraries and inter-node communication are optimised for the solvers you actually run — DFT, MD and others. The same resources return results sooner, and researchers never have to tune the environment themselves.
How is the cost determined?
Cloud billing for the hours the resources are actually up. We size the cluster after going through the solvers you run, concurrent users, data volume and budget together.
Compute that keeps up, infrastructure that gets out of the way
Tell us the solvers you run, the scale you need, and the timeline. We will come back with a fitting design and an expected cost.