Book Cephas, Our 160-Core, ~7.0 TFLOPS ADCIRC Live Cluster

Our Services

Access to our managed ADCIRC cluster is not free, but it is very cost-effective. It is not running in the cloud; it is a physical cluster that we operate and maintain in Houston, Texas, USA.

We call our dependable, bare-metal computing cluster, Cephas.

We are continuing to refine the best ways to provide access and support. For now, interested users should email us to discuss their requirements.

We can reserve blocks of days or weeks during which a client may use the cluster exclusively. The exception is an operational emergency, such as a hurricane, when we may need to reclaim the cluster for forecasting or response work.

Exclusive access to Cephas starts at $100 per day, with a minimum reservation of three days. Final pricing depends on the reservation length, scheduling priority, storage and data-transfer requirements, and the amount of technical or engineering support requested.

Self-managed pricing covers reserved computing access and normal cluster operation. Model preparation, ADCIRC configuration, troubleshooting, data processing, engineering assistance, and other hands-on services are quoted separately.

We work best with friendly, collaborative clients who share our goal of getting their ADCIRC simulations completed successfully.

Email us to book Cephas, with full-cluster access starting at $100 per day.

About Cephas

Cephas is our four-node, 160-physical-core ADCIRC computing cluster. Rather than nickel-and-dime users with complicated CPU-hour pricing, we prefer to learn about each client’s requirements and provide a customized quote.

We are open to renting part or all of the cluster for fixed blocks of time, depending on scheduling and priority. We use Cephas for our own ADCIRC work as well, but our rental rates can be substantially lower than comparable commercial cloud-computing costs.

Our goal is the same as yours: to get your ADCIRC runs completed. Tell us about your mesh, simulation duration, forcing, number of scenarios, output requirements, and desired completion date, and we will help determine the most practical way to run the work.

You can also jump to the comparison below to see approximately what would have been required to provide comparable theoretical computing capacity in 2006, shortly after Hurricane Katrina.

Email us at help@support.adcirc.live to request information about renting Cephas and receive a free quote!

Sign up for our announcement email list to receive updates about cluster availability, capabilities, and services.

Cephas: Our ~7.0 TFLOPS ADCIRC Cluster Specifications

Recent Improvements and Planned Upgrades

Cephas is an actively maintained system. We have recently expanded the cluster to four compute nodes and 160 physical CPU cores, and we are continuing to improve its network, scheduling, and storage infrastructure.

• Dedicated 10 Gigabit Ethernet network: We plan to add a private 10 GbE network connecting the compute nodes and shared-storage system. This should provide substantially more bandwidth than the current Gigabit Ethernet network and reduce network bottlenecks during multi-node MPI communication, shared-file access, model startup, and output processing.
• Improved Slurm scheduling topology: We are refining the Slurm configuration so that cluster-management, login, scheduling, storage, and compute responsibilities are more clearly separated. These changes are intended to improve reliability, simplify maintenance, and allow compute resources to remain focused on ADCIRC workloads.
• Improved job placement: Planned Slurm topology and scheduling improvements will provide greater control over how MPI ranks and jobs are distributed across the cluster. This will help us account for node memory, shared-storage access, network communication, and the location of output-writing processes when scheduling ADCIRC runs.
• Faster shared storage: Further down the road, we plan to supplement or replace portions of the current spinning-hard-drive storage with solid-state storage. High-speed NVMe storage is the preferred long-term performance option because it provides substantially higher throughput and lower latency than conventional hard disks and SATA SSDs.
• Tiered storage: Large-capacity hard disks may continue to be used for archival and less performance-sensitive data, while faster SSD or NVMe storage could be used for active model inputs, temporary files, checkpoints, and simulation output.

These upgrades are intended to improve real ADCIRC turnaround time rather than merely increase theoretical specifications. The greatest benefits are expected for multi-node simulations, jobs that generate large output files, repeated ensemble runs, and workflows that rely heavily on shared storage.

If you need a cost-effective environment in which to scale your ADCIRC capacity quickly, click here to request a free quote !

ADCIRC Cluster Services

There are many practical considerations associated with running ADCIRC locally, and we are prepared to discuss all of them with you. These include:

• The advantages and disadvantages of a local physical cluster versus cloud computing, and when to use either approach
• The advantages and disadvantages of multi-core workstations or laptops compared with a dedicated cluster
• Electrical capacity, power consumption, battery backup, cooling, and additional HVAC requirements
• Shared storage, network throughput, MPI communication, and ADCIRC scaling
• Equipment cost, total cost of ownership, maintenance, and depreciation
• When to purchase used professional equipment rather than new hardware
• How to build an affordable initial cluster while retaining the ability to expand it later

We can also provide complete ADCIRC cluster services, including:

• Cluster design and detailed equipment recommendations
• Cluster hardware installation and setup
• Linux installation and system configuration
• Network and shared-storage configuration
• Slurm workload-manager installation and configuration
• Compiler, MPI, NetCDF, HDF5, and supporting-library installation
• ADCIRC and ADCIRC+SWAN installation, compilation, and testing
• ADCIRC cluster user training and IT support
• ADCIRC engineering and modeling support
• General cluster maintenance, monitoring, troubleshooting, and expansion
• Rental access to part or all of Cephas

To learn more, click here to request additional information or receive a free quote !

Modern vs. 2006: What a 160-Core, ~7.0 TFLOPS Cluster Means

TL;DR: The theoretical computing capacity provided today by four professional workstations could have required several hundred dual-socket servers and a small datacenter in 2006.

Cephas Today

• Nodes: 4 Dell Precision T7810 workstations
• Processors: 8 × Intel Xeon E5-2698 v4
• Physical cores: 20 per processor, 40 per node, and 160 cluster-wide
• Estimated peak FP64: Approximately 0.88 TFLOPS per processor and approximately 7.0 TFLOPS total
• Installed memory: 96 GB total
• Estimated heavy-load power: Approximately 400–500 watts per node, or approximately 1.6–2.0 kW total
• Footprint: Four professional tower workstations
• Storage: 16 TB of shared storage

Approximate 2006 Equivalent

• Representative processors: Dual-socket, dual-core Intel Xeon “Woodcrest” or comparable AMD Opteron systems
• Estimated FP64 performance per node: Approximately 16–20 GFLOPS
• Nodes required to approach 7.0 TFLOPS: Approximately 350–440
• Physical cores: Four per node, or approximately 1,400–1,760 cores
• Typical memory: Approximately 4–8 GB per node, or approximately 1.4–3.5 TB distributed across the cluster
• Estimated server power: Approximately 400 watts per node, or approximately 140–176 kW, before cooling and other datacenter overhead
• Estimated footprint: Approximately 9–11 full racks at one rack unit per server, with additional space required for networking, storage, power distribution, and management systems

Notes: FLOPS values are estimated theoretical peak double-precision performance figures and are intended only as rough comparisons. The 2006 estimates assume approximately 16–20 GFLOPS per dual-socket, dual-core server. Real ADCIRC performance depends on processor frequency under sustained load, memory bandwidth, network latency and throughput, compiler and MPI configuration, file-system performance, model characteristics, and application scalability.