OmnibusCloud started as crowdcomputing: people lend their idle machines to projects they care about. Since the simulation tools arrived, engineering companies have been asking us a different question. Can it run for us alone, on our machines, with our models, and nobody else on the server?

That is already how OmnibusCloud is built. The public network is one server with everyone on it. The same server, with the same applications, can run for a single company.

Your office is already a cluster

An engineering office owns more computing power than it uses. The workstations sit idle at night, over the weekend and through every meeting, while an engineer with a study waits for a single workstation to get through the variants one after another.

OmnibusCloud turns those machines into a pool. A small client on each machine takes work when the machine is free and within the hours you allow. A server splits the work, hands it out and collects the results. Your engineers stay in the applications they use: Blender and 3ds Max for rendering, PrePoMax and ParaView for simulation, WitSweep for parameter studies on CalculiX, Nastran and OpenFOAM models.

The question for a company is where that server lives.

Three places for the server

The public network. You can start today. Create an account, make a private group, put the client on your machines, and your work runs on them alone. The server, though, is shared: your files pass through it, it coordinates everyone else's work too, and on a busy day your jobs can wait their turn. Use it to test the system and find out whether you need it.

A dedicated server. We set up an OmnibusCloud server for your company and run it for you. It sits on the internet, nobody else uses it, and your files go to it and nowhere else. Your office installs nothing beyond the client, and your administrator gets the full dashboard, to manage the server or to leave it to us.

A server in your office. A machine inside your own network, installed together with your administrator, who looks after it from then on. It does not need the internet at all. Models and results never leave the building, and they move at the speed of the office network.

The difference between the last two is distance. Parameter studies and rendering don't notice it, because every variant and every frame computes whole on one machine. Solvers that split one model across machines exchange data every round, and for them a server next to the machines is the fastest place.

The comparison, row by row →

What changes when the server is yours

The controllers. OmnibusCloud learns new kinds of work through controllers, the modules that carry a solver or a renderer to the machines. On the public server every controller reaches every machine. On your own server you choose the set at installation: a team that only runs simulations has no use for Blender and doesn't carry it. A controller can be added later without reinstalling the server, and each machine can decline one it should not carry.

Your own solver. We run CalculiX and OpenFOAM because both are open, so their controllers can ship them to every machine. The platform is not tied to them. For an in-house code or a commercial solver, we build a controller that runs it under your license, on the machines that license covers. On your server it is yours alone: no other company sees it or can run it.

Your applications. Where a program you work in opens a way in, through an API, an add-in or the files it reads and writes, we can connect it as closely as PrePoMax, ParaView and Inventor are connected today: work that starts from your model and results that return to it.

Several offices, one pool

A company rarely sits in one building. Dedicated and office servers can be joined through the gateway, so that work submitted in one office runs on another office's machines when they are free. An office whose day is over lends its machines to one where the day is still going, and the results come back to the engineer who submitted the job.

Each server stays its own. Its administrator decides what it offers: which machines, in which hours, how many tasks at once, with a reserve for local work, and which controllers may run on them. Two servers are paired by an invitation, and only the inputs the other side doesn't already hold travel between them. A short loss of the link holds the work in flight instead of starting it again.

The same mechanism works between companies. An office can lend its machines to a partner, or run work on theirs, and nothing crosses until both administrators allow it.

Where to start

Start on the public network. Put the client on a few of your machines, make a private group, and run something real: a render, a study in WitSweep, an analysis from PrePoMax. If it earns its place, the next step is a pilot. We set up a dedicated or office server, connect your machines, and run your own models on it from the first day.

Your own OmnibusCloud → compares the three options in detail. To talk about a server of your own, contact us →.

Questions and feedback: r/OmnibusCloud →.