When it comes to covering supercomputers, the most attention falls on the front runners on the Top 500. However, a closer look at the tail-end of the rankings reveals some rather interesting use cases—not to mention courses of development, system design, and user-driven requirements for future build out.

The University of Florida is home to one expanding system, which rests just at the cutoff of the top supercomputing rankings at #493. The university’s Director of Research Computing, Dr. Erik Deumens, tells us the real purpose of the system is to support as many diverse applications as possible with as few queue barriers as possible. While this is a familiar claim no matter what size the site may be, the team has gone through great lengths to ensure that current developments to make their flagship system, called HiPerGator, are fed solely by user demand.

It might not be surprising then, at least to those in research computing, that the demand for the latest generation of processors with a 10 or 20% performance jump is far less critical than simply being able to onboard an application without a long queue and run in a reasonable amount of time. But meeting that need requires some serious thought about capacity, scheduling, and meeting diverse application requirements. In other words, for those tuning in for the ultra-high performance computing story, this isn’t the most exciting tale, but there are some important lessons to be learned from his team’s experiences working with a broad range of applications and over 600 users to find out what really creates a fully functional system—all based on what amounts to an “economic” decision-making process for their HPC investments.

In essence, the economics of demand determine the spending decisions at the University of Florida and several other similar centers. This isn’t so different than the large scientific computing sites in theory, except user requests trump all—including power or other considerations. “If the users are asking for the latest novel technology but it’s not the most efficient, we aren’t going to deny them what they need for their research,” says Deumens. In the case of HiPerGator, the university funds the system and staffing so that that individual researchers can use their grants to buy a desired number of cores for their jobs. Flexibility is built into the “purchase” as users can go past 10x what they requested as needed to avoid added complexity in terms of scheduling and managing their jobs. Deumens and team use Moab and Torque to handle the many requests, in addition to offering the capability for more sophisticated users to fine-tune their requests according to the mix of available architectures. The system tends to run under its maximum capacity at all times so that there are not long wait times since the one thing that researchers want—timely (if not immediate) access to computational resources that run in the anticipated timeframe. And essentially, says Deumens, everyone is happy.

For some background, the HiPerGator system in its original incarnation (announced last year) offered up over 16,000 AMD “Abu Dhabi” cores with Dell underpinnings, a 2.88 petabyte Terascala-built Lustre-based system and Mellanox’s Infiniband throughout. They’ve since added an additional round of cores from pre-existing systems (both Intel and AMD), bringing their HPC core count to over 21,000. There is a set of nodes that provide a total of 80 GPUs in addition and more planned for the future—in addition to the possibility of Xeon Phi cores as well as they plan their build-out to be completed by this time next year. “There are always exceptions but most of our users don’t care what processor generation they’re running on. They just want to get their work done.” And all the while, his team keeps very careful track of what the users are looking for in terms of new or existing hardware and they use this information to tally what they ask vendors for during each year’s hardware and software buying cycles.

To put this in context, when the original HiPerGator emerged, there were a total of 8 GPUs available to researchers, which they bought simply to support the mission of a semester-long class that required them for special projects. However, once researchers at the university knew they were available, they began experimenting with porting codes, including AMBER on the molecular dynamics front. These development activities led the application teams to desire full production runs, which required more GPUs. And so their unexpected influx of GPU nodes occurred organically. This is the exact type of case that will feed how the next generation of their system develops—actual user interest means more “purchases” from researchers, but to keep their one main goal of providing solid resources without the wait times, they’ll make sure to supply ample nodes with whatever the research community seems to desire.

Deumens and team are taking those desires on the road in the next months. They’re currently in the midst of looking for vendors to help them supply the needs of HiPerGator 2, which again, is slated for this time next year. He gave us a sense of what works—and doesn’t—when it comes to supporting research at a university that wants to become a top tier research center based on its HPC capabilities.

First, he says, there are some successes in terms of their approach to scheduling. It used to be a manual process, but has been eased through their Moab and Torque engines. Further, he highlighted the increasing role of Galaxy, the open source scientific gateway project for creating, tracking and sharing scientific workflows that has taken off in the biosciences community. He also says that for a research center their size, the more cores they have available, the better. While some of their users can take advantage of their Infiniband fabric and run MPI or SMP jobs, in the end it’s all about getting up and running.

The other element that has worked for research teams at the University of Florida is having a stable, strong storage system like their Terascala solution, which is capable of handling massive data flows—an increasing problem for all scientific computing sites as data demands scramble to meet the computing capacity that is available.

What’s missing from their system is something that will be difficult for any of the vendors who supply the next iteration of the machine next year. And it’s something we’ve heard from much larger centers. There is a dramatic need to make a “super app” of sorts that turns a researcher’s desktop machine into a direct link to the supercomputing site, handling scheduling, data movement, and output in a seamless, portable interface. While this seems like it might be easy in this era of web-based interfaces for everything, it’s what’s really missing for centers designed around simply serving scientific users—and something that he and his team will continue to look toward in the coming years.

It was interesting to listen to the difference in concerns about power, performance and ease of access from the perspective of a much smaller HPC site than the top ten system managers we so often talk to. Power is always a concern, of course, but at smaller scale when exascale is something for the DoE and other government labs internationally to worry about, the problems of real-world daily operations boil down to one simple factor—make a supercomputer easy to use, quick to load into, and predictable in its time to result. A humbling reminder after so many conversations about eeking performance out of the hottest processors, largest systems and biggest power footprints on the planet.