Your own OmnibusCloud

OmnibusCloud can run for your company alone. Your office already owns a compute cluster: the workstations that sit idle at night and between meetings. With a server of your own, they work on your rendering, simulation and parameter studies, for nobody but you, in the applications your engineers already use.

A server coordinates the machines. It splits the work, hands it to machines that are free, and collects the results. Yours can run on the internet, set up and looked after by us, or on a machine inside your office.

You can try the system on the public OmnibusCloud first. A private group of your own machines takes a few minutes to set up, and the applications are the same whichever way you run it.

Three ways to run it

Public network

Nothing to set up. Create an account, make a private group →, install the client → on your machines, and start today. Your work runs only on the machines in your group.

The server is shared. Your files pass through it on their way to your machines, the same server coordinates everyone else's work, and when it is busy your jobs can wait their turn. Solvers that exchange data between machines every round feel the distance to the server. Controllers live on the server for everyone, so there is no room on it for a controller of your own.

Use it to test the system and find out whether you need it. It needs nothing from anyone else in your company.

A dedicated server

We set up an OmnibusCloud server for your company and run it for you. It sits on the internet, and nobody but you uses it. Your office needs nothing beyond the client on its machines, and your engineers type one server address into their applications.

Your files go to your server only.

Its controllers are the ones you choose when it is set up: a team that only runs solvers has no use for Blender rendering, and its server does not carry it. Controllers built for you live there too, and nobody else sees them. A controller can be added later without reinstalling anything, and each machine can decline a controller it should not carry. Your administrator gets the full dashboard: machines, groups, users, running and finished jobs, installed controllers. They can manage the server day to day or leave all of it to us.

A dedicated server is set up under an agreement with us. Transfers still go over the internet, and solvers that exchange data between machines every round still feel the distance. Parameter studies and rendering do not: each variant of a WitSweep study and each frame of a render computes whole on one machine.

A server in your office

A physical machine in your own network. We install it together with your administrator, and from then on your administrator looks after it. The server does not need to reach the internet at all.

As with a dedicated server, the controllers are chosen at installation: what your work needs and nothing else, plus any built for you. Your data, controllers and users stay with you. Files move at the speed of your office network, so the cost of transferring a model mostly disappears, and distributed solves get their best case. The price of that is that the server is yours to run.

A natural path is to try the public network first, run a pilot on a dedicated server, and bring the server into the office once there are numbers to show your IT department.

Several offices, one pool

Dedicated and office servers can be joined through the gateway. A company with offices in several cities, or departments with servers of their own, gets one pool across them: work submitted in one office runs on another office's machines when they are free, and the results come back to the engineer who submitted it.

Each server stays its own. It keeps its users, machines, controllers and schedules, and its administrator decides what it offers to the other side:

• which groups of machines, and in which hours of its own time zone,
• how many tasks at once, with a reserve kept for local work,
• which controllers may run on its machines,
• whether work in flight drains or is cancelled when the link goes down.

Two servers are paired by an invitation that one administrator creates and the other accepts. The accepting server opens the connection, the inviting one never dials out. Only the inputs the other side does not already hold travel over the link, and a short loss of the link holds the work in flight without starting it again. A task runs on the other side only when that side has the same controller in the same version. Both administrators see the link, what crosses it in each direction and anything that needs a look.

The same mechanism lets a company lend its machines to a partner's office, or run work on theirs. Nothing is shared until an administrator turns the gateway on and grants it.

The same applications everywhere

Whichever way you run it, your engineers work in the same applications, pointed at a different server address:

The machines need only the OmnibusCloud client. Solvers and renderers come with it the first time a job needs them, so nothing else is installed on a colleague's computer. The client takes work only when its machine is free and within the hours you allow, and every machine can be paused from its tray.

Built around your work

Everything on this site can be adapted to your tasks or extended for them.

• Your solver. OmnibusCloud runs 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 a dedicated or office server, that controller is yours alone.
• 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 to OmnibusCloud as closely as PrePoMax, ParaView or Inventor are connected today: work that starts from your model and results that come back to it.
• Your process. The checks before a run, the responses a study collects, the recipe a case runs, the way results are reported can all be shaped to how your team works.

We do this work with you, as part of the agreement for a dedicated or office server.

Your data

• What a machine keeps. Nothing of a task after it ends. The task runs in the client's own folders, its working folder is removed when it finishes, and only what the job asked for leaves the machine. Inputs a machine downloaded stay in its cache while it works through a job and are dropped afterwards.
• What the server keeps. A job's inputs and results, for as long as the server is set to keep them, so a study can be extended or re-run.
• What the workstation keeps. Studies, results and downloaded files, in the engineer's own profile.

On a dedicated server, none of this passes through a server anyone else uses. On an office server, none of it leaves your network.

A pilot

A pilot is how we start with a company: a written agreement, a dedicated or office server, and your own work on it from the first day.

What we do:

• Set up the server, connect your machines and set the hours your policy allows.
• Run your real models, and tell you which of them each application takes and which it refuses.
• Licenses for WitSweep for the length of the pilot.
• A working session every two weeks while the pilot runs.

What we ask:

• A handful of your real models, under NDA, so that everything is measured on your own work.
• What a typical task of yours looks like, and the machines you have.
• A named contact who can spend an hour every other week.
• Permission to write up the result as a case study, anonymous if you prefer.

The pilot starts where the payback is quickest: parameter studies on your own models, your engineers keeping their tools. It ends with a written summary of what was measured, and with no obligation to continue.

We run a few pilots at a time, so each gets our full attention.

Talk to us

Tell us what you compute today, on how many machines, and where your models are allowed to go. Contact us →