D7.4.1: Applications and user requirements for Tier-0 systems
Notice bibliographique
Résumé
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.
Récupéré en direct depuis OpenAlex et désinversé. Les résumés ne sont pas conservés dans cette base de données : les index inversés représentent 8,6 Go des 9,3 Go de texte de la base, et le serveur dispose de 13 Go libres.
Comment cette classification a été obtenuedéplier
Prédiction distillée sur la base complète
Imitation des enseignantsNi prévalence calibrée, ni vérité terrain. Validation humaine à venir. Apprise à partir de 10 348 étiquettes directes de Codex et de 10 348 étiquettes directes de Gemma. Le mode candidate est l'union des têtes enseignantes seuillées; le consensus est leur intersection. Ces sorties portent le statut machine_predicted_unvalidated et ne sont ni des étiquettes humaines ni des étiquettes directes de modèles de pointe.
Scores Codex et Gemma par catégorie
| Catégorie | Codex | Gemma |
|---|---|---|
| Métarecherche | 0,000 | 0,000 |
| Méta-épidémiologie (sens strict) | 0,000 | 0,000 |
| Méta-épidémiologie (sens large) | 0,000 | 0,000 |
| Bibliométrie | 0,000 | 0,000 |
| Études des sciences et des technologies | 0,001 | 0,000 |
| Communication savante | 0,000 | 0,001 |
| Science ouverte | 0,002 | 0,002 |
| Intégrité de la recherche | 0,000 | 0,000 |
| Charge utile insuffisante (le modèle a refusé de juger) | 0,000 | 0,001 |
Scores machine (provisoires)
Les deux têtes enseignantes du modèle étudiant, lues sur ce travail. Un score ordonne la base pour la relecture; il n'affirme jamais une catégorie, et le statut de validation accompagne chaque rangée tel quel.
Scores de référence d'un modèle non mature (critères de maturité non atteints, 7 itérations). Un score ordonne; il n'affirme jamais une catégorie.
score_only:v0-immature-baseline · tel quel depuis la passe de notation : score_only signifie que le nombre peut ordonner les travaux, et qu'aucune étiquette de catégorie n'en découleClassification
machine, non validéePrédiction automatique; un appel candidat d’une seule tête enseignante, pas un consensus.
Le détail, modèle par modèle et score par score, se trouve en fin de page sous « Comment cette classification a été obtenue ».