Coretype Collections

Overview 

Coretype Collections are curated groups of compatible Coretypes that appear as distinct hardware options during job setup, designed to provide equal or better performance at the same or lower cost compared to selecting a single Coretype on its own. A Collection behaves like a single hardware choice in the UI, while giving Rescale flexibility to use multiple underlying instance types that meet or exceed a defined baseline of performance and resources for users.

Highlights

  • Collections are shown as dedicated hardware tiles under a Coretype Collections section on the Hardware step, and each Collection name ends in “Plus” (for example, Elm Plus, Kyanite Plus, Emerald Plus, Starlite Plus).
  • Each Collection is defined around an entry point Coretype that represents the baseline performance and resource characteristics (for example, Elm Plus is anchored on Elm, Emerald Plus on Emerald, Starlite Plus on Starlite).
  • The underlying Coretypes in a Collection are selected so that they are as performant as the entry point or better, for comparable job configurations.
  • When you choose a Coretype Collection, you select a number of cores as usual; that core count is locked for the job, while the platform has the option to provide equal or higher memory and/or storage per node within the Collection definition, at no additional compute price per core.
  • The per‑core compute price is determined when you select the Collection on the Hardware step and does not change based on which underlying infrastructure is used to run the job.
  • Collections are offered only at On‑Demand Pro (ODP) priority; there are no ODE or ODR variants for a given Collection today.
  • When a user selects an individual Coretype that is part of a Collection, the UI can surface a non‑intrusive suggestion to switch to the corresponding “Plus” option, highlighting expected cost and potential performance benefits.

At initial release, four Collections are available across all platforms: Elm Plus, Kyanite Plus, Emerald Plus, and Starlite Plus, with additional Collections to follow over time.

Coretype Collection “Emerald Plus” selected for specified job setup

Using Coretype Collections 

This section describes how to use Coretype Collections during job setup in the Rescale UI.

Selecting a Coretype Collection in the UI

  1. Create a job
    • From the Jobs page, create a new job or duplicate an existing one or create a new job from a Template.
    • Configure your input files and software as usual in the Setup step.
  2. Navigate to the Hardware step
    • On the job setup page, go to the Hardware step (Hardware Settings).
    • Scroll the hardware list to find the Coretype Collections section. Collections appear as hardware tiles with names ending in “Plus”, such as Elm Plus or Emerald Plus.
  3. Configure cores and walltime
    • Specify number of cores and walltime just as you would when selecting an individual Coretype.
    • The core count you configure is locked for the job; the platform may choose between equivalent underlying instance types that satisfy or exceed the Collection’s minimum resource guarantees while preserving this core count.
  4. Inspect Collection details
    • Each tile displays:
      • The entry point Coretype (for example, “Elm” for “Elm Plus”)
      • Key resource ranges (for example, minimum memory per core and storage per core across the Collection)
      • Price per core‑hour (ODP) for your workspace
    • Click or hover on a Coretype Collection tile to reveal more information about:
      • The entry point Coretype
      • A summary of the underlying Coretypes included in the Collection (where exposed)
  5. Submit the job
    • Complete any remaining configuration (Licenses, Post‑Processing, etc.) and submit the job.
    • At runtime, a concrete configuration consistent with the Collection definition and the entry point Coretype family will be selected, while ensuring the job is billed at the fixed Collection rate you saw at submission.

Using suggestions from individual coretypes

When you select an individual coretype that belongs to a Collection (for example, Elm), the UI may display a suggestion to switch to the corresponding “Plus” option (for example, Elm Plus) if one exists for that Coretype.

The suggestion banner or inline card identifies the relevant Coretype Collection (e.g., Elm Plus) and highlights potential value.

You can accept the suggestion to automatically update your job’s hardware selection to the Collection, or ignore it and continue with the individual Coretype.

Similarities and Differences with Coretypes

Coretype Collections are exposed to end users as hardware options alongside standard Coretypes, but they have some important behavioral differences.

How Collections are similar to individual Coretypes

  • Collections show up as individual hardware tiles in the Hardware step, with their own names, SKUs, and pricing, just like regular Coretypes.
  • You can configure cores, walltime, and other job parameters exactly as you would when choosing a standard Coretype; there is no separate job type or workflow for Collections.
  • Collections behave like singular Coretypes with respect to:
    • Job templates and job duplication
    • Automations and scripting
    • Budget enforcement and platform‑side billing mechanics for ODP workloads.
  • Current Collections are defined for Coretypes that are broadly applicable and compatibility expectations are the same as when using the underlying entry point Coretype (for example, if a solver supports Emerald, it will also support Emerald Plus).

How Collections differ from individual Coretypes

  • Group of Coretypes vs. a single configuration
    • A standard Coretype corresponds to a single Rescale compute infrastructure configuration (mapped to one or more provider instance types with fixed resources and price).
    • A Coretype Collection is a curated group of compatible Coretypes anchored on an entry point Coretype, where all members of the Collection are at least as performant as the entry point for comparable core and memory configurations.
  • Collection Specifications
    • Collections have fixed core and node count no matter what underlying compute infrastructure is used and have minimum resource characteristics, based on the Collection’s entry coretype, that are guaranteed across the underlying configurations for storage, memory, network speed, and memory bandwidth.
    • Collections will always meet the performance of the Collection’s entry coretype’s characteristics, but they offer an additional advantage of potentially providing the user better performance at the same cost across a variety of characteristics:
      • Faster read-write for providing low latency access for frequent I/O operations like writing checkpoint files, reading/writing intermediate solver results, and managing scratch data hence reducing time spent on I/O-intensive phases of HPC simulations
      • Up to 8x better network bandwidth enabling faster inter-node communication for distributed HPC workloads.
      • Higher memory bandwidth with improved memory controller architecture and support for faster memory speeds that improve price performance on memory bound HPC workflows (due to faster data access, improved cache line fills, and better utilization of CPU compute resources)
      • More memory capacity for memory-intensive simulations and datasets allowing HPC workloads to process larger simulation domains, finer mesh resolutions, and bigger datasets entirely in-memory without costly disk I/O or the need to decompose problems across more nodes, reducing communication overhead and improving solver convergence times.
  • Fixed ODP priority only
    • Individual Coretypes may support multiple priorities such as ODE, ODP, and ODR (where enabled).
    • Coretype Collections are currently ODP‑only; there is no economy or reserved variant for a given Collection today.
  • Price abstraction over underlying instances
    • With a single Coretype, the per‑core price you see corresponds directly to that Coretype’s configured ODE/ODP/ODR compute price in your account.
    • With a Collection, you see a single ODP per‑core price today set as the same price as the entry point Coretype; the job is billed at this rate even if the platform uses different underlying instance types within the Collection to run the workload.
  • UI signifiers and discoverability
    • Collections are distinguished by the “Plus” suffix and appear in a dedicated Coretype Collections section in the hardware list, while individual Coretypes appear in the main hardware sections (e.g., General Purpose, Large Memory, Large Disk, etc.).
    • When you select an individual Coretype that is part of a Collection, the UI may prompt you to switch to the related “Plus” option.

Relationship to Coretype Sets

Coretype Sets (CTS) and Coretype Collections are distinct but related concepts:

  • Coretype Sets are ordered groups of Coretypes and priorities (ODP/ODE/ODR) that the platform can cycle through to improve job availability and reliability, for example, failing over from one Coretype to another if capacity or quota is unavailable.
  • When using a Coretype Set for a job, the final Coretype used for the job with its characteristics (like core count) can vary based on the setup of the Coretype Set and hence the price will reflect the specific Coretype and setup used.
  • Coretype Collections have a set price and fixed core count making selection for a specific workload an easier decision.
  • Coretype Collections are curated coretype groupings exposed as single “Plus” options that focus primarily on cost–performance simplification, while keeping the job‑level experience as simple as choosing a single hardware tile.
  • Coretype Collections can be added to Coretype Sets in the same way single Coretypes can be added to Coretype Sets.

From a user perspective, both appear as separate hardware choices on the Hardware page and can be targeted or restricted by administrative hardware policies in the same way as individual Coretypes.

Coretype Collections Pricing 

This section outlines how pricing works for Coretype Collections and how it appears to end users.

  • Single ODP rate per Collection
    • Each Coretype Collection has a single ODP per‑core price, visible on its hardware tile in the Hardware step and consistent with what you see for individual ODP Coretypes.
    • Collections are only available as ODP options; you cannot request an ODE or ODR version of a Collection today, and Collections will not appear when filtering strictly for economy or reserved priorities.
  • Parity with entry point Coretype at launch
    • At initial release, Collections are priced at the same ODP rate as their entry point Coretype for your account (for example, Elm Plus uses the same ODP compute price per core as Elm at launch).
    • This means early adopters get simplified selection and potential resource improvements (e.g., more memory or storage per node) without paying more per core than when running directly on the entry point Coretype.
  • Price stability per job
    • The per‑core price is fixed, even if different underlying instance types or regions within the Collection are used at runtime (subject to your organization’s region and hardware policies).
    • Coretype Collections will match the pricing of the entry point Coretype’s ODP price
  • Licensing and platform fees
    • Coretype Collections only affect compute infrastructure pricing. Software licensing, platform fees, and other non‑hardware charges continue to be calculated according to your existing contracts and job configuration (e.g., On‑Demand licenses, BYOL, platform subscription), independent of whether you use a Collection or a single Coretype.
×