Included compute
Production compute, already in the plan.
Studio Core includes a serious monthly GPU allocation alongside the solver, meshing and platform. There is no separate HPC licence, cluster purchase or variable cloud bill between your team and the next result.
01
A production allocation, not demo credits
Enough capacity to establish a real monthly engineering cadence.
Make decisions without pricing every run
Core provides 120 A100-equivalent hours each month. At our deliberately conservative internal planning basis of 250 conventional CPU cores per A100, that represents roughly 30,000 CPU core-hours of monthly solver capacity.
The practical benefit is behavioural as much as financial: engineers can rerun a case, compare a design change or investigate a convergence issue without first asking whether the next job is worth another cloud charge.
120A100-equivalent hours
×250CPU cores · planning basis
=≈30,000CPU core-hours / month
four-hour solves
Short production runs, setup checks and rapid design decisions.
eight-hour solves
A sustained cadence of larger steady-state cases.
twenty-hour solves
Longer, higher-fidelity jobs without a separate cloud invoice.
Illustrative mixes assume each job consumes the stated A100-equivalent GPU time. Actual throughput varies with mesh size, physics, convergence and hardware.
02
The capacity is separated where it matters
Solver work, meshing and parallel throughput do not compete for one opaque credit pool.
Solver compute
A recurring monthly allocation for steady RANS and URANS workloads.
Meshing compute
A separate CPU allowance, so geometry preparation does not consume solver capacity.
Parallel throughput
Run independent engineering workstreams without buying another solver seat.
Managed hardware
Use the appropriate available accelerator without operating a GPU cluster yourself.
03
Why including compute changes the economics
The usual CFD stack spreads one workflow across several purchases and owners.
Several costs before the first result
- Base solver licence
- Parallel or HPC scaling licence
- Cloud instances or GPU servers
- Meshing capacity and storage
- Cluster, queue and driver administration
One managed production allocation
- FluxCore solver access
- Steady RANS and URANS workflows
- GPU scaling without an HPC add-on
- 120 GPU-hours every month
- Separate meshing compute
- Managed hardware and job orchestration
Why this matters
Included compute turns simulation capacity into a known operating cost. Teams can plan throughput around engineering demand rather than licences, instance prices and hardware availability.
04
Why we use a conservative planning basis
Published GPU-resident CFD results show that one accelerator can outperform many CPU cores.
| Published engineering case | Hardware comparison | Reported result | Primary source |
|---|---|---|---|
| DrivAer external aerodynamics | 1× A100 vs 80× Xeon Platinum 8380 cores | >5× faster | Ansys GPU benchmark, part 1 |
| 7.1M-cell automotive air intake | 1× A100 vs 32× Xeon Gold 6242 cores | 8.3× faster | Ansys GPU benchmark, part 2 |
| 4M-cell traction inverter CHT | 1× A100 vs 32× Xeon Gold 6242 cores | 8.6× faster | Ansys GPU benchmark, part 2 |
These are third-party Ansys Fluent benchmark results, not FluxCore benchmarks or a guarantee of case-level performance. GPU uplift varies with mesh, physics, numerics and CPU generation. Studio therefore uses a 250-core planning basis rather than the highest equivalence implied by any single published case.
Scale reference10×
At the 250-core planning basis, Core's monthly allocation is equivalent to roughly ten times SimScale Community's currently listed 3,000 core-hour allocation.
View SimScale's published allocationPut it against a real case
See what the allocation means for your workflow.
Start with a free case evaluation, a scoped Pilot Study, or Studio Core.