Skip to content

Approach

This page explains how Vishwanath Grid is put together. The short version: many universities, one shared cluster, one login, open-source everything.

What "shared cluster" looks like in practice

Each partner university keeps a small number of compute servers on its own campus. Those servers are physically owned and run by the university — same as any other on-campus equipment.

What is different is the layer of software that sits on top of all those servers. From a researcher's point of view there is only one cluster, with one login screen, one job-submission page, and one shared file system. Where the job actually ends up running is a detail handled by the scheduler, the program that picks a machine for each job.

flowchart LR
  R[Researcher] -->|one login| GW[vishwanathgrid.org]
  GW --> S[Scheduler]
  S --> P1[Servers at university A]
  S --> P2[Servers at university B]
  S --> P3[Servers at university C]
  GW --> D[Shared storage]
  GW --> T[Research tools]

One login, every tool

A researcher signs in once, on a normal-looking login page. After that, every Vishwanath Grid service — the cluster, the code repository, the notebooks, the dashboards, the chat — recognises them automatically. There is no separate password for each tool.

The technology that does this is called single sign-on. We use a well-established open-source single-sign-on server. If a partner university already has an identity system (most do), it can plug in.

Open-source, top to bottom

Every component the platform runs is published under a permissive open-source licence — typically Apache 2, MIT, or AGPL. There are no commercial subscriptions inside the stack, which means:

  • A partner can read the source code of anything we run.
  • If a project we depend on stops being maintained, anyone can fork it and continue.
  • A partner who leaves the federation can keep running everything they were running, on their own machines.

Designed for the long horizon

Universities work on decade timelines. The cluster is built the same way:

  • Hardware that is generic enough to be re-tasked when a research group's needs change.
  • Software with no subscription costs, so a funding gap does not stop the lights from staying on.
  • A federation model where any single partner leaving does not break the whole.

If you want to see the order we are building things in, the roadmap has the phase-by-phase view.