D7.4.1: Applications and user requirements for Tier-0 systems
Bibliographic record
Abstract
This is the initial deliverable for Task 7.4 (Applications Requirements for Tier-0 Systems). It reports the results of surveys carried out of current PRACE partners’ HPC systems, the applications running on them, and of current/potential users of the PRACE infrastructure. The questions asked in the systems and applications survey are largely the same as were asked in a previous PRACE survey, carried out in 2008, and so changes in findings can be observed. The results of an applications survey from the South Eastern European HPC community are included as an Annex to this deliverable.<br> The principal findings from the PRACE surveys were:<br> - 28 systems are represented in the systems survey, representing just over 3.0 PFlop/s of peak computing power.<br> - Compared to the 2008 PRACE-PP survey, the compute power available across the PRACE partners has increased by a factor of 3.7, with almost all this increase being a result of increased numbers of cores, rather than increased power per core.<br> - Around a quarter of CPU cycles on these systems go unused.<br> - As the number of cores in systems has increased, so too has the number of cores used by jobs on these systems, but at a slower rate, so that the fraction of the machine used by the average job has decreased since 2008.<br> - PRACE partners are supporting about 50% more users per system than in 2008.<br> - While the popular scientific and I/O libraries, debuggers and performance analysis tools are present on many systems, it is clear that they are not universally available.<br> - For each system, we requested an application survey return for all applications which consumed more than 5% of the CPU cycles on that system. This resulted in 93 survey returns, representing 57 different applications.<br> - The most widely used applications are largely the same ones as in the 2008 survey.<br> - Compared to the 2008 survey, there has been an increase in the proportion of applications using C or C++, such that the balance is now approximately half C/C++ and half FORTRAN.<br> - MPI remains by far the most popular parallelisation technique, though there has been a modest increase in the number of codes using mixed-mode MPI/OpenMP.<br> - There were no applications reported as using any of the PGAS family of APIs.<br> - 411 responses to the user survey were collected.<br> - Over 50% of users have their own application codes, and consider themselves as developers rather than end users.<br> - The most commonly used shared codes are mainly from the areas of Computational Chemistry and Molecular Dynamics.<br> - There is a general desire from users to increase the scalability of their applications, but their ambitions are relatively modest.<br> - Over one-third of users do not fully understand the scalability issues of their applications and about 15% expressed a desire for assistance from PRACE to solve this problem.<br> - Over one-third of users require more than 2GB of memory per core for their application: this is likely to become a significant problem on future systems.<br> - Almost 50% of users would be prepared to use a different application if it meant more scalability.<br> - Requirements for disk space and for the amount of data to be transferred off the system vary widely, over more than three orders of magnitude.<br> - Users are slightly more likely to use C or C++ than FORTRAN as their main development language<br> - MPI and OpenMP are by far the most widely used parallelisation methods.<br> - Use of Grid middleware and workflow systems is rather low.<br> - Just over 50% of users had considered applying for PRACE resources, but of those that had not, over half were unaware of the possibility.<br> - A large majority of users thought that the potential future diversity of architectures would make applying for PRACE resources more attractive, and that smaller, stepping-stone resources (i.e. Tier-1) would be a helpful route to Tier-0 access.
Fetched live from OpenAlex and de-inverted. Abstracts are not stored in this database: the inverted indexes are 8.6 GB of the frame’s 9.3 GB of text, and the host has 13 GB free.
How this classification was reachedexpand
Full frame distilled prediction
Teacher imitationNot calibrated prevalence, not ground truth. Human validation pending. Learned from the 10,348 direct Codex labels and 10,348 direct Gemma labels. Candidate is the union of thresholded teacher heads; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels or direct frontier model labels.
Codex and Gemma teacher scores by category
| Category | Codex | Gemma |
|---|---|---|
| Metaresearch | 0.000 | 0.000 |
| Meta-epidemiology (narrow) | 0.000 | 0.000 |
| Meta-epidemiology (broad) | 0.000 | 0.000 |
| Bibliometrics | 0.000 | 0.000 |
| Science and technology studies | 0.001 | 0.000 |
| Scholarly communication | 0.000 | 0.001 |
| Open science | 0.002 | 0.002 |
| Research integrity | 0.000 | 0.000 |
| Insufficient payload (model declined to judge) | 0.000 | 0.001 |
Machine scores (provisional)
The two teacher heads of the student model, read on this work. A score orders the frame for review; it never asserts a category, and the validation status ships verbatim with every row.
Baseline scores from an immature model (maturity gate not passed, 7 training rounds). Scores rank; they never assert a category.
score_only:v0-immature-baseline · verbatim from the scoring run: score_only means the number may rank works, and no category label ships from itClassification
machine, unvalidatedMachine predicted; a candidate call from one teacher head, not a consensus.
How this classification was reached, model by model and score by score, is at the end of the page under "How this classification was reached".