Usage
Grid is best suited for your problem when it is relatively easy to split it up in multiple, independent parts. Of course, we at SURF are willing to help you bring your application to the Grid. Please contact our Servicedesk for any questions or advice.
When you have software running MPI, or on multiple, intercommunicating threads you may find it difficult to port this to a Grid. MPI jobs can be run on our Grid, but will run on a single cluster. All our clusters run CentOS 7 or up and every script or program which runs on this can in be principle be submitted to the Grid. At present all grid nodes run Grid middleware (gLite). The amount of memory a job can address is about 8 GB RAM per core.
Service Model
Grid is aimed at projects that depend on a continuous amount of available resources that enable them to execute their production workflows predictably. The service model for Grid is aimed at facilitating these production workflows.
Although allocations are based on a number of core hours over the project period, they are actually not a budget that can be depleted with over usage. For each Grid project, CPU and GPU allocations will be transferred into priority configurations by means of a so-called fairshare mechanism. These priority configurations will allow projects to claim a continuous amount of cores, provided that a sufficient amount of workload is being scheduled continuously. The fairshare configured for your project will depend on the allocated CPU and/or GPU capacity as well as the start and end dates of the allocation.
The mechanism implements a job priority that depends on the actual recent resource consumption, allowing for rapid scale-up to the designated number of cores for each project. Over the project runtime, the continuously available cores will automatically accumulate into the allocated CPU and/or GPU capacities, regardless of you actual usage. In times of underusage by other projects, more cores can be acquired than foreseen, but this will not go at the cost of the priority configuration, which will be constant over the full project runtime.
Example: if your project requires a sustained amount of 200 cores over a project lifetime of 12 months, an allocation of 200*24*365 = 1.752.000 core hours would result in a fairshare setting that allows for the use of 200 cores continuously.
More information
For more detailed user information please see these pages.